Getting WordPress V2.8.3 to drag and drop widgets and display the blog edit screen correctly – a debugging tale.

The Problem:

The latest version of WordPress is really very good, and once it is working properly is really quite impressive; but in our environment we had some serious issues that made it non-functional initially, requiring two days of solid debugging of the code.

While the general public part of the blog worked fine, the administration screen was essentially non operational.  Various menus would not display on the browsers (IE7 IE8 and FF 2.0) and the blog authoring screen would display properly only the first time a blog was authored on any given browser.  The second and later times, the button would disappear, and the text was white (making it invisible).   The public pages could not be configured properly as the widget drag/drop mechanism stubbornly refused to drag and drop, and the accessibility menu (the alternative widget configuration mode) would not display.

Searching the WordPress forum site and documentation revealed scores of people with the same problem (but by no means universal) and no practical solutions for solving it – except it a few cases where plug-ins were involved, and where the user was using google gears.  We had not plug-ins yet, and are not prepared to install google gears.  So we were faced with either removing the software or debugging it (is is open-source after all!).  So we decided to debug it instead.

Now thinking about what was happening we noted that, firstly, we did not install a little optional tool offered by the WP installer called Google Gears which caches scripts, etc on the browser to improve performance. It emerged later that, for some users, installing google gears fixed their widget-drag drop problem.  We excluded this because our development and support computers have to be as close to yours as we can get them – and larger corporates are not in the habit of allowing modifications to browsers, which Google Gears represents.  Secondly we have been pretty much stripping out google junk from most of our dev systems after we discovered some of there libraries in unauthorised locations (like their very annoying web address redirector that takes you to a google add page when the browser fails to find the site you entered because you typed a single character wrongly).  Lastly, we are increasingly using MS’s Bing since it is proving to be a better search engine than google lately – no advertisements and more accurate searches.  We started wondering if the people without the WP problems had all installed Gears.

Further thinking about the behaviour led us to test what happened when we deleted the browsing history. Surprise, surprise – the blog authoring page worked the first time after the browsing history was deleted – then became dysfunctional on the second access.  So clearly we were looking at some kind of caching anomaly.  Caching is the mechanism whereby the browser stores stuff locally to speed browsing and, theoretically, getting fresh copies if it has changed on the server.  This works fine with static web pages and images, but is less effective when pages are dynamically generated, but seem to have the same name.

So we turned on the debuggers and looked at what was happening.  Looking at the WP page code, however suggested that everything should be fine.  The place where, and the object about which, the debugger was complaining was theoretically correct from the perspective of caching in that it was uniquely named with each access.  Yet the debugger and the browser insisted that they could not find the object bing referenced and housed in the offending script. 

So we looked around on the server code and discovered that the WP programmers had done something a little odd, that in theory should not have mattered.  The WP app generates JavaScript libraries dynamically using a list of required libraries fed to a php page called load-scripts.php.  Most web apps tend to ether have a static JavaScript library that is fed to the browser once for all pages or use some mechanism of creating a dynamic library on a page by page basis. WP uses a shared php script that receives a list of required scripts  for that purpose.  To ensure updating of the script list, the calls to the load-scripts file added a parameter with random  string in the call line – so it should be refreshed each time the calling page executes.  Now, in the \admin\load-scripts.php file they had inserted a header command that defined to the browser the caching rules for the JavaScript code dynamically constructed by the php script.  This is where it got strange – the caching rule said that the generated page should expire some time 12 months from now – but the load-scripts call lines in the hosting pages were clearly intended to cause the load-scripts page to be refreshed with each access (which makes sense for a dynamically generated JavaScript library).  So the browser was being told to keep the script indefinitely, while the access model was designed to ensure it would never be required again.

Not Right! (As my four year old son would say.)  On the face of it, this should not matter – it is just wrong, but the browser should go away and get the scripts again anyway based on the uniqueness of the calling line, but either the browsers all share a common bug, or they are smarter in the cache management than we realise, because they were clearly not getting the scripts again – they had, after all, been told that library of scripts would be current until 2010, but then the DOM in the browser could not find the JavaScript objects, because they had not been retrieved for the current instance of the browser page, and the library containing them was not the same name as the expected one (or something like that!).   Either way, the fix was straight forward – change the caching rule to match the way the load-scripts.php page is called: 

1. Locate the file “\WordPress\wp-admin\load-scripts.php”
2. Open it in a text editor visual studio or equivalent is preferred, but notepad will do. DO NOT USE MS_WORD or similar word processing tool.
3. Locate the following line:
header(“Cache-Control: public, max-age=$expires_offset”);
4. Comment this line out so it looks like this:
/* header(“Cache-Control: public, max-age=$expires_offset”);
5. Add in the following line
header(“Cache-Control: public, no-store”);
6. Double check that you have written the above line EXACTLY as shown.
7. Save the file
8. Now go to your browser and delete all browser file history (sorry, but this is essential or you won’t see the fix.). On IE 7 you do this by:
a. From the menu bar: Tools/Internet Options
b. Select the General tab
c. Under browsing history choose “delete”
d. On the window that opens, choose “Delete Files”
e. Confirm and close windows
f. Close ALL open browsers and restart the browser.

The Result:

All menus in the admin panel now work, widgets can be dragged and dropped and blog editing works correctly – in IE 7, IE 8 and FireFox 2.0


8 Comments to “Getting WordPress V2.8.3 to drag and drop widgets and display the blog edit screen correctly – a debugging tale.”

  1. [...] here: Risk Think | Getting WordPress V2.8.3 to drag and drop widgets and … Related Posts:Drop Server Resource Consumption to 50% by Tuning WordPress in 10 …Meet Headway, [...]

  2. Naff says:

    Neat. Thanks for this. I had the same problem.

  3. Zoran says:

    Hi there,
    I have already seen it somethere…

    • Yes – probably from one of my posts on the WP forum. I put it in a couple of spots to make sure ppl could find it. Since it was a common problem when 2.8.3 first appeared, and nobody seemed to be proposing a solution that went to the cause. After that we decided to write it up here as well.


  4. Tnelson says:

    what a great site and informative posts, I will add a backlink and bookmark your site. Keep up the good work!

  5. JimmyBean says:

    I don’t know If I said it already but …I’m so glad I found this site…Keep up the good work I read a lot of blogs on a daily basis and for the most part, people lack substance but, I just wanted to make a quick comment to say GREAT blog. Thanks, :)

    A definite great read..Jim Bean

  6. PsyncThonsVon says:

    Hello! Base klooper notwithstanding my english jer, buti very nice re say gJ$)Kd!!!.

  7. Hey, I found your blog in a new directory of blogs. I dont know how your blog came up, must have been a typo, anyway cool blog, I bookmarked you. :) :)