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…


Using LiveCode (RunRev) with SDK Platform Android 2.2, API 8, revision 3

The current (LiveCode 4.6.3, Oct 2011) release of LiveCode for Android development does not accept the revision 3 directory structure of the Android 2.2 (Froyo) SDK and needs some directory structure tweaking as below:

Copy the folder




You need to do this when in the Edit menu Preferences dialog for the Mobile Support item, if it fails with an error message saying:
The chosen folder is not a valid Android SDK. Please ensure you have installed it correctly, and enabled support for Android 2.2 (Froyo).


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 :-).


Coding and Holding The Big Picture in Your Head

I find that I am often unable to complete some piece of code unless I have a mental picture of the whole thing in my head. And this is a huge problem. For small things, it is fairly easy to get a mental picture of what needs to be done and my coding happens fast. But for something that is larger, requiring perhaps a multi-step process with things that can go wrong in each or all of the steps, it is much harder. I keep procrastinating for days on end until my puny brain has wrapped itself around whatever needs be done end-to-end and I feel that I will be able to take care of all the loose ends and all corner cases are considered — mentally. Only then can I start coding.

But this method does not scale and also it’s hard to give a project schedule and tell when you’ll be done with some module :-(.

I need to figure out some way of divide-and-conquer programming where I don’t need to have the entire thing in my head, but have just pieces of it in my head at a time, code that piece and be comfortable that the particular piece has been coded correctly — and that the way it’s been coded it will interact correctly with all the other pieces making the old adage of the sum of the parts being larger than the whole come true.

Oh well. I guess I cannot be everything all the time. Back to wrapping my head around this current problem…why is it that people find web-development easy and I keeping finding it hard and wondering why no-one sees that it is complicated distributed programming? That things can go wrong anytime and everywhere.

How do you deal with coding of such nature? Let me know in the comments.


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