Regain Your WordPress Admin Account

So, I decided to get cute and changed my WordPress admin username to a username I wanted via a utility called phpMyAdmin. I went to the wp_users table and made a simple username change to the user_login field. I logged out and logged in back to the WordPress Dashboard. Disaster! I just lost both my WordPress admin and network admins rights. My former admin account has been reduced to a regular plebe. So, this is how a regular WordPress subscriber looks like.

It was a scary five minutes at WordPress land. I’m laughing now, but I wasn’t then. So, I went back to phpMyAdmin and also changed the user_nicename and display_name to the wp_users table hoping that would fix it. No cigar. Panic set in. After a few Google searches, I finally found the solution. Thanks to people who post their solutions online.

What a relief! First, you have to make sure you have the right user_id, especially if you have a multisite blog. Go to your wp_users table and make a mental note of your admin ID. It’s usually an ID of 1.

Next, I went to the wp_usermeta table and changed the wp_capabilities entry to a:1:{s:13:”administrator”;s:1:”1″;}.  The key here is the entry s:13. My account was reset to s:1 for some reason. I temporarily changed it to s:10, but it didn’t work. Setting it to s:13 did the trick. It worked wonderfully.

Now, I’ve regained all the admin rights for each blog that’s on the network, except that I’ve lost the Network Admin. Well, another Google search. Thank you. To make the story short, I also had to edit the wp_sitemeta table. Look for the meta_key and change to a:1:{i:0;s:11:”yournewname”;}. The s:11 is the length of “usernewname” which is 11.

That was the fix. Whew. A close shave. All in all, all is good once again at WordPress land. I am one happy admin. Just a bit on the adventurous side, but otherwise a happy camper. I’m posting this article because, I know some dufus admin in the future will probably do the same thing that I did. It wasn’t all that bad. It was just a little bit disconcerting when you lose all admin rights.

Simple Invoices 500 Internal Server Error

Simple Invoices is a free, open source, web based invoicing system that you can install on your server, desktop, or at a service provider. I installed Simple Invoices on a webhost company I rather not mention. The application was working fine, until they tweak their PHP settings several months back. As a result, the PDF export in Simple Invoices no longer worked. I was bummed. So, I was forced to run Simple Invoices from my home server, which was fun, but the issue was, I can’t access it outside of the house.

So, I decided to install Simple Invoices on my new account at Linode. Now, the funny thing was, the application won’t even come up. Not even a login page. So, I searched online for a possible solution to my dilemma. Some suggested to increase the php memory settings to 128M, but that didn’t work out for me. At one time, I thought I had a missing pdo_mysql module, but that wasn’t the case. Then, I stumbled into something that led me to the ultimate discovery.

Simple Invoices has this configuration file called config.ini located inside the config folder. One thing this application doesn’t like are extra characters inside the config file. I happen to like funky passwords with interesting characters like +-)!@#. My MySQL password happens to have a close parenthesis in it. Essentially, this extra character caused the entire application to not start. So, I change my password, and sure enough, the application worked.

So, if you ever get a 500 internal server error with the Simple Invoices application, make sure you don’t have any of those extra characters inside your config.ini file. I wasted two hours trying to fix this issue, only to be surprised by such an idiotic requirement. That means I can’t use difficult passwords for this application. I think this is either a design issue or a funny requirement of the Zend Framework, which by the way, Simple Invoices is written on. It was somewhat funny, but I wasn’t amused.

Use UUIDGEN For Passwords

An impenetrable system is only as good as its weakest password. Computers systems are often attacked using brute force. Most users tend to use really simple and easy to guess passwords. The use of complex passwords on the other hand, makes it almost impossible for them to remember. That’s why passwords typically fall in the 6-8 character range.

For systems and applications, that don’t need human intervention, when communicating to databases and other systems, a much more complex password can be assigned. These passwords typically do not need to be typed-in on forms, so they can be long, difficult and outrageous. There’s a Linux utility called UUIDGEN which randomly creates and generates unique universal identifiers.

A typical output would be:

150152b0-cd0e-11e1-9b23-0800200c9a66

These keys are perfect for systems and applications. For example, WordPress requires a username and password to talk to the MySQL database. The database credentials are typically stored in wp-config.php file. A key generated by UUIDGEN can be used in this scenario. This is just one example where long and difficult passwords can be deployed. They can be used for other purposes as well.

So, if you have access to a Linux system, to generate a unique key, all you have to do is type the command, “uuidgen” in the Terminal.

WordPress Blank Dashboard

I recently moved one of my blogs to Linode, a VPS hosting company. I noticed right away, when I logged in as admin, that the WordPress Dashboard, displayed a blank page. That’s not good. So, I started removing plugins by renaming the plugin directories until I found the offending plugin. Sure enough, it was a custom plugin I wrote myself.

Nothing has changed. The plugin hasn’t been touch. WordPress is the same latest version. The only thing that changed was the host server. So, I started looking into my PHP installation. What could possibly be missing? When I looked into my plugin code, I noticed some references to curl. I realized my server was missing a php5-curl module on the new host server.

A simple command to install php5-curl on the new server does the trick.

sudo apt-get install php5-curl

In this particular case, a missing module in PHP, caused the plugin to die unexpectedly, resulting in a blank Dashboard page within WordPress. Removing offending plugins temporarily fixes the issue, but it doesn’t get to the root of the problem. In my case, I was able to narrow it down to the missing PHP curl module that my plugin desperately needs.

In any case, everything is back to normal as expected, except for the blog, which is serving pages exceptionally fast, since I’m now running at Linode.

Install CodeIgniter The Secure Way

CodeIgniter is a PHP framework for rapid application development. It’s exceptionally fast and it comes in a small footprint. Installing CodeIgniter is fairly straightforward. You just upload the CodeIgniter files and folders to the directory of your choice.

But, for a much more secure installation, you should probably move the application and system folders above your webroot folder, so that nobody has direct access to it. In addition to moving them, you also need to set the full server paths in the main index.php. You will need to edit index.php found in the main CodeIgniter folder.

Change the following entries to:

$system_path - '/full-server-path/system';
$application_folder = '/full-server-path/application';

Save. That should do it.