Archive
Fix: WordPress administration UI content area showing up blank
Some time ago, at a WordPress 3.3 blog, a friend was getting a blank main area at the administration UI (just the menu was showing up there) when they visited the classic URL of the form http://somesite/wp-admin/. Here is a writeup of some notes I had kept while troubleshooting that issue and then upgrading to newer WordPress, with updated theme and plugins.
Visiting the problematic admin UI page online, I right-clicked and selected View Source in the browser and browsed to the bottom of it where it was showing:
That div tag wasn’t not closed with a matching closing div. Obviously some PHP code that was outputing that tag failed at that point.
For starters, I copied all files via FTP (with the FireFtp Firefox plugin) from the remote server locally (into my Dropbox). Useful for backup too in case I messed up something.
Could use grepWin tool (http://stefanstools.sourceforge.net/grepWin.html) to search all locally copied php files for “contextual-help-sidebar” and see which one was outputing this (if that string was assigned to some variable could then search again where that variable was being used).
However, WordPress also has debugging mode, so I edited wp-config.php and uploaded the edited version to the server replacing the old file. I changed WP_DEBUG setting to true below:
At the problematic admin UI online page again, I right-clicked and selected View Source in the browser and browsed to the bottom of it, this time reading:
This led to indentifying the exact place in the PHP code that was causing this issue:
So, I commented out the buggy PHP code, converting it to an HTML comment block instead of a PHP block:
and the admin UI was working again after I pressed ENTER at the address bar again to refresh the admin UI (http://somesite/wp-admin/) and it was not showing up fine (F5 function key didn’t seem to really refresh the site when using Firefox btw, probably some caching issue).
Then installed (the free version) of the WP Database Backup plugin for WordPress:
http://www.wpseeds.com/documentation/docs/wp-database-backup/
by searching for “Backup” at
http://somesite/wp-admin/plugins.php
and evaluating the different backup plugins listed there (judging from both their votes and by checking out if WordPress wasn’t saying at the details page of a plugin that it hasn’t been tested with that [old] 3.3 WordPress version that was on that site) and backed up from Tools/WP-DB Backup menu:
http://somesite/wp-admin/tools.php?page=wp-database-backup
Then Downloaded the MySQL backup (.sql) file, so now I could update Themes, then Plugins, then update WordPress to new Core from
http://somesite/wp-admin/update-core.php
Did keep copies of the wp-content/themes and wp-content/plugins folders before and after updating them of course.
After WP updated, it asked to update the DB, all went ok
Then did backup up again the database via the WP-DB Backup tool and went again to
http://somesite/wp-admin/update-core.php
and installed an update for one of the plugins (can also do update per-plugin from http://somesite/wp-admin/plugins.php)
Then backed up again every file (db not included there) via FTP and done.
Fix: WordPress media uploads not working on IIS
Using Microsoft Web Platform Installer (aka WebPI), one can easily install WordPress on IIS (together with PHP and MySQL database engine.
Btw, better install the latest PHP version from there and remove any older ones. Also do install from there the Windows Cache Extension for PHP for the version of PHP you’re using.
Windows Cache Extension for PHP stores the PHP bytecode, the compiled version of the PHP script, in memory making it available when subsequent executions of the same script are needed helping to increase the overall PHP application performance. The use of Windows Cache Extension for PHP allows the PHP bytecode to be generated only once and to be reused each time the same PHP script is executed.
An issue you will definitely face is when you try to use the Media Gallery feature of WordPress to upload some media asset. It will fail due to insufficient rights to the server filesystem. You should do the following to fix this:
- Right click the folder wp-content\uploads at your WordPress site installation (usually it’s a separate folder under c:\inetpub\wwwroot, or it’s flat inside the wwwroot folder). Select Properties from the context menu that pops up. At Security tab of the Properties dialog window, add the user IUSR (not IIS_IUSR) and give it Modify and Write access apart from the Read etc. rights it already has (but don’t give Full Control). Remember to do this again every time you may replace the site folder (btw to not lose your previous uploads, neither those access rights settings, you can “cut” that folder and paste it on your server desktop, then paste it back after you’ve replaced the wordpress folder contents with say some new version of the site code, deleting first the new wp-content\uploads).
- Either repeat the same process as above for folder c:\windows\temp (or whatever system temporary folder you’ve set at advanced system properties / environment variables dialog), or to be more secure in case some PHP bug gets exploited, you can create a separate temporary folder specifically for all PHP apps or even specifically for your wordpress site and using PHP Manager plugin for IIS (can get that via WebPI) you can select to manage all settings for the whole server or for your site respectively. Then you select one-by-one the settings that say c:\windows\temp\… (or any ones that say /tmp to be safe) and change them to use the temp folder you’ve created. Make sure you use double quotes for those string settings, since the PHP Manager plugin doesn’t seem to add them itself (not sure if not having them would cause problems to PHP when trying to read php.ini file).