WordPress – Thesis Hosting

Need a WordPress Admin Password Reset?

So, you are locked out of your WordPress and you need in? Maybe the password reset function won’t work for you, because you don’t have access to the email anymore or you’ve instituted some security protocol that won’t allow a reset for an admin’s passwords or whatever.

I don’t know you. I don’t know your pain.

Whatever the situation, you need in. While I do have a tutorial here on adding an admin user to WordPress through the database, there is a much quicker and easier way.

Specifically, if you have FTP access and you know the admin username–and please tell me it’s not “admin” because I might have to slap you–then you can use this emergency password reset script.

You just save the code as emergency.php, upload it to the root of your WP installation, and visit the url of the script to reset your admin password. Then, please DELETE the script. Because any hacker yahoo on the planet could be searching for this very script and do the same dang thing you just did.

The internet being what it is, where info sometimes disappears into the ethers, I’m copying the code for you here.

If you fail to delete the script when you’re done, you’re totally on you own, man. Hope that helps and happy blogging!

WordPress Multisite Using CloudFlare on Individual Blogs

Trying to set up a WordPress Multisite using CloudFlare on individual blogs? I was. I just moved a WordPress (WP) Multisite subdomain installation and wanted to take full advantage of CloudFlare CDN for each for each of the sites blogs. It’s an awesome service, and free!

Using the lazy route of enabling CloudFlare on my domains via hosting control panel, it requires the www domain name prefix to invoke it’s magic. But the file uploads in a WordPress multisite don’t automatically include this magic.

By default, media uploaded through WP uses the path http://subblog.primaryblogdomain.com – we want to change that to http://www.blogname.com to be served up by CloudFlare.

How-to Instructions for setting up WordPress Multisite Using CloudFlare

In the WP backend (as Super Admin), on the toolbar, go to My Sites/Network Admin/Sites

Edit each site that has been set up on CloudFlare, and select the “Settings” tab.

Change the “site URL” field to be your fully qualified CloudFlare domain, as in http://www.blogname.com and note the blog ID number, from URL when you’re editing each blog. It will end with “site-settings.php?id=X” and we’ll make use of it shortly.

Test an upload to see it uses the proper url. Boom, it’s set!

If you are doing this on an installation that has been moved (i.e. already has posts), you’ll also need to update the posts table in the database. I like to use PHPmyAdmin for this. Hint: Backups are your friend!

Here is the query you’re looking at, where “X” is the ID of the wordpress blog if your tables are named named as mine are; you can easily identify each blog’s ID

UPDATE wp_X_posts SET post_content = replace(post_content, 'subblog.primaryblogdomain.com/wp-content/uploads/', 'www.subblog.com/wp-content/uploads/');

I would suggest leaving the upload path in the SQL command so you don’t inadvertently change something you didn’t want to change. Also, be sure it’s a correct upload path for your setup!

After you’re done, you can also add the CloudFlare WordPress plugin to see to it your stats and so forth accurately reflect your visitors’ locations. You will need to configure the plugin on each site of your installation individually.

I found I also needed to re-save my permalinks in some cases. I’m not sure if it was this operation that created the need or not. I was doing a lot of work on my install at the time, but if you’re getting 404 errors with post titles, give that a try.

That’s it–configuring Wordpress Multisite Using CloudFlare is not so difficult. Unless you have some image paths hard-coded in your themes, plugin or widget code, your WordPress should now serve all your images from Cloudflare instead of the local server. No plugins, no headaches. Just a little configuration change and some mySQL voodoo.

FYI, this information is offered AS IS, in the hopes it is of help to someone. If you break your Wordpress, I cannot fix it for you. I cannot answer WP support questions. This is what worked for me, period. Thanks for understanding.

Resolving WordPress Plugin Activation Error “Characters of Unexpected Output During Activation” & “Headers Already Sent” Php Error

“The plugin generated 3 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.” – WordPress Error

Not good, right? This was the error message I ran into updating a WordPress plugin that I happen to really like. Worse, it indeed generated the “Warning: Cannot modify header information – headers already sent by…” error message when my caching plugin was active. While things worked without my cache plugin, my cache plugin definitely took priority over the lightweight image box plugin that was throwing the errors.

I did the obligatory searching for blank spaces at the beginning and ending of implicated php files for the “headers already sent” error to no avail. A little more research led me to a quick solution, though.

Resolving the Unexpected Output During Activation Error

It appears this happens because straight UTF has a few invisible bytes in the encoding that identifies it as UTF, known as BOM. This confuses PHP. (Like my technical talk here? Har!) But it’s easy to fix.

Grab the free Notepad ++, open the offending php file from the plugin folder–identified via your error messages–and using the “Encoding” option on the Notepad ++ menu, change the encoding from UTF-8 to Encode in UTF-8 (without BOM). Save and replace it in the plugin folder. Woot!

Hope this helps somebody!

Widows Live Writer Error “Invalid response document returned from XmlRpc server” After WordPress Update Fix

My solution for the Windows Live Writer (WLW) error:

The response to the metaWeblog.newPost method received from the blog server was invalid: Invalid response document returned from XmlRpc server

Warning: This solution entails editing a WordPress core file and is therefore generally not recommended. If some PHP guru knows how to fix this with code in the functions.php file or something, I’m all ears!

Find class-wp-xmlrpc-server.php in wp-includes folder
In the code, locate the line “if ( strpos( $post_content, $file->guid ) !== false )”
Directly before it add another line of code…

if($file->guid && !($file->guid == NULL))

I’m usually not big on editing core files, but I use WLW to blog daily and this error keeps cropping up. It’s highly frustrating and there are numerous fixes around the web that are both more time consuming and not necessarily effective. This is a quick, down-and-dirty fix that will get you up and running.

Solution Courtesy “Stuff I Stumbled Upon Blog“

Manually Adding an Admin User to a WP Database

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. ((Big hugs and kisses out to DNA Web Agency for this uber-helpful information lifted for this tutorial.))

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:

user_login –username to access WordPress
user_pass – password – be certain to select MD5 from the phpMyAdmin Function dropdown menu; it’s stored encrypted)
user_nicename – how you’d like to refer to yourself, not login
user_email – email for this user
user_url – optional
user_registered – just select a date
user_activation_key – leave this blank
user_status – leave this set to 0
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.

umeta_id – automatically generated
user_id – ID of the user you just created
meta_key – wp_capabilities
meta_value copy and paste this:

[code]a:1:{s:13:”administrator”;b:1;}[/code]

Insert another row, with this information:

umeta_id – automatically generated
user_id – use the ID you created
meta_key – insert wp_user_level
meta_value – insert 10

Save your work and go log in!

Disabling WordPress Plugins When You Cannot Access Admin Area

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!

SQL: Closing Comments on WordPress Installation

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!

Mass Delete Pending Spam Comments from WordPress Database

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.

Moving WordPress Installation to New Domain – SQL

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');

Quickie – Disable WordPress Comments Temporarily

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.