Subscribe to this blog and receive notifications of new posts by email.
Join 2,252 other subscribers
IRC Hours: Mon @ 1600 UTC & Thurs @ 1500 UTC
IRC Hours: Tues and Fri @ 2100 UTC
Backup: Scott Taylor
IRC Hours: Mon @ 1900 UTC & Thur @ 1600 UTC
Lead: Dave Martin
IRC Hours: Mon & Thur @ 2000 UTC
Lead: Sergey Biryukov
Lead: Lance Willett
Backup: Konstantin Obenland
IRC Hours: Tues & Thur @ 1700 UTC
Suggest agenda items for Oct 29th dev chat
Eric Marden, demetris, Matt Martz, and 5 others are discussing. Toggle Comments
Custom post type ui. Can it make it to 2.9?
2.9 is feature frozen.
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
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.
Review status of features with regard to beta readiness
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/
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.
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.
Is that what .maintenance is for? http://sivel.net/2009/06/wordpress-maintenance-mode-without-a-plugin/
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]
← I updated the access flags for #wordpres…
Agenda for Oct 29th dev chat: * Custom p… →
License / GPLv2
Hosted WordPress.com |
WordPress.TV Videos |
WordCamp Events |
BuddyPress Social Layer |
bbPress Forums |
WP Jobs |