bishopj

Which version of PHP are your running?

As it stands, if the $post value is neither an object nor an array you will simply pass it through. Prima-facie your code is partially better, except that there is an unhandled condition – that of a scalar value for $post that was clearly meant not to arise.

The error is therefore before that function – not in that function.

Which suggests one of three things:
1. You have code mods else where that are wrong, or the upgrade did not replace all files in the original WP diretories
2. The database upgrade did not take, so you have a wrong type for that field (unlikely).
3. In the words of rumsfield…there are things that we know, and things we know we don’t know, and things we don’t know that we don’t know…

I suggest looking at what calls that routine. My install of 2.8.3 does not exhibit this error (running on PHP 5). Handling of input fields from post/get actions were one of the big messy changes made between PHP 3 and 4, and then cleaned up in early releases of 4.

I would first make sure that you have the version of php running that you think you have (although I would expect more extensive problems than this if you had the wrong version).

The standard advice with 2.8.3 seems to be to disable all plugins and then progressively re-enable them until the error resurfaces.

In v2.8.3 you can edit the header directly:

admin panel -> appearance -> custom header

Is that what you mean?

Also look at this thread (the fix repairs a number of admin-panel problems including the widget drag drop problem):

http://wordpress.org/support/topic/298603?replies=6

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):

http://myblog.com/wp-admin/widgets.php?widgets-access=on

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.

Regards
Jonathan Bishop
Bishop Bhillips Consulting

I posted this in another thread:

A number of users (like me) find they can not drag and drop the widgets in the admin panel, and usually also can not enable the accessibility mode in screen options because the screen options menu will not display.

There is a solution and here it is:

1. After logging into your admin panel as normal navigate to the widgets screen normally.
2. In the address bar of your browser edit the address by changing everything after the question mark to read:
?widgets-access=on
3. Hit return and all the widgets on your widget page should get an “Add” link on them. You can now click on the add link on a widget to add it to your theme by following the prompts on the screen.

(I worked this out by reading the code sent to the browser.)

Note the address in step to above will look something like this when you edit it:

http://myblog.com/wp-admin/widgets.php?widgets-access=on

Obviously //the mybog.com/ should be replaced with your domain and folder etc.