Posts Tagged WordPress

WordPress visual editor mangling sourcecode

I tend to post quite a bit of sourcecode, such as bash scripts and PHP scripts. I use the SyntaxHighlighter Evolved plugin to highlight and colorize the sourcecode, as well as make it easy to copy.

Unfortunately, I’ve noticed that the WordPress built-in visual editor does a great job of mangling the code, especially by HTML-escaping certain characters.

I’ve found that installing the TinyMCE Advanced plugin has fixed the cause of it, as well as providing a ‘replace’ function which I can quickly use to clean up previously-mangled code.

I’ve gone through my posts and hopefully corrected any previously mangled sourcecode. I’d like to say thank you to everyone who has brought a piece to my attention.

I strongly recommend the above plugins.


Leave a comment

How to fix mangled HTML in WordPress posts using SQL

There are quite a few ways that source code and other preformatted text can get mangled in WordPress, such as a rich-text editor, or even by the export/import process.

When I speak of ‘mangled’, I mean unnecessarily HTML-encoded. Left and right angle brackets (the < and > signs), quotation marks (the ” symbol), and ampersands (the & symbol) get HTML-encoded to &lt;, &rt;, &quot;, and &amp;. This can seriously mangle sourcecode, as well as making other text seriously ugly.

It can become a huge time waste to try to go back and edit all your affected posts one at a time to fix mangled code, even with search-and-replace.

Instead, there’s an easy and straight-forward way to do it in SQL, that you can execute from phpMyAdmin, MySQL Workbench, or whatever you fancy.

Simply run each of the following queries on your WordPress database, and feel free to edit them as you like.

update wp_posts set post_content = replace(post_content, '&quot;', '"');
update wp_posts set post_content = replace(post_content, '&gt;', '>');
update wp_posts set post_content = replace(post_content, '&lt;', '<');

Have any others to suggest? Please feel free to do so in the comments below. Thanks!

, , ,

Leave a comment

How to find a keyword in your WordPress posts using SQL

If you have a lot of WordPress posts and might want to find all posts containing a certain keyword for any reason, you can start by using the following SQL code, which was taken from this post. I used this in phpMyAdmin for a MySQL database. Make sure you are in the correct database first!

You can substitute any keyword for ‘needle’ below, but you must have the single-quotes and percent signs around it.

SELECT ID FROM wp_posts WHERE post_content LIKE '%needle%';

Example: Let’s say you use the NG Gallery plugin, which has you add a tag to all your posts to include said gallery. Now you find to find all posts which have that NG Gallery tag in them. The following query would work:

SELECT ID FROM wp_posts WHERE post_content LIKE '%nggallery%';

This can also be built upon for find-and-replace operations.

Keep in mind, you can really muck things up using SQL. Make a backup first if you don’t know what you’re doing!

Questions, comments, and feedback are always welcome. Thanks!

, , , , ,

Leave a comment

Redirect non-www to www (and vice-versa) via htaccess

This is probably old news for a lot of folks, but it’s handy nonetheless and I often have to look up these .htaccess strings. Note that Apache mod_rewrite is required for any of this to work.

This (and it’s comments) are based on the Drupal default .htaccess file [License as of 9/30/11: GPL], because the Drupal .htaccess file explains it very well. Mind that lines starting with # are comments. Uncomment them to make them take effect.

Also, this should NOT be used with a WordPress install (it will result in a redirect loop). Instead, make the change in Dashboard > Settings > General.

RewriteEngine On
# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
# To redirect all users to access the site WITH the 'www.' prefix,
# ( will be redirected to
# uncomment the following:
# RewriteCond %{HTTP_HOST} !^www. [NC]
# RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# ( will be redirected to
# uncomment the following:
# RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
# RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]

Questions, comments, or feedback? Please leave a comment below. Thank you!

, , ,

Leave a comment

Determine if current user is an admin in WordPress using PHP

You can determine if the current logged-in WordPress user is an admin and take a certain action in WordPress using PHP. If you’re using a PHP widget plugin, you can use this code in a PHP widget to show or do something if the current user is an admin. You can also use this to limit the display of a block you might be working on to only admin users while you’re working on it.

This method is ideal because only admins have the manage_options capability.

Comments are welcome below. Thank you.


Leave a comment

WordPress 3.2 admin area display errors under suPHP

If you do the automatic upgrade to the recently-released WordPress 3.2 and notice the admin area displays incorrectly, you may need to reset some file permissions.

Simply run the following from your web root:

chmod -R g+r,o+r *

Should be all set.

, ,

Leave a comment

Forcing the WordPress administration over SSL

From the WordPress administration over SSL guide, add the following directive to your wp-config.php file:

define('FORCE_SSL_ADMIN', true);

This will cause logins and admin pages to force SSL sessions.

If you’re having issues making this work for you, check out my article involving Apache and SSL.

Questions, comments, and feedback are welcome.

, , , ,

Leave a comment

Integrating Smart 404 into the Suffusion WordPress theme

By default, WordPress does very little for a user who lands on a 404 or ‘Not Found’ page. The WordPress Smart 404 plugin can help with this, by attempting to match terms from the URL to published articles. This is something you want especially if you change your categories or tags because your old tag- and category-based URLs will not display anything useful to your visitors. Instead of losing them to a 404 page, show them what they’re looking for — or at least come close.

I use the Suffusion theme here on my blog, and I know it’s a very popular plugin as well, so here’s how to integrate Smart 404 nicely within Suffusion.

Obviously make sure you have both the Suffusion theme and the Smart 404 plugin installed and activated.

Open the theme editor by going to Appearance > Editor and load the 404.php file, change it to include the smart404_suggestions PHP function call as follows:

+ &lt;?php
+ if (function_exists('smart404_suggestions')) {
+ echo &quot;<br /><br />Here's some posts that may be close to what you were looking for:";
+ smart404_suggestions();
+ echo "<br /><br />You might also try searching.";
+ }
+ ?&gt;
  </div><!--/entry -->

This wraps the smart404_suggestions function nicely in a PHP function_exists call, which will prevent PHP errors if you later decide to uninstall the plugin.

Be aware that if you update your theme at any point, you may have to redo this edit.

Questions, comments, and feedback about this are welcome and appreciated. Thank you!


Leave a comment

My suggestions for WordPress plugins

Here’s my suggestions for a great set of WordPress plugins. The descriptions provided here are from the plug-ins themselves, and the links go to the plugin page on You can also go to your ‘Plugins’ area in your WordPress dashboard to search for and install any of the below plugins easily.

Bad BehaviorDeny automated spambots access to your PHP-based Web site.

Contextual Related PostsShow user defined number of contextually related posts.

Fast Secure Contact Form – Fast Secure Contact Form for WordPress. The contact form lets your visitors send you a quick E-mail message. Super customizable with a multi-form feature, optional extra fields, and an option to redirect visitors to any URL after the message is sent. Includes CAPTCHA and Akismet support to block all common spammer tactics. Spam is no longer a problem.

Fluency Admin – Give your WordPress admin the Fluency look, Fluency 2.4 is the latest update and is compatible with WP 3.1.x.

Google XML Sitemaps – This plugin will generate a special XML sitemap which will help search engines like Google, Yahoo, Bing and to better index your blog.

Jetpack by – Bring the power of the cloud to your self-hosted WordPress. Jetpack enables you to connect your blog to a account to use the powerful features normally only available to users.

Simple Facebook Connect – Simple Facebook Connect is a series of plugins that let you add any sort of Facebook Connect functionality you like to a WordPress blog.

Simple Twitter Connect – Makes it easy for your site to use Twitter, in a wholly modular way.

WP-PageNavi – Adds a more advanced paging navigation to your WordPress blog

What plugins do you use on your WordPress-powered blog? Have any to recommend? Are you a plugin author and want to “plug” your plugin? :) Please feel free to leave a comment below!

, , , , ,

Leave a comment

WordPress, suPHP, and Ubuntu Server 10.04

If you have WordPress running under an unprivileged user account, you may have noticed that when trying to install or delete a plugin that it prompts you for FTP information. This is due to a rather unintuitive way that WordPress checks for file access:

The following code is from the get_filesystem_method() method in the wp-admin/includes/file.php file:

if( function_exists('getmyuid') && function_exists('fileowner') ){
    $temp_file = wp_tempnam();
    if ( getmyuid() == fileowner($temp_file) )
        $method = 'direct';

This code creates a temporary file and confirms that the file just created is owned by the same user that owns the script currently being run. In the case of installing plugins, the script being run is wp-admin/plugin-install.php.

This may seem a little counter-intuitive, since the only thing WordPress really needs to be able to do is write to the wp-content/plugins directory.

If you’re on your own server (i.e. your own box or a VPS) and not worried about security implications, you can simply make the files owned by your web server process (usually www-data or nobody). This will have WordPress’ check succeed and no longer ask for your information.

If you’re on your own server and running a shared hosting environment, or just care about the security implications, you should install suPHP.

What are the security implications? If all web files are owned by the web server process, it’s extremely easy for someone to introduce malicious php code which can affect other sites on the server. Since the web server process has access to all of the web server files across the server, malicious code would have no problem gaining access to other files and directories on the server.

suPHP, configured correctly, causes all php scripts under a defined directory (usually /home) to run as the user account they are owned by. It also enforces other security measures, such as requiring that directories and files do not have write permissions for anyone other than the user.

I could go on and on about what it does, but my biggest struggle has been getting it to work. Installation is easy, but it’s painfully clear it does not work out of the box. After dozens of searches I found varying different ways of making it work, but sometimes drastic and not clean nor easy, few didn’t require recompiling something (which I wasn’t going to do), and none of them seemed to work.

After more than a day of searching and testing, I finally came up with a simple, elegant, working solution. Note that this was written and based on Ubuntu Server 10.04 64-bit, and libapache2-mod-suphp 0.7.1-1 and may or may not work for other platforms.

Install suPHP:

apt-get install suphp-common libapache2-mod-suphp

Edit the sites-enabled/xxxx.conf file for your VirtualHost

Inside your directive, add:

php_admin_flag engine off
AddHandler application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php
suPHP_Engine on

Lastly, edit /etc/suphp/suphp.conf and under ;Handler for php-scripts (at the bottom) change:




Restart apache and all should be well.

/etc/init.d/apache2 restart

Note: You might get an error message like the following:

Syntax error on line 7 of /etc/apache2/sites-enabled/
Invalid command 'php_admin_flag', perhaps misspelled or defined by a module not included in the server configuration

In this case, check that you actually have the Apache PHP mod installed and enabled. In can get uninstalled or disabled on occasion when upgrading Apache. Here’s how to reinstall/reenable:

sudo apt-get install libapache2-mod-php5
sudo a2enmod php5

Checking that it’s working

Create a phpinfo.php file with the follow contents:

<?php phpinfo(); ?>

Call it via your browser and check the Server API line near the top: CGI / FastCGI means suphp is working. Anything else means it’s not.

Suphp is slow!

Yes, unfortunately suphp is slow. Suphp runs PHP scripts in CGI mode, which reportedly causes them to run slower. I would argue that the security advantages outweigh the need for fast scripts, but each situation is unique. You have to decide for yourself.

500 Internal Server Error

If you’re getting the 500 Internal Server Error, it means that suphp is probably working, but for some reason it won’t allow the script to run.

Check that you don’t have any PHP opcode caching (APC, etc) running. If you are running any type of PHP opcode cache suphp will never work. You must disable your opcode caching. If you’re using APC, you can disable it system-wide by simply editing /etc/php5/conf.d/apc.ini and commenting the line out with a semicolon as follows:


Another element of importance is file permissions. SuPHP will fail (with a 500 Internal Server Error) any file that has permissions which are not allowed, as defined in /etc/suphp/suphp.conf. For example:

; Security options

Any file or directory with the attributes defined as allow=false will fail. Based on the configuration above, any file that is group- or world-writable will automatically fail. Same with directories. It’s best to leave these options alone (instead of changing them), and change the permissions on your scripts instead.

However, it is supposedly possible to disable it on a per-VirtualHost basis. I haven’t tested this.

Also check that your /var/log/suphp/suphp.log file isn’t over 2GB. If it is, rotate it or delete it.

If all else fails, check /var/log/suphp/suphp.log and /var/log/apache2/error.log for hints.

Many thanks to all of the blogs and articles that each held a piece of this puzzle. :)

, , , , , , , , ,