This is the official blog for the core development team of the WordPress open source project. Follow our progress with weekly meeting agendas, project schedules, and the occasional code debate.
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.
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.
• 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?
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.
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 :
there are a lot of files to open,
some items are registered (scripts and styles) out of context (script-loader.php should only load generic js and css) ,
some files are loading code out of context (e.g. wp-admin/includes/template.php),
some code is duplicated n times for each admin page (e.g. the ‘action | action …’ code),
etc …
I personnally tried to solve this in my plugin MailPress (requires PHP5 but this code architecture can be implemented for PHP4 & PHP5):
Admin pages are classified as single or list pages.
list page is an extension of single page, of course.
All admin pages are defined in a class called MP_AdminPage extending a single or a list class.
As WordPress admin is going bigger and bigger, isn’t it time to reorganize this part of WP, to gain in
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.
wpmuguru, and 7 others are discussing. 
steph 10:35 pm on January 15, 2010 Permalink |
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.
TobiasBg 10:17 am on January 16, 2010 Permalink |
Just so that it doesn’t get lost:
as it was postponed
hakre 7:27 pm on January 18, 2010 Permalink |
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.
Mark Jaquith 2:53 am on January 18, 2010 Permalink |
• 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?
Shane 6:29 am on January 18, 2010 Permalink |
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.
wpmuguru 5:16 pm on January 27, 2010 Permalink |
I believe 1.4 is in trunk already.
Nevermind / off by a week.
jQuery 1.4 and WordPress 3.0 | the rabbit hole 6:34 am on January 18, 2010 Permalink |
[...] will bring this up at the next dev meeting, but as of right now there is no jQuery 1.4 in WordPress [...]
arena 1:51 pm on January 22, 2010 Permalink |
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
Peter Westwood 6:24 pm on January 27, 2010 Permalink |
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.
kelebek 2:22 am on April 3, 2010 Permalink |
I believe 1.4 is in trunk already.