> I think removing 400 lines of duplicated code in post.php is a real improvement.
That is really refactoring. It doesn't help the client directly. It makes future modifications easier. As with others it also should be prioritized. Do you have unit/acceptance tests which will ensure that something will not break while doing this refactoring?
Removing duplicated code does help the client directly, in several ways. It slims down the single download archive a bit. It makes posting and editing use the same code, and therefore provides a unified workflow, as opposed to the previous bifurcated one for posting versus editing.
I have no unit or acceptance tests. If you have some, please submit them.
> I think more plugin hooks are a real improvement.
Is there a real strong requirement for them? Or just someone feels they are nice? You can always add tons of hook everywhere. However they also, however imperceptibly slow down rendering of the page. I think hooks should only be added to address a strong requirement. They don't take much time to add but we shouldn't indiscriminately go down that path.
Yes, there is an identified need for new plugin hooks. People are looking to do more and more with WordPress, including some (weird) integration with other systems. Plugin hooks facilitate these integrations without requiring users to modify core code.
Further, the core WordPress developers have repeatedly stated that the WordPress core should be kept as slim as possible, focusing on core functionality. Non-core features should be implemented in plugins. So far, this has worked well.
Plugin hooks are being added for plugin (de-)activation, user creation and deletion, and more.
BTW: Don't talk caching for speed here as caching comes with its own set of problems. It renders many real-time plugins useless.
I said nothing about caching.
> I think a robust user capabilities system is a real improvement over arbitrary user levels.
Define robust user capabilities. What is the plan/architecture for this new system? Fundamentally what are we getting with this?
I invite you to subscribe to the hackers mailing list, where you can monitor -- and participate in -- the discussions surrounding the user capabilites system.
One thing I noticed is that in several places wp template tags or functions dictate visual layout. They should be separated in all places. It makes for better template creation and maintenance.
Many important functions are not documented codex, which I often find in the code.
Please submit patches for these items. If you have improvements, please share them, instead of complaining that the two core WordPress developers didn't code things the way you would have.
Several people are using WordPress around the world. Whenever there is an upgrade it affects them. Many have personalized WordPress. Any new release should keep these users in mind. Between 1.2 and 1.5 the whole templating system changed. It was a big change for many and hence many haven't upgraded even today as you can see in the forums.
Anyone who edits (or "personalizes") core WordPress files is taking it upon themselves to maintain their revisions across upgrades. This is true in any Open Source system in which a user makes changes. The core system cannot be made to accomodate all users' modifications. This is entirely up to the user.
I have seen plugins break with even minor releases like 1.5 to 1.5.1. Sufficient care needs to be taken.
Please address your concerns to the plugin authors. The core WordPress developers cannot be held responsible for plugin breakage.
WordPress is moving into big league. Think Big. Look at Microsoft. They test new releases with popular software of their platform before releasing them. WP developers should similarly test popular plugins (need not be perfect list and yes mistakes can happen) with every new release.
Plugin developers need to test their own plugins. It is unreasonable to expect the core WordPress developers to test even a smattering of the available plugins, many of which the core developers do not use.
Themes break everywhere with new releases. Why? We need to find out.
Part of the problem is that there is no official guidelines which says what to do and what not to do in theme development. You should think about compliance checking.
Please help us write the documentation necessary. Please spend time with us in #wordpress-docs, agonizing over how best to articulate complex concepts to new users without insulting advanced users.
WordPress developer community should focus on perfecting existing functionality more than adding new goodies. People are still facing issues with pingbacks and trackbacks. I know them, fixed them in by blog, couldn't find time yet to release them as plugins. Another reason is that they shouldn't be plugins but part of core code.
Instead of writing plugins to solve these problems, please submit patches to the core application.
WordPress needs to publish its architecture. Serious re-factoring needs to be done.
Please submit patches to help expidite your refactoring suggestions.
WP community should issue patches, specially for security upgrades.
Thank you for your volunteer effort in this regard so far. I encourage you to continue to satisfy this need for others.
Despite the strength of plugin architecture, expect people to modify code. The community should reasonable accomodate them and not just provide blaket statements like it will be tougher etc.
How do you propose we support poeple who make changes to the core files? If you're customizing core files, then you should keep track of what you've changed, and why. Before upgrading, you can compare the last-modified versions of your files to the available source code. Or, if you're handy with
diff, use that.
WordPress, as a project, does a lot to make the code available to the people who want it. We, the support volunteers, have done our best to support as many people as we can. If you make modifications to core files, or if you use an unstable un-released development version of WordPress, you should expect challenges. That's just the way it's going to be.
I think the above should have higher priority over ajaxian niceties and draggable menus.
I happen to agree with you, but not everyone does.
This is Free Software. The two core developers do this because they want to. It is entirely their perogatvie to focus on the development aspects that give them the most pleasure.
I made a modest effort to propose something other than the draggable interface. I invite you to do the same.