Fix for garbled WordPress admin screen

IMPORTANT: See update to this below after the image

After logging in, the admin screen (dashboard) of my WordPress installation was all jumbled (see screenshot below). It seemed like a CSS or JavaScript related problem. Developer tools on Google Chrome reported several issues with locating the ‘jQuery‘ variable and with the wp-admin/load-scripts.php file.

After several attempts at searching the WordPress site and googling around, I came across this forum post. Based on this forum post, I found that first configuring define(‘SCRIPT_DEBUG’, true); in wp-config.php and then refreshing my admin screen fixed the problem. Subsequently I removed this config line and refreshed my admin screen again and it stayed fixed.

It seems like in the default configuration, WordPress compresses or combines several JavaScript and/or CSS files into a single file and this compression/combination was somehow garbled. Turning on the SCRIPT_DEBUG flag turned off this compression and removing it again probably re-generated some files fixing my problem — I don’t know for sure what actually helped! But it worked.

This was with WordPress 3.3.1.

Fix for WordPress Admin Screen Garbled/Jumbled
WordPress Admin Screen Garbled


This happened a second time to me and doing the same thing as described above fixed the problem once again. But in the process, I noticed that the time-stamps on all files in my blog directory had been somehow updated to today’s date. Also *every* PHP file now had some additional code at the top within a php tag in the first line. The php code was eval‘ing a base64_encoded string via the base64_encode api. Apparently, evaluating this encoded string injected some JavaScript into every php based page on the site. It looked like some mal-ware had taken over my site. Having evaluate my site indicated there was some mal-ware (you provide your URL and they crawl your site and tell you whether your site has any mal-ware injected).

To fix my problem, I used the following shell scripts to detect files having the problem and to fix them.

Remember that I provide these scripts as an aid to anyone encountering the same problem and provide them as-is without any warranty. USE THEM AT YOUR OWN RISK. PLEASE MAKE BACKUPS OF YOUR FILES BEFORE RUNNING THESE SCRIPTS SINCE THEY WILL MODIFY FILES. The regular expression I used worked for me, but they may not necessarily work for you. BACKUP, BACKUP, BACKUP. Also the below may not be sufficient to rid your site of this mal-ware. I don’t know what else needs be done to completely rid your blog of the mal-ware.

To find all the files with this injected php code, I used the following script:

find . -name “*.php” | xargs awk ‘FNR == 1 && /<?php.*base64_.*?>/ {print FILENAME}{nextfile}’

To remove this line of injected php code, I used the following script:

find . -name “*.php” | xargs sed -i ‘1s/<?php \/\*\*\/ .val(base64.decode(“.*==”));?>//’

(In the above scripts, please fix the quotes and the double-quotes — pre-formatted code doesn’t wrap, so had to use regular formatting which messes with quotes and such)

Now I wait and watch to see if the problem re-surfaces, if it does, then I know there is more I need to do.


This happened yet another time and I cleaned up in the same manner. I also searched some more and found that someone had installed the infamous c99 shell to allow them backdoor access into my setup. They were using this backdoor access to periodically inject additional php code into my php scripts. I found the c99 shell by searching for the string “gzdef.ate.base.._encode” (I am using . instead of the actual character to prevent security tools from thinking this page has a security issue. Replace the dots with ‘l’, ‘6’ and ‘4’ in order). I removed the backdoor, but I am yet to find the vulnerability in the existing script that was exploited by someone to install the backdoor shell in the first place. Looking…


Focus on the road not the wall

An interesting essay on being the CEO by Ben Horowitz. The ideas he suggests for managing your own psychology as a CEO also appears useful in general. The following stood out for me:

Focus on the road not the wall

Focusing on things that need to be done and not focusing on things that bring your project down can help you finish your project and not go crashing into a wall :-).


Ignoring white space when performing diff with Subversion

Subversion doesn’t seem to have support for ignoring white space changes when performing a diff against revisions. But it has an option to invoke an external diff utility. So I generally invoke GNU diff with it’s ignore white-space option as in below:

svn diff --diff-cmd diff -x -uw /path/to/file

Hosted SMTP / SMTP Relay Service

A few hosted SMTP (or SMTP Relay Service) providers (their servers are whitelisted, they manage bounces and can send out large volumes of email without attracting the attention of spam blacklisters or ISPs):

Amazon SNS : It seems like SNS can be used for this and would be a cheaper option than the rest, but no personal experience with it.


If you are going to print tablular information…

…in a console as a result of some debugging or control command, then try to ensure that any column that uses string or such similar output does not have spaces within that column. This helps with parsing output using tools like awk that are able to split by column and help with subsequent slicing and dicing of the information (specially when debugging).


keytool / jarsigner on ubuntu with openjdk version 6

keytool -genkey -keyalg rsa -keysize 2048 -alias jdkcert2048
keytool -import -alias jdkcert2048 -file ca-cert.crt
keytool -import -alias jdkcert2048 -file code.crt
jarsigner test.jar jdkcert2048

Notice in the above how I generate a Certificate Signing Request (CSR) using the alias jdkcert2048 and then I import the Certificate Authority (CA) Root Certificate and the code signing certificate using the alias jdkcert2048 and then later sign my jar file with the same alias.