V2.8.3 Fixing admin edit panel blanking, non displaying screen panel , etc

I am posting this here because I am trying to get the attention of someone from the dev team so that they can look into the matter below for the current/next release. My fix (although it works) may not be appropriate for some reason of which I am not aware.

I have been doing some debugging of WP2.8.3 because my fresh (non upgrade) out of the box install of WP 2.8.3 on W2003/IIS6/MySQL 5/PHP 5 with no plugins and default theme and Gears NOT installed in any browser, failed to display a fully functional admin panel for a number of screens. Somethings like Edit worked in FireFox, but not in IE 7 and IE 8. Worse, the screen options menu would not display on any screen, so the option of setting up widgets using the add link was not available. (I actually turned this on manaually by issuing the instruction directly from the address bar).

In IE7/8, if you deleted the browsing cache of all files (nothing else), the post edit panel, for example, would display correctly (with all the tiny MCE buttons) but once you publish the post, the post content became white space (it is there – just white font) and the MCE buttons would vanish. This then became a permananent problem for new posts and editted old posts. Delete the history again, and you get one ok post edit, then the problems returns after publishing/updating.

Analysing what was happening showed that when the error occurred an object or function defined in a script referenced by the load-scripts.php call was seemingly not present.

Various other behaviours on other screens showed similar causes…So I turned on the debuggers on the server and one of the PC’s on my network and loaded the pages through the debuggers and took snapshots of the browser cache in IE7 before and after various operations to see what was going on.

In summary I ended up fixing everything (except the drag and drop widgets), including the non-displaying screen-options menus by changing the caching rule in the header of the page generated by load-scripts.php to “no-store”. As follows:

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.

So what is going on?

Well first it seems to me that the load-scripts header is wrong anyway (but that should not be causing the problem). As far as I can see, the code that generates the load-scripts line always adds a random string so that in theory the file reference is unique each time. Hence there is no need to set the browser cache to store the scripts until sometime in 2010, as the scripts reference is different with every call. Having said that, the scripts are pretty small anyway, so compared to an image, the performance gain from caching them is pretty marginal.

BUT given the reference is unique, it should not be causing the problem that the above solution fixes – but it is definately the case
that the IE 7 and 8 are caching the script as instructed in original the header, but NOT getting new copies of the scripts when the same page is executed, even though the calling line is notionally different because of the random string added to the ver parameter. Directly instructing the browser NOT to store the scripts file under any circumstances solves the problem.

Miraculously this fixes practically every display problem in the admin-panel (except for the dragging and dropping of the widgets) – but since the screen options menu is now available you can use the add link instead.

I hope this information is of use to someone from the dev team. I have copies of the before and after caches and (obviously) can easilly reproduce the bug if you guys can not reproduce it in your dev environments.

I can be reached via the contacts on https://www.bishopphillips.com/ if necessary (or I guess via my profile if that is accessible to dev team members).

Regards
Jonathan Bishop