I think, therefore I am. I am, therefore I sail

Category: WordPress Page 3 of 20

Remove admin color scheme picker from WordPress Profiles

If you want to clean up the WordPress user profile page in wp-admin by removing the color scheme picker here is a quick snippet that will do the task quickly for you.

remove_action( ‘admin_color_scheme_picker’, ‘admin_color_scheme_picker’ );

Add HTML tags to the allowed tags list in WordPress

By default WordPress limits what HTML tags are allowed in post content. If tags that are not whitelisted are found in the content they will be stripped. It is possible add additional tags to the allowed list.

View allowed tags

To view the list of currently allowed tags you can use the following code:

add_action( ‘init’, function() {
echo allowed_tags();

Add to the allowed tags

In this instance I need to allow the iframe tag. Be sure to also specify the allowed attributes:

add_action( ‘init’, function () {
global $allowedtags;

$allowedtags[‘iframe’] = array(
‘src’ => array(),
‘height’ => array(),
‘width’ => array(),

Add allowed tags to the WP Editor

Using the above will allow the iframe tag in code, but what if you want to allow the iframe to be added using the post editor? There is another filter used by tinyMCE which also needs to be set:

add_filter(‘tiny_mce_before_init’, function( $a ) {
$a["extended_valid_elements"] = ‘iframe[src|height|width]’;
return $a

Script to convert MySQL collation from utf8mb4 to utf8

I ran into a strange situation with WordPress where the MySQL server did not support utf8mb4. I needed to quickly convert the tables back to utf8 to get the site running again.

Though this script does work I highly recommend if you are running WordPress that you upgrade your MySQL server to support utf8mb4 for security. WordPress made this change to fix a security vulnerability introduced by The Trojan Emoji.

echo ‘ALTER DATABASE `’"$DB"’` CHARACTER SET utf8 COLLATE utf8_general_ci;’
mysql -p$PASS -u $USER "$DB" -e "SHOW TABLES" –batch –skip-column-names \
| xargs -I{} echo ‘ALTER TABLE `'{}’` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;’
) \
| mysql -p$PASS -u $USER "$DB"

Migrate from CodeHighlighter to SyntaxHighlighter without altering past posts

For many long years this site has used the CodeHighlighter plugin to markup code. CodeHighlighter’s last update was in 2012, that is eons in computer time. If you paid attention you will notice that CodeHighlighter is one of my plugins. Why am I switching away you ask? CodeHighlighter’s code base is old, real old. It was old when I inherited the plugin and it needs a rewrite. A very significant rewrite that I simply do not have the time to do now. Alix Mills has a great plugin called SyntaxHighlighter that is currently maintained with regular updates so I am making the switch. The caveat is that CodeHighlighter and SyntaxHighlighter both use different syntax to mark code.

CodeHighlighter uses pre tags with a source language attribute like:

<pre lang=\"php\">echo ‘Hello World’;</pre>

While SyntaxHighlighter uses shortcodes named by the language like:

[ php]echo ‘Hello World’;[/php]

While making the switch I had two options; 1) Updates all the posts with markup (literally hundreds) or 2) Filter the CodeHighlighter marked on the fly into SyntaxHighlighter. I chose the second.

After strugglebussing with Ian Dunn and AJ Mallory at WordCamp Seattle I finally came up with a solution that is very quick and so far seems to work on all my posts. Drop this code somewhere and it will act as a shim, rewriting posts code markup on the fly, and very quickly too!

add_filter( ‘the_content’, function( $content ) {

if( 2 == get_current_user_id() ) {

$regex = ‘#\<pre lang=\"(.*)\"\>(.*)?\</pre\>#Uis’;
preg_match_all( $regex, $content, $matches, PREG_SET_ORDER );

foreach( $matches AS $m ) {
//echo ‘<pre>’; var_dump( $m );
$new_c = str_replace( ‘<pre lang="’ . $m[1] . ‘">’, ‘[‘ . $m[1] . ‘]’, $m[0] );
$new_c = str_replace( ‘</pre>’, ‘[/’ . $m[1] . ‘]’, $new_c );
$content = str_replace( $m[0], $new_c, $content );
return $content;

return $content;
}, 1);


Remove query strings from static resources in WordPress

Using tools such as Pingdom and Google PageSpeed Insights I commonly see a message simliar to the following from WordPress powered sites:

Remove query strings from static resources

This week I have been on a performance optimization kick for a client and have been using this site as a testbed for optimizations. By default WordPress appends a version number to all Javascript and CSS asset files going through the enqueue system but it is pretty easy to rip the query string out.

Remove the query string from assets

Removing the query string can be done rather easily. I tossed the following code snippet into an mu-plugin and it “just worked” to remove the ver query string from Javascript and CSS files. In most cases this is all that is needed to prevent query strings on these assets:

function blob_remove_script_version( $src ) {
return remove_query_arg( 'ver', $src );
add_filter( 'script_loader_src', 'blob_remove_script_version', 15, 1 );
add_filter( 'style_loader_src', 'blob_remove_script_version', 15, 1 ); 

Did it help?

Definitely maybe…

The site was already loading very quickly. Performance may have increased in the hundreds of milliseconds saved, but then again it could have just been some requests running faster than others. As we all know timing is not an exact science on the web. Not everything is happy in candy land though…

Caveats to removing the query string

Lets assume those few hundreds of milliseconds did give a performance gain; is it worth it? After chatting with the WordPress caching god Zack Tollman the answer seems to be a resounding “no”. Zack led me through a series of scenarios with the primary being updates to said assets.

Take this url javascript asset as an example: https://ben.lobaugh.net/site-functions.js. WordPress would spit out https://ben.lobaugh.net/site-functions.js?ver=4.0.1. Later on an update the url may become https://ben.lobaugh.net/site-functions.js?ver=4.2. Why would you care? Cache busting. That file contains essential functions for site operation. Without the query string your site visitors may be using a cached version of the js file. This could cause your site to be broken until the file expires from their local cache or they manually refresh. As the site owner/developer you do not have control over when that happens, however if you use that query parameter and change the version number the client will see it as a new asset and load in the new file and recache it. The first load may be a bit slower but subsequent loads will again be speedy.

But doesn’t the query string prevent caching? The short answer is no, the longer answer is it depend on the caching mechanism. Query strings are common place on the web today and in most cases these days caching mechanisms respect query strings and will cache the file.

Is there a better way to do this?

Possibly. Google actually recommends embedding the file version in the url path instead of using a query parameter. This does make it look like a second file and could make linking to the file a touch more difficult. Busting the cache with a new version in the url parameter is a form of a new url path though anyways. Does it make much difference beyond the performance testing tools in the everyday browsing experience? I will leave that to you to decide but my suspicion is probably not.

My takeaway

My takeaway from all this is that while there could be a slight performance gain from removing the query strings it is very likely not worth the headache that will be caused by updates to the site. In the WordPress world site owners are encouraged to update WordPress core and plugins/themes as they are available. Updates may be available on a daily basis. Having WordPress automagically take care of busting the cache for these assets and ensuring the visitor is always able to access the site is far more valuable than saving a few hundred milliseconds of time.

hello dog

Page 3 of 20

Powered by WordPress & Beards