[wp-trac] [WordPress Trac] #14579: Ajaxify list-type screens in the admin

WordPress Trac wp-trac at lists.automattic.com
Wed Aug 11 23:31:20 UTC 2010


#14579: Ajaxify list-type screens in the admin
----------------------------+-----------------------------------------------
 Reporter:  scribu          |       Owner:  scribu                 
     Type:  task (blessed)  |      Status:  accepted               
 Priority:  normal          |   Milestone:  3.1                    
Component:  Administration  |     Version:                         
 Severity:  normal          |    Keywords:  has-patch needs-testing
----------------------------+-----------------------------------------------

Comment(by nacin):

 Awesomesauce.

 ----

 Small things I noticed on first read. Note I only really looked at
 modified files:

 AJAX fetch-list looks like it needs a cap/referer check. Also, die('-1')
 on insufficient privs, die('0') on failure.

 default-list-tables.php -- I'm not sure I like an includes file having a
 require at the top. Also, should we split these tables up into individual
 files? Some of these classes are quite large.

 template.php, right line 1817, this should be show_ui, not public.

 minor style issues: false instead of FALSE, single if statements should
 not be on one line, we like our semicolons, CSS declarations should not be
 on one line, etc.

 looks like merging turned wp-admin/network/*.php back into ms-*.php a bit.

 <br class="clear"> in plugins.php and a few other places.

 _wp_search_sql() probably doesn't need to be in functions.php.

 Script localization needs the convert entities bit at the end.

 jquery.query.js should be minimized. Also, the crunching of admin-table.js
 looks like it didn't touch local variables, also. munging is fine.

 ----

 General concerns about back compat:

 We obviously changed quite a bit of markup, as well as some CSS. Should
 the old CSS selectors remain, in order not to hurt the styling of old-
 style tables by plugins?

 Renaming the "p" query arg on edit-comments, does that break anything? Is
 that the URL included in emails? Now it's longer… p should be an alias at
 least.

 Probably need to deprecate, not outright remove, WP_User_Search. I did not
 carefully read through a lot of the red, so there may be other things we
 can't get rid of without breaking a lot of plugins.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14579#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list