Suggest agenda items for January 21, 2010 dev chat.
kelebek, Peter Westwood, wpmuguru, and 7 others are discussing. Toggle Comments
I believe 1.4 is in trunk already.
I don’t think a big re-organisation will help anyone.
It is just a lot of work for not a lot of improvement.
We are gradually trying to remove code duplication and make the code more re-usable. The work that has been done on custom post types for 3.0 already removes a fair amount of code duplication and make it easier to maintain.
About “WordPress Coding Standards – How to go on?”,
Has the way of building admin pages been adressed ?
This is more a code architecture subject than a coding standards subject.
In standard WordPress, for admin, if you take a look at how code is organized, and try to follow the building of an admin page from top to bottom :
I personnally tried to solve this in my plugin MailPress (requires PHP5 but this code architecture can be implemented for PHP4 & PHP5):
As WordPress admin is going bigger and bigger, isn’t it time to reorganize this part of WP, to gain in
[…] will bring this up at the next dev meeting, but as of right now there is no jQuery 1.4 in WordPress […]
jQuery 1.4 came out during this cycle. If we add it now before we get to far we can try to remove all the bugs, but I suggest holding it off till. Twitter is starting to get the ‘How to use jQuery 1.4 with WordPress’. No idea if any errors will happen, but what is going to be the official stance.
I can’t make it.. again.. so you’ll have to just get my input from here.
Nevermind / off by a week.
• Discuss options for plugin/theme repository disputes. Right now, plugin/theme authors don’t have a recourse when something is suspended or rejected. Perhaps a forum only for plugin/theme devs to discuss administrative issues?
Just so that it doesn’t get lost:
as it was postponed
Thanks. I put a blogpost online regarding “WordPress Coding Standards – How to go on?” and to gather some feedback previous to the meeting this week. Open to everyone who want’s to throw in some thoughts about the issue.
There needs to be a decision on how private content should work. There’s a cluster of tickets involving get_posts/get_pages, private post queries, and performance.
#4711 is the root of the problem: private posts aren’t included in get_posts or get_pages.
#4711 has two major side effects. #8592:
private pages aren’t available as parents in the edit dropdown, and #6939: private pages aren’t shown in menus even if the user is logged in and has permission to read them.
There are two proposed solutions: making private posts accessible only from the admin screens (#11697), and allowing admins to disable the feature altogether to get around the performance issues (#11375). (Personally, I’m not a fan of either. I’d rather see #4711 fixed.)
Comments on private posts/pages are also problematic. They show up in comment feeds (#11695) and the recent comment list on the Dashboard (#9144) regardless of the current user’s read_private* capabilities.
I’m sure Denis will chime in with anything I’ve missed, as he’s been heavily involved in all the tickets.
← Agenda for January 14, 2010 dev chat: – …
Summary of Jan 14th Dev Chat →
Subscribe to this blog and receive notifications of new posts by email.
Join 5,352 other subscribers