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: Cleanup after upgrading from Windows 10 technical preview
I recently replaced the internal hard disk of my old Lenovo S10-3t Tablet PC with an SSD and installed Windows 10 technical preview, but recently realized the hard disk had almost run out of space.
Trying to figure out why, I realized that upgrading from the Windows 10 technical preview version to the final Windows 10 version (this happened automatically via Windows Update), left back a “Windows.old” folder at the hard disk root taking up 3.14GB, as if I had upgraded from Windows 7 or Windows 8 via Microsoft’s free OS upgrade offer (that offer is valid for a year btw, so make sure you don’t miss it).
You’ll notice the Disk Cleanup tool (you can find it by pressing the search icon (magnifying glass) at the Windows taskbar and writing “cleanup”, temporary Windows installation files are also mentioned as taking up an extra 3.22 GB, but there is some double counting there, since I ended up with 5.30GB free after cleanup, from around 200MB I had left on the hard disk before I run Disk Cleanup (note that I already had run CCleaner, but I hadn’t selected the option there to cleanup files from previous Windows installation, since I didn’t expect to have any such).
Note, that Disk Cleanup will even warn you that you won’t be able to restore the machine back to the previous Windows version (aka the technical preview), but why should you care to do so anyway?
Update:
To make some extra disk space and since I use a fast SSD, I had set Windows to compress the hard disk contents (one can set this option by right clicking the disk and selecting Properties), so probably there is no double-counting by Disk Cleanup dialog, it just must be showing the uncompressed space those things it cleans take up. So it could indeed be 3.14GB + 3.22GB of useless space taken up by updating Windows technical preview to the official Windows 10 release via the normal automatic Windows Update process, which is quite a lot.
Microsoft should show some warning to the user about all this extra space taken up (right away after updating and offer to remind them in the future again if they opt to keep the files till they’re confident the latest version works OK) and offer them the choice of cleaning this up
Another interesting thing I notice is that although I had selected the option to compress the drive and it had applied respective attribute to all files (showing a progress dialog), it didn’t remember that setting (not sure if I had set it before the upgrade), so probably it wasn’t compressing newer files.
Fix: can not delete install subfolder after upgrading phpBB on IIS
To upgrade a phpBB forum, one usually downloads an automatic upgrade package to the latest version, selecting on the website which version they currently have. The current version number at a phpBB installation is shown at the Admin Control Panel (there’s a link to it at the bottom of the main page of a phpBB forum usually) and there admins also see a warning if they have older version and links/info on how to upgrade.
After the correct automatic upgrade package is download, the install subfolder it contains has to be unpacked into the forum folder on the webserver. From that point on the forum is taken offline and users can’t log-in or see discussions anymore till the install subfolder is deleted.
The installation process is quite smooth, you just point the browser to the install subfolder (say http://localhost/myforum/install) and then it will show a step-by-step wizard, where it first updates the database to the latest version and then shows option to update the PHP files and other file resources at the forum either via FTP automatically or by creating an archive on the fly that you can download and unpack into the forum’s folder on the webserver, replacing any previous files with the same path/filename as the ones in the archive, without closing the upgrade wizard webpage. Then you tell the wizard to check again if files are now updated and you’re done.
However, there’s one last and very important step to bring the forum online again and let users log-in again to it and/or see discussions. You have to remove the install subfolder you had placed at the forum folder on the webserver.
If you use IIS (note that you can easily install WordPress and PHP on IIS using Microsoft Web Platform Installer), you may find that you can’t delete some subfolders nested a bit deeper under the install subfolder, like db and en.
I just had this issue while upgrading phpBB on http://robotics.mech.upatras.gr/forum and had tried various ways to delete the install folder, like the handy Take Ownership command on the Windows Explorer folder context menu, to no avail – that is till I realized it was IIS that was blocking deletion of those subfolders. So I opened up IIS Manager, did a Stop action on the webserver (it might have also worked if I had just stopped the respective website) and then I could delete the install folder from Windows Explorer. Started IIS again and all was up and running nicely.