WordPress.org

Peter Westwood 8:52 pm on October 23, 2009 Permalink  

• 

  Lari 8:23 am on October 24, 2009 Permalink

  Custom post type ui. Can it make it to 2.9?

  • 

    Alex M. (Viper007Bond) 2:50 am on October 26, 2009 Permalink

    2.9 is feature frozen.

• 

  Beau 2:45 am on October 26, 2009 Permalink

  Doing security-only patches as a way of 1. maintaining some level of support for older versions of WP, and 2. being “safer” to implement fully-automated core upgrades

  • 

    Alex M. (Viper007Bond) 2:49 am on October 26, 2009 Permalink

    Isn’t that what was done with the 2.0.x branch? Turned out to be a ton of work and not really worth the trouble.

    http://wordpress.org/development/2009/07/the-wordpress-2-0-x-legacy-branch-is-deprecated/

• 

  Peter Westwood 8:38 am on October 28, 2009 Permalink

  Review status of features with regard to beta readiness

• 

  Jeffro 10:20 am on October 28, 2009 Permalink

  I’m noticing more and more with queries in the WordPress support forums of folks who upgrade WordPress only to be greeted with memory limit exhausted errors. I had this problem myself when I upgraded to the version of WordPress once SimplePie was used as the feed parser. I had to go from 32 megs to 64. Is it possible that this information needs to be added to the minimum requirements page on WordPress.org? http://wordpress.org/about/requirements/

  • 

    Matt Martz 11:56 am on October 28, 2009 Permalink

    I think one thing that people tend to forget is that they should deactivate all plugins before performing an upgrade. Did you perform this step when you did the upgrade? Maybe what we should do is detect whether or not plugins were deactivated. If not, then make a backup of the option containing the active plugins, clear the option, upgrade, then restore it. Or perhaps add a check to see if we are upgrading and then not load plugins if that constant is set. Just some ideas.

    • 

      demetris 2:24 pm on October 29, 2009 Permalink

      Deactivating plugins before upgrading is good advice in theory, but in practice it is problematic, since very often plugins offer functionality that is integral to a site. You can’t just deactivate them.

      For upgrade issues caused by plugins, another idea would be to have a “Known Issues” part in the release notes. If a prominent, popular plugin breaks something essential in WordPress when upgrading (and WordPress has enough prerelease testers to catch such issues for popular plugins), then it could be mentioned as a Known Issue.

    • 

      Eric Marden 4:30 am on October 31, 2009 Permalink

      @demetris

      Is that what .maintenance is for? http://sivel.net/2009/06/wordpress-maintenance-mode-without-a-plugin/

• 

  demetris 6:28 pm on October 29, 2009 Permalink

  1. Improve template for new release announcements

  2. Link to release announcement from admin upgrade notice, something like: [Read what is new] or [Click to upgrade]