WP-Admin Trailing Slash Problem

I had this WordPress wp-admin trailing slash problem for a couple of weeks now. When I don’t include a trailing slash after the wp-admin directory when logging in to WordPress, I will get a 404 missing page error. It’s a little annoying if you ask me, but it doesn’t really affect blog readers. It only shows up if you want to login to the WordPress Dashboard, and you forget to type the trailing slash at the end of wp-admin. Example below.

site.com/wp-admin/ <– this redirects to the WordPress login ok.
site.com/wp-admin <– this will result in a 404 missing page error.

So, I tried a couple of suggestions I found online, but the suggested changes to the .htaccess file didn’t seem to fix the issue. A couple of occasions, the suggestions were exactly the same code I already had in my .htaccess file. So, I tried a couple more suggestions. I noticed one blog post had a couple more lines in the .htaccess file that I haven’t seen in mine. So, I tried it and it worked. So, here are the changes I made.

I added these two lines to my .htaccess.

RewriteEngine On
RewriteBase /

I think the key code is in the second line. It basically establishes the base URL.

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.

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.

Linode Kicks Ass

Get a web server running within minutes. Choose a Linux distro, resources, and node location. That’s essentially Linode in a nutshell. I signed up with Linode about two weeks ago. I’ve been playing around with it since then. I can happily say that I’m very impressed with Linode. It has exceeded my expectations.

If you want total control of your web server, Linode VPS is really the way to go. You will be asked to choose server size when you sign up. They come in many configurations. I chose Linode 512. You also need to choose a data center location. There are six data centers worldwide. I choose the one in Fremont since I live in California.

So far, I’m loving the guaranteed server resources. My websites are running faster . I chose Ubuntu 12.04 LTS 32 bit because it’s a Linux distro I am very familiar with. Apparently, 57% Linode users have chosen Ubuntu as well. I already transferred a couple of domains over to Linode. The websites are screaming.

I plan to migrate more websites later. If you are curious about how Linode works, here is a short list of features to get you started:

  • Full ssh and root access
  • Guaranteed Resources
  • 4 processor Xen instances
  • Out of band console shell
  • Dedicated IP address, premium bw
  • Six datacenters in the US, Europe, and Asia-Pacific
  • HA and Clustering Support
  • Bandwidth pooling
  • Managed DNS with API

MySQL mysql_connect new_link

I want to share a database connection access problem I had last week, while working with a custom PHP script inside WordPress. I had created this WordPress Page Template containing some PHP code that needs access to the database. The problem was that the database connection for my custom script overwrote the WordPress database connection that was previously establish, causing certain parts of WordPress to not display properly.

It took me a while to figure out that it was the newer database connection of my custom PHP script that was causing the previously established WordPress database connection to disappear. Hence, certain parts of the WordPress page were not displayed. Little did I know, that the fix was quite simple. So, here’s a sample of my mysql_connect code. Prior to this line, I’ve already set the variables.

Mysql_connect

$db=mysql_connect($host,$username,$password);

The Fix

Simply add a fourth parameter called new_link and set it to TRUE.

$db=mysql_connect($host,$username,$password,TRUE);

What this does is basically telling mysql_connect to establish a new connection, while keeping the older mysql_connect connection around, in case we need to access it at a later time. It’s amazing how one little switch in a command can make a huge difference to this seemingly simple code. Anyways, adding a fourth parameter and setting it to TRUE was the solution.