Not sure where to post this, so I am putting it in couple of spots as the issues this post addresses are popping up all over the place.
Firstly, for those that can't drag and drop widgets, and can't get the screen options menu to respond, you can turn on the accessibility mode manually by logging into the admin panel and entering (your equivalent of):
Secondly, 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.
In IE7, if you deleted the browsing cache of all files (noting 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 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 will post this in the dev blog as well so that someone who know what they are doing (ie. from the dev team), rather than me who is not really a PHP programmer can look into it.
Bishop Bhillips Consulting