Lost your admin password? Need in to the WP admin but client hasn’t given you access? If you can access the database directly–easiest using a tool like PHPmyAdmin–you can give yourself whatever access you need. ¹

Locate the right database–if you have FTP, looking at the wp-config.php file at the root of your WP installation is the fastest route. Otherwise, if you have multiple WP installs, check out the options table to match urls and make sure you’re looking in the right database.

In your wp_users table, you insert a new record:

1. user_login –username to access WordPress
2. user_pass – password – be certain to select MD5 from the phpMyAdmin Function dropdown menu; it’s stored encrypted)
3. user_nicename – how you’d like to refer to yourself, not login
4. user_email – email for this user
5. user_url – optional
6. user_registered –  just select a date
7. user_activation_key – leave this blank
8. user_status – leave this set to 0
9. display_name – what displays, can be same as nicename

Note the user ID, as you’ll need it for the next steps.

To give yourself access permissions, head on over to insert a record into the wp_usersmeta table.

1. umeta_id - automatically generated
2. user_id – ID of the user you just created
3. meta_key –  wp_capabilities
4. meta_value copy and paste this:

1

Insert another row, with this information:

1. umeta_id - automatically generated
2. user_id – use the ID you created
3. meta_key – insert wp_user_level
4. meta_value – insert 10

Save your work and go log in!

1. Big hugs and kisses out to DNA Web Agency for this uber-helpful information lifted for this tutorial.

If you”ve got a WP installation on a server not running under suPHP (i.e. requiring some folders set to 777 permissions), you may find your WP requests FTP info to do any updates, and get miscellaneous errors even with this info provided.¹ The AutoFTP plugin can help by saving the FTP credentials, but you may still see the errors. I did.

In addition to being annoying, this  can also be confusing for some webmasters. Since it’s a lousy idea to make your entire wp-content folder world-writable to allow for easier plugin updates, let’s look at a better solution:²

First, let’s add some protection for your wp-config.php file to your .htaccess file:

1

Verify your “wp-content” folder permissions are set to 0755.

Then, chmod your wp-config.php file to 0644.

In your wp-config.php file (at the root of your WP installation), add the code below. Be sure to provide the correct paths for your server, and do not add a port to your FTP host:

1

This should take care of the requirement to enter FTP information for every automatic update, and eliminates those annoying “cannot copy file” and “cannot move file” error messages when trying to do auto-upgrades of WP and plugins.

1. Why not run under the more restrictive permissions provided by suPHP? Maybe you want to run opcache  like e Accelerarter that requires a different configuration, for example.
2. Thanks to “detroiter” for this solution.

When you cannot access the admin of a WordPress installation because of a plugin issue, you can delete the plugins directly from a database management tool like PHPmyAdmin. (And if you can’t access the WP backend, there’s a good chance it is because of a plugin issue.)

This helpful tidbit comes from the WP FAQ

In the table wp_options, under the option_name column (field) find the active_plugins row

Change the option_value field to: a:0:{}

If you have FTP access, you can also rename your original plugin folder (/wp-contents/plugins) and and add an empty plugin folder. After you sign on to your WP admin area, you can delete the dummy folder and rename the plugin folder back to “plugins,” as it will have deactivated all  your plugins when you signed on with the empty folder.

Happy WordPressing!

During domain propagation when changing hosts for a WordPress blog, you may want to close comments to keep from losing anything. While you can certainly use the WP comment template technique, this is an especially convenient way of turning off comments en masse on a WP installation.

After transferring the blog databases to the new host, access PHPmyAdmin on the old host with this bit of SQL; if you have a different prefix to your table that “wp_” you’ll need to adjust the command accordingly.

UPDATE wp_posts p SET comment_status = 'closed', ping_status = 'closed' WHERE comment_status = 'open'

This approach also makes it very easy for a client to check domain propagation. If the comments are closed, the site is being served from the old host. If comments are open, it’s being  served from the new host. Easy!

If you’ve got 14,500 and some pending spam comments in your WP database, I feel your pain. I just transferred a WP site in exactly that state.

Fortunately, you don’t have to scroll through hundreds of pages of the comments moderation que, clicking away to get rid of the junk. A simple line of SQL is all you need to conquer the  spam dragon in a matter of mere seconds. Pop this query into something like PHPmyAdmin where you can run SQL statements directly, and you’re golden.

DELETE FROM wp_comments WHERE comment_approved = '0'

Ideally, run this on the source database before transfer to make your life easier. Why would you want to move thousands of spam comments anyway, right? As a plus, you may be able to import your database using PHPmyAdmin if you can get your database dump to a reasonable file size via deleting an out-of-control spamfest.

Note:  This command will delete ALL unapproved comments. No second chances, review or confirmation. Make sure that’s your goal before you go running SQL statements all willy-nilly. The management is not responsible for outcomes. Use the force wisely, Luke.

photo credit: chotda

A few database changes need to be done when moving WP from one domain to another; information below taken from a very  helpful article at My Digital Life:

To update WordPress options with the new blog location, use the following SQL command:

UPDATE wp_options SET option_value = replace(option_value, 'http://www.old-domain.com', 'http://www.new-domain.com') WHERE option_name = 'home' OR option_name = 'siteurl';

After that you will need to fix URLs of the WordPress posts and pages, which translated from post slug, and stored in database wp_posts table as guid field. The URL values in this field are stored as absolute URLs instead of relative URLs, so it needs to be changed with the following SQL query:

UPDATE wp_posts SET guid = replace(guid, 'http://www.old-domain.com','http://www.new-domain.com');

If you have linked internally within blog posts or pages with absolute URLs, these links will point to wrong locations after you move the blog location. Use the following SQL commands to fix all internal links to own blog in all WordPress posts and pages:

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.old-domain.com', 'http://www.new-domain.com');

TimThumb is a cool little thumbnail script in vogue for WP theme designers. It’s also notorious for not playing nicely with WPMU. Specifically, the rewrite magic used to run WPMU chokes the script in generating the thumbnail, as it’s looking for “/files/date/filename.ext” instead of “/blogs.dir/X/files/date/filename.ext”–where X is the $blog_id variable.

This is easy enough to fix if you want to hardcode your path into the script, but what if you want to set up a theme on WPMU that utilizes the script and open it to more than one blog? Maybe you’re a Thesis fan, perhaps? Well you can.

Please note: This technique requires hacking the timthumb script and as such, it’s never going to be an ideal solution. However, since many WP themes have timthumb deeply integrated and WPMU admins may well want to make such themes available to their users without requiring a users themes plugin, this IS an option that will allow multiple users to access a single version of the script and have it work properly.

Here’s how:

Towards the top of your script, you’ll need to include the wp-blog-header.php file.  This allows you to access WordPress variables from within the external script. This path worked for the Thesis theme setup, where the timthumb script, “thumb.php,” is located in the folder “/wp-content/themes/thesis_16/lib/scripts/” – you will need to adjust the path as appropriate to go from your actual script location up to the root of your WPMU install.¹

require_once('../../../../../wp-blog-header.php');

From this:

$src = get_document_root($src) . '/' . $src;

To this:

global $blog_id; $src = get_document_root($src) . '/wp-content/blogs.dir/'. $blog_id.'/' . $src;

And from this:

// check for unix servers
 if (@file_exists($_SERVER['DOCUMENT_ROOT'] . '/' . $src))

To This

global $blog_id;    // check for unix servers
 if (@file_exists($_SERVER['DOCUMENT_ROOT'] .'/wp-content/blogs.dir/'. $blog_id.'/' . $src))

That’s it. You now should have thumbs showing up where they belong!

Troubleshooting quick tips:

• If you get an “failed to open stream: No such file or directory” error, then your path to wp-blog-header file is probably off.
• If you’re getting a “file not found” error, trying replacing the $blog_id variable with a hardcoded number of the blog id to see if the problem is in your code itself or in accessing the variable.

1. Code note: There are probably better ways of doing this. I am not a programmer; I am a hack. Feel free to share your wisdom in the comments. Also, I’m squishing the declare global of $blog_id for these two functions we’re editing into the same line as the new code in the interest of keeping line numbers consistent. If that bugs you, then adjust as required.

Allowing people to set up blogs for WordPress MU at blog.domain.tld requires installing your WPMU in the site root and setting up wildcard DNS. In setting up my first WPMU, I ran across this tutorial by Matt Mullenweg of WordPress fame, linked from the WordPress MU docs.

Since I’m not the queen of DNS or anything, I checked with my admin folks to make sure I got the Virtual Host entries correct. I found out this is extremely easy to do if you have a cPanel setup.

Here’s How from my SysAdmin:

To add wildcard DNS and vhost settings in one swoop, simply add a new sub domain to the account and name it ‘*’ (the asterisk character). Make sure it’s document root is pointed to the same directory that your WordPress MU is setup in and cPanel will add everything else to all of the configuration files.

Sure enough, worked like a charm, took 30 seconds, and didn’t require anything scary like restarting Apache–there is no time that runs slower in the time-space continuum than waiting for httpd to restart, man.

This can now also be accomplished via the beta script, which contains an array with allowed hostnames. But still good info to know.

Love the TimThumb script for auto-generating thumbnails in WordPress, but feeling hemmed in by the requirement the image be hosted on your domain? If you use another domain for your image storage–to parallelize domains as recommended by Google’s Page Speed–you can, with a simple edit to the script.

Note: This only works for a using single, different domain from your blog, parked atop your current blog domain.

1. So first, get your domain set up and parked.
2. Then, change the upload settings in WordPress (under “Settings > Miscellaneous”) . Leave the “Store uploads in this folder” setting alone. But for the “Full URL Path to files, enter ” http://mydomain.com/wp-content/uploads”¹
3. Then, you dig into the script to make your adjustment. Find this line:

$host = $_SERVER["HTTP_HOST"];

And replace with this line:

$host = "mydomain.com";

Now, all your uploaded images will be stored in exactly the same folder as before physically, but use the parked domain’s url to display, which makes your site load faster since browsers only fetch a specific number of resources at a time, grouped by source domain. And your generated thumbnails will work without incident!

While I generally don’t advocate editing a core script file to get the desired behavior, it’s a small edit for a reasonably good payout of faster page load speed. Just make sure you note the changes someplace where you can find them so you’re not scratching your head as to why your thumbnails quit working when you upgrade the script next time around.

1. Without the quotes in the WordPress settings, and of course, replacing “mydomain.com” with your own domain. Duh.

Very handy if you’re moving a WordPress blog during DNS  propagation time. This is best suited to remove the ability to comment on their blog without changing the comment status of posts in their database. See the alternative SQL method to turn off comments and pingbacks on a WP blog in hosting transition here.

From http://www.theblog.ca/wordpress-temporarily-disable-comments:

1) Turn off the display of the comment form in your Comments file in your template. To do this, go to “Presentation… Theme Editor…” then edit the Comments file.

You’ll see something like this.

?php if ('open' == $post->comment_status) : ?>
<h3 id="respond">Leave a Reply</h3>

Replace it with something like this:

<?php // if ('open' == $post->comment_status) : ?>
 <p>Comments are temporarily disabled</p>

Note: I see no need for the author’s suggestion of renaming the wp-comments-post.php file because we don’t need to worry about the spam comments accumulating during a hosting move.