Sh404SEF Alias Update Caused Website White Screen of Death

Well, this was a fun one to stumble across.

We’re big fans of Sh404SEF, and would wholeheartedly recommend using it as an agile manager of your SEF URL’s.

However, one fine day we got a URL update request from a client, and logged in to carry out the 2 second task.

The alias save seemed to “stick” (i.e. the Sh404SEF swirly kept going and going with no conclusion), so we clicked the close button, and carried on.  Upon checking our alias change in the website front-end, we discovered the dreaded white screen of death had decided to pay a visit.

As with any white screen of death, the first thing to do is start hunting for errors.

We’d recommend the following course of action:

1. Check your Joomla public_html (or www) folder for an error log.  Check out the errors, and follow accordingly.  If you have no error log there, check your /logs folder and see what’s in there.
2. If your error log files are pretty unhelpful, then switch on debug
   • via your Joomla administrator if accessible – Global Configuration -> System tab -> Debug System set to Yes
   • or via FTP – your configuration.php file, if the administrator is not accessible.
3. Set the debug reporting level to the highest available: Global Configuration -> Server tab -> Error Reporting set to Development
4. Now reload your website front end and see what goodies are now being displayed to you.

In our instance, we had a double whammy.

• Table ‘./raspberry/idoa_session’ is marked as crashed and last (automatic?) repair failed

So to fix this, we:

1. Logged into PHPMyAdmin
2. Selected the database
3. From the list of tables in the main window, checked the xxxx_session table, scrolled down to the bottom of the page, and in the drop down box to the right selected Repair.
4. Then, for good measure, we clicked on the database name again (in the breadcrumbs at the top of the page), went back to the list of tables in the main window, scrolled all the way to the bottom of the page, clicked the Select All link, and in the drop down box to the right selected the Check option.  We looked through the results to see if any other tables require a repair.  Thankfully, all looked to be ok.

Once the above was fixed, we reloaded the front-end of the website and got a debug message stating that there was a problem with the file:

/components/com_sh404sef/cache/shCacheContent.jadsgfjhgdhfgdsgyu637dcsdt83.php

And upon finding the above cache file via FTP we discovered it was huge.  1.5MB huge.

Now when I saw that, I thought to myself “you know what, Sh404SEF has been getting a little sluggish lately…”

So, the fix was:

1. Via FTP, copy the above mentioned Sh404SEF cache file locally (just to be on the safe side), and then delete it from the server.
2. Go back to the administrator and re-save the last Sh404SEF alias or URL change that you made before the fire and brimstone let loose.
3. Switch off debug and set error reporting back to default.
4. Go to your website front end and check that all is well.
5. Cry tears of joy.