robinadr

Tagged code

Just a small release with one change: now, the text domain for the translations don’t load unless the WPLANG constant is both defined and not empty. I found that loading this added overhead to every page load, since the plugin file is always loaded even if the archives aren’t asked for.

This cut the runtime for this plugin from 20 to 30% in the Plugin Performance Profiler (P3) tests to an insignificant level. No other changes were made for this release.

Download it now.

I have been using SyntaxHighlighter Evolved to highlight code on here for a while, but it always had problems playing well with the Markdown plugin I use. I wanted to change to something that falls back gracefully, and doesn’t require any special markup outside of what Markdown can do.

I ended up using Google Code Prettify to highlight my code. It doesn’t use any weird markup (just adding a prettyprint class to the <code> block, and I can do all of it in Markdown. Here’s an example of a code block:

~~~ {.prettyprint .lang-php}
<?php
// Source code here
print( "some string" );
?>

The above Markdown ends up rendering like this:

~~~ {.prettyprint .lang-php}
<?php
// Source code here
print( "some string" );
?>

Because it doesn’t use any strange or custom tags (just a class on a <code> block), it will degrade gracefully into just a regular <pre> block without highlighting if the Prettify code disappears or isn’t working. To me, this is a much better solution than a [shortcode] like the ones that SyntaxHighlighter Evolved uses.

Here are the 2 lines of code that make it all work:

~~~ {.prettyprint .lang-html}


## Conflicts with WordPress

If your theme makes use of it, WordPress adds classes to the `<body>` tag through the [`body_class()`][4] template tag. Unfortunately, on some pages, these classes can sometimes conflict with the global styles used by the Prettify themes. For example, on my tag archive pages, the `<body>` tag had a class of `tag`, which is one of the classes Prettify uses to highlight code. The result was pink text everywhere on the page.

[4]: http://codex.wordpress.org/Function_Reference/body_class

To fix this conflict, I edited my Prettify styles to change the scope of the styles to those classes *within* `<pre>` and `<code>` blocks. For example, this is the original style rule:

~~~ {.prettyprint .lang-css}
  /* a markup tag name */
  .tag {
    color: #f2777a;
  }

I changed it to this:

~~~ {.prettyprint .lang-css} / a markup tag name /

content pre .tag {

color: #f2777a;

}

Slashdot just linked to an article citing a study about widespread vulnerabilities in a lot of popular WordPress plugins. I’m not going to link to the study itself because it seems to partially for selling the company’s services; however, the point still stands: a lot of WordPress plugins are written without security in mind. This only gets worse when code is abandoned but still running on production sites.

WordPress has generally gotten a tough rap when it comes to security (which hasn’t been without merit in the past). That being said, the team that works the WordPress core itself have really stepped it up in the past few big releases, likely because of the implications of running the code on WordPress.com. I have faith in the security of the core, but when it comes to plugins it’s a complete crapshoot. How can you try to deal with this?

Stay updated. Sure, it can be annoying. But it’s worth it. Since WordPress launched the plugin repository, updates show up right in the admin, so there’s no reason not to update. Also, if a plugin seems abandoned, you should abandon it too.

Get rid of the cruft. If you’re not using a plugin, deactivate it. Better yet, delete it. Consider every plugin you install a risk, and minimize these risks.

Install the popular options. I’m hesitant to suggest this, because popularity absolutely does not imply good code. However, when more people use a plugin, it isn’t crazy to think there is a better chance of a security hole being found and subsequently plugged. Do not use this as a rule, but more as something to keep in mind.

The WordPress Codex (documentation site) also has some tips for “hardening” your WordPress installation.

If you don’t want to deal with it, don’t host it. WordPress.com offers a great service you can even use your domain with, and they can do all the work of maintaining the back-end. Gone are the days where the only way to run WordPress is to host it yourself.

A Real Solution

If you think about these points, they really only involve minimizing your risk with band-aid solutions. They only cover up the real problem: there is no auditing or accountability when it comes to WordPress plugins. Plugin authors don’t have any incentive to patch their free plugins, other than goodwill.

The article also brings up another interesting point:

“First of all, Web admins think that if they are downloading these plug-ins from a reputable source, then there is an assumption that they are receiving a secure plug-in,” said Maty Siman, CTO of Checkmarx, in an interview. “In our opinion, that is the biggest factor.”

While there is no mention of any security process on the official plugin repository, this statement does have some truth in it. Downloading plugins from the official source for plugins gives a sense of confidence to an everyday user. WordPress is very easy to set up and use these days, and a lot of people won’t have the knowledge to know otherwise.

Any kind of real solution will require code auditing and regular checks of website, all of which is a lot of work. Perhaps it might be time to do what Apple does with their App Store, at least with regards to security. Audit the most popular plugins on the repository, and make it very clear that they are secure and will get patched promptly in the event a vulnerability is found.

However, this takes a lot of manpower (or womanpower), and is a tedious, time-intensive process. It’s hard to find people and pay them to get this done in the context of an open source project with open source plugins.

You should use the Use Google Libraries plugin instead.

Update: I’ve modified the plugin to use a generic URL (.../1/jquery...) which loads the latest 1.x version. That way I don’t have to change the plugin everytime jQuery is updated.

The ZIP file has been updated, just overwrite your old googlejs.php file and everything will be gravy.

In an effort to save bandwidth, I made a quick plugin to modify WordPress to use Google’s Libraries API, which offers a Google-hosted jQuery. Here’s the code in question:

function radr_google_js( &$scripts ) {
    $scripts->remove( 'jquery' );

    $scripts->add(
        'jquery', // shortname
        'https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js', // url
        false // dependancies (none)
    );
}

add_action( 'wp_default_scripts', 'radr_google_js' );

If you’re interested in using this on your own site, you’re welcome to download this quick plugin. Just follow standard procedure — unzip, copy to wp-content/plugins, and activate.

I came across an article on Learning jQuery about animating the scrolling between same-page links (i.e. anchors). Basically one block of code does this automatically, but I came across a problem that it was trying to do the same for anchors on other pages, which obviously wouldn’t work.

The line in question:

~~~ .prettyprint $(‘a[href*=#]’).click(function() {


This line selects all `a` elements with a hash (`#`) in its `href` attribute, but this also selects links to anchors on other pages. I changed it to this:

~~~ .prettyprint
$('a[href^=#]').click(function() {

So instead of matching a hash anywhere in the href attribute, this code only matches the hashes at the beginning. Other than that, the rest of the code is the same as in the article. You can see the effect here by clicking on the link in the footer to go back to the top of the page.