Solving error 500 when activating a Wordpress Theme

Recently I was tasked of moving a web portal from an old architecture onto a more up to date accommodation.

My platform of choice to manage content is Wordpress nowadays. The reason is mostly due to the huge popularity of the software, the freedom from license costs and the painless upgrade/expansion of features.

It was required to preserve the same look & feel from the old portal (based on OpenCMS). So one of my first tasks was hiring a designer to replicate the same theme onto the new portal.

This was done in a satisfactory manner, the only problem occurred when moving from a test machine (my windows worstation running on xampp) to the pre-production machine (suse linux).

Wordpress would be running but every time I would try to activate the theme it would simply crash the whole software application and reply with a ERROR 500 message.

I've looked around the web and many people were pointing as culprit a badly written .htaccess file that halted apache from serving the page, some others advocated a lack of appropriate permissions and however, none of these cases helped my situation in concrete: permissions were correct, .htaccess was empty.

I needed information, to know more than a simple "ERROR 500" and get details. Apache provides a nifty reporting log that can be activated through .htaccess. At least in theory this would have helped me, however in practice I simply saw no log being generated where I wanted one.

The machine had been specially tailored to provide no details whatsoever, in order to prevent attackers from exploiting potential vulnerabilities (it's all about security by obscurity I guess..)

So, different approaches needed to be taken.

I remembered that PHP can be run from the command line too. And if it runs from the command line, we get output. Turns out that my instinct was correct.

When doing something as simple as "php index.php" from the SSH window, I was capable to see why and where the error was occurring. It was complaining about mb_substring(), this reminded me that I might be using a PHP version different from the one on the server and that was the correct situation.

To solve, I just remembered that "mb_" stands for multibyte and that previous PHP versions come shipped without that feature. This could be solved by simply removing the "mb_" from the conflicting commands and the legacy command would still be valid.

This solved the matter. After some ten edits I was seeing the intended template working on the new portal at the new server.


Talk about troubles.. I am just writing this here so that more people in future can keep some sanity if they ever stumble in similar situation.

Good luck!
:)