Word count, Edit Post > Publish > Visibility, Published Date & Status "Edit" links don't work

[scaturan]

hosting platform:

Apache 2.2.23
PHP 5.4.10
FreeBSD 8.3
WordPress 3.5 (no modifications to codebase & themes, no plugins)

• client:

Mac OS X
Firefox and Safari

prior to upgrading to 3.5, Edit Post > Publish > Visibility, Published Date & Status "Edit" links worked as expected. I can make changes then hit Update.

after upgrade to 3.5, these Edit links no longer work. Tons of load-styles.php errors. Word count is always set to 0 - Quick Edit works just fine.

tw2113 (from #wordpress Freenode) suggested I enable script_debug in wp-config.php and that resolve the issues I was having. Word count now works also.

As tw2113 have mentioned, I shouldn't need to have script_debug enabled just to get your post editor working.

Any thoughts?

Please advise, thank you!

[alexvorn2]

the problem can occur if using the last trac version that comes with jQuery 1.9

[helen]

#22899, maybe?

[SergeyBiryukov]

Could you check if the change in [23201] fixes this for you?

[scaturan]

replaced ~/wp-includes/script-loader.php with https://core.trac.wordpress.org/browser/trunk/wp-includes/script-loader.php?rev=23201&format=txt

set script_debug false in wp-config.php - logged off, cleared browser cache, logged in, Edit a post > still same issues.

it looks like only script_debug true fixes it.

[scaturan]

a fresh install of WordPress 3.5 has the same issue. I used the latest.zip from WordPress.org
tested on Firefox and Safari

Anyone else able to reproduce it or is this something specific to my setup (PHP version 5.4.10)?

[ocean90]

Tons of load-styles.php errors.

What are these errors? What's the repsonse of load-scripts.php? (Check the page source for the link.)

[scaturan]

Found the problem...

LimitRequestLine 500 is set on my httpd.conf, globally.

By default, 8190 bytes is the maximum length per Apache HTTP Server documentation - beyond that, I have to recompile Apache manually.

after looking at my Apache logs, it looks like the problem is that the URI length of GET request for load-scripts.php is longer than 500 bytes, resulting in a 414 HTTP response error - hence not all the necessary scripts are properly loaded - hence the issues I was having.

Whereas when script_debug is set to true, the URI length is not an issue at all.

In a default WordPress 3.5 installation, what exactly is the total URI length of the GET request? Does it increase depending if plugins are used or on a theme's markup?

[scaturan]

this is the actual GET requests for a default install with no plugins are used and no modifications to the codebase.

GET /blog/wp-admin/load-scripts.php?c=0&load[]=jquery,utils,plupload,plupload-html5,plupload-flash,plupload-silverlight,plupload-html4,json2&ver=3.5 HTTP/1.1" 200 1258 144281 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20100101 Firefox/17.0"

144281 bytes out

"GET /blog/wp-admin/load-scripts.php?c=0&load[]=admin-bar,hoverIntent,common,schedule,wp-ajax-response,autosave,jquery-color,wp-lists,quicktags,jquery-query,admin-comments,sugg&load[]=est,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,postbox,post,thickbox,underscore,shortcode,backbone,media&load[]=-models,wp-plupload,media-views,media-editor,word-count,editor,jquery-ui-resizable,jquery-ui-draggable,jquery-ui-button,jquery-u&load[]=i-position,jquery-ui-dialog,wpdialogs,wplink,wpdialogs-popup,wp-fullscreen,media-upload&ver=3.5 HTTP/1.1" 200 1225 352075 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20100101 Firefox/17.0"

352072 bytes going out

when LimitRequestLine 500 is in effect for the <VirtualHost> container where WordPress is being served, here's the GET request.

"GET /blog/wp-admin/load-scripts.php?c=0&load[]=jquery,utils,plupload,plupload-html5,plupload-flash,plupload-silverlight,plupload-html4,json2&ver=3.5 HTTP/1.1" 200 1258 144281 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20100101 Firefox/17.0"

the second GET request ends up as 414 HTTP response.

[scaturan]

I'm not sure if this is considered a bug in WordPress per se.

But I couldn't find any documentation anywhere about load-scripts.php choking when LimitRequestLine is in effect and has a value smaller than what's being requested.

Sorry for the hassle, folks! :)

Happy New Year ya'll!

[scaturan]

looks like LimitRequestLine 600 works fine for my setup.

Thanks again!