WordPress Archives · Thesis Hosting

Mass Deleting Broken Shortcodes in WordPress

First of all, get yourself the (old-but-still-works) Search Regex plugin. Don’t edit these posts by hand or you’ll want to slit your wrists within minutes. Instead, you’re going to use Regular expressions and man, does this make your life easier! Don’t worry if you’re not a reg-ex whiz. I’m not either! But I figured it out so some examples.

Shortcodes can be deleted in two swipes if you have content wrapped in them you want to keep. Let’s say you had the misfortune to be tasked with cleaning up a site that used to run Avada as it’s theme so you have a billion useless shortcodes to clean up. So you have a bunch of this:

[fusion_whatver attribute="blah,blah,kill-me-now"]This is content I still need to keep, damnit![/fusion_whatever]

Not good. But you can resolve it in literally a couple minutes.

First of all, take a backup of your database first. DUH! You can break things and I’m not going to help you try to fix them. Then get busy with your plugin.

Opening Shortcode Search

@\[fusion.*?\]@

Your search will look something like this, with your actual shortcode text of course. This is saying, give me all the shortcode starting with the word “fusion” until the shortcode closing bracket.

The @ symbol is the delimiter, starting and ending the search expression. The forward slash is an escape character, specifying that left bracket is part of what you’re looking for in the text, not search instructions.

The dot and asterisk say to grab stuff after the beginning of the shortcode text specified, and the question mark basically says not to grab too much. This will pick up all the shortcodes start with “[fusion” up to right bracket. So this is what it would match from the example above.

[fusion_whatver attribute="blah,blah,kill-me-now"]

The content you want to keep won’t be touched. Leave the replacement field blank and pull the trigger. Then move to the next part.

Ending Shortcode RegEx Search

@\[\/fusion.*?\]@

This is looking for closing fusion shortcodes. The extra forward slash is to escape the backslash so again, specifying that is part of the actual search text and not instructions. It will remove any closing shortcode tags like the “fusion_whatever” in the example without messing up the content wrapped in the shortcodes.

And if you don’t want the content in between the shortcode tags? Use the initial statement but without the question mark and it will get it all Like this:

@\[fusion.*\]@

There is a preview function so you can check and make sure you’re actually doing what you want before you hit the button that is marked “Save. “If you know Regex you could do all sorts of weird and dangerous things with this but if you don’t, maybe this will be enough to get you going. Good luck!

Bonus Points: That penguin guy has a very helpful article on this! Thanks, Penguin dude.

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!

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.