Launch the celtic knot generator.

Note: Requires a fairly modern browser.

Instructions

When you first load up the knot generator, you will see a 10×10 grid filled with the default cross-hatch pattern. Click on one of the red or blue control nodes to select it. Then click on another node of the same color to make a cut between those nodes. Click the same nodes again to remove the cut. Note that you can only create horizontal and vertical cuts, not diagonal ones.

Keep making more cuts to create your own celtic knot. Experiment with the cell size, string color and other settings. Once you’ve found a combination you like, you can download the resulting knot by clicking the “Download as PNG” button.

If you want to start over, click the “Reset pattern” button to go back to the default cross-hatch pattern. Alternatively, click “Randomize” to create a random symmetrical knot with the current settings.

Screenshots

A screenshot of the knot editor interface:

A basic example knot:

A more complex knot:

Setting the stroke color to white produces a different visual style:

Browser Compatibility

Tested in:

• Chrome 19
• Opera 11.62
• Firefox 11.0 (no HTML5 sliders)
• Internet Explorer 9 (no HTML5 sliders)

Somewhat surprisingly, Firefox turned out to have better canvas rendering performance than Chrome. On my system, setting the grid size to 40×20 and quickly dragging the hue selector in the color picker produced noticeable lag in Chrome, but was perfectly smooth in Firefox. Of course, that’s hardly a scientific test.

Possible Improvements

• Optimization.  Right now, the script is not optimized at all and can sometimes spike the CPU even on a relatively powerful system. It should be possible to improve the rendering speed considerably by, for example, caching and re-using identical image tiles instead of drawing the entire knot from scratch every time. Another thing you could do is limit how often the knot is regenerated when the user drags the size slider(s). Right now, dragging a slider can generate hundreds of image updates and cause massive lag.
• Add the ability to save/load knot patterns and link to saved knots. Should  be easy enough – just stick the pattern data in the URL #anchor.
• Add export to SVG.
• Refactor the renderer. For example, the tile drawing functions could be made simpler by treating cell size as a constant and scaling-up to the actual size with canvasContext.scale().

Final Thoughts

Overall, the canvas element turned out to be rather pleasant to work with.  The API makes sense and is reasonably intuitive. It also reminds me of Processing, which I have used several times before. The MDN canvas tutorial was very helpful for learning the basics.

Credit goes to Yusuke Kamiyamane  for the color picker icon and Anton Lopyrev for the Java-based knot generator that served as an inspiration for the UI.

function add_menu_with_notification_bubble() {
	$bubble = sprintf(
		' <span class="update-plugins"><span class="update-count">%d</span></span>',
		42 //bubble contents
	);
	add_dashboard_page(
		'Example Menu',
		'Example Menu' . $bubble,
		'read',
		'example-menu-item'
	);
}
add_action('admin_menu', 'add_menu_with_notification_bubble');

The resulting menu will look like this:

Security-wise, this is dangerous for two reasons:

• Most plugins are not designed to be accessed in this way and will simply crash. The error message, if any, can disclose sensitive information about your site.
• Most plugin developers don’t expect anyone to access the plugin .php files directly. Doing so may trigger a dangerous bug or vulnerability that they haven’t tested for.

While the chances of either happening are admittedly fairly slim, it doesn’t hurt to safe-guard your site from this type of attack. Luckily, disabling direct browser access plugin .php files is very easy. Just create a text file named “.htaccess” in your /wp-content/plugins directory and place this code in the file:

<FilesMatch "\.php$">
	Order deny,allow
	Deny from all
</FilesMatch>

Now anyone who tries to load a plugin PHP file in their browser will now get a “Forbidden” error.

A word of warning

This will break some plugins. While most plugins only need their CSS, JS and image files to be accessible via the web browser, a handful also rely on .php files being directly accessible (e.g. for AJAX or dynamically generated CSS).

If you find out that one of your plugins doesn’t work, create a .htaccess file in that plugin’s directory and place the following code in the file:

<FilesMatch "\.php$">
	Order deny,allow
	Allow from all
</FilesMatch>

This will re-enable browser access to .php files for just that directory.

Our transient will die naturally of old age once $expiration seconds have passed since we last ran set_transient()

What you might not know if you haven’t explored the source code of the transients API is that transients stored in the database* will not actually “die of old age”. Instead, a stale transient will stick around until someone tries to access it. Only then will WordPress notice that the transient has expired and delete it. If no-one ever attempts to read a stale transient – e.g. because the plugin that created it has been uninstalled – it will stay in your database forever.

* If you have a suitable caching plugin installed, transients can be stored in a fast in-memory cache like APC or Memcached instead of the database.

Fortunately, since the expiration time of each transient is also stored in the database, we can easily clean up stale transients with a little bit of SQL magic. Run the two queries below to delete all stale transients. You can use either phpMyAdmin or a plugin like WP-DBManager to execute SQL queries.

DELETE a, b
FROM
	wp_options a, wp_options b

WHERE
 a.option_name LIKE "_transient_%" AND
 a.option_name NOT LIKE "_transient_timeout_%" AND
 b.option_name = CONCAT(
		"_transient_timeout_",
		SUBSTRING(
			a.option_name,
			CHAR_LENGTH("_transient_") + 1
		)
	)
 AND b.option_value < UNIX_TIMESTAMP()

DELETE a, b
FROM
	wp_options a, wp_options b

WHERE
 a.option_name LIKE "_site_transient_%" AND
 a.option_name NOT LIKE "_site_transient_timeout_%" AND
 b.option_name = CONCAT(
		"_site_transient_timeout_",
		SUBSTRING(
			a.option_name,
			CHAR_LENGTH("_site_transient_") + 1
		)
	)
 AND b.option_value < UNIX_TIMESTAMP()

Note: Back up your database before running any of the plugins or queries presented below.

Delete inactive plugins and themes

Not only do inactive plugins and themes waste disk space, they also clutter your database with unused settings and other metadata. Remember: most plugins won’t delete their DB options and tables until you completely uninstall them. You will also continue to receive update notifications, which can be a distraction. Remove any plugins and themes you’re not using any more.

Delete orphaned DB options

As mentioned above, plugins should automatically clean up their database entries when you uninstall them. Unfortunately, not all of them do, which leads to some entries becoming “orphaned”. Use the Clean Options plugin to delete DB options left behind by those untidy plugins.

Delete orphaned database tables

First, use WP-DBManager to get a list of all tables in your database. Compare it to the list of WordPress core tables. Any table not on that list is part of a plugin. If you spot any tables that have been orphaned by uninstalled plugins, use the “drop” command to delete them.

Delete post revisions

The post revision feature can be useful, but it also tends to fill up your database pretty quickly since WordPress creates a new revision each time you edit a post. There are several ways to fix this problem.

Delete all post revisions

You can use WP-Cleanfix or WP-Optimize to get rid of any and all post revisions.

Delete only old post revisions

In some cases you may want to clean out old revisions while leaving the most recent – and thus most likely to be useful – revisions intact. This SQL query will delete only post revisions created before March 1st, 2012:

DELETE a, b, c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE
	a.post_type = 'revision' AND
	a.post_date < '2012-03-1'

Use WP-DBManager or a similar plugin to run this query.

Limit the number of revisions per post

Add this line to your wp-config.php file to limit the number of revisions to 5 per post:

define('WP_POST_REVISIONS', 5);

Disable revisions

Add this line to your wp-config.php to completely disable post revisions:

define('WP_POST_REVISIONS', 0);

Note that this does not remove existing revisions. Use one of the other techniques discussed above to do that.

Delete spam comments

Even small blogs can receive thousands of spam comments per month. If left unchecked, all the spam will gradually accumulate in your database, potentially slowing down comment queries and hurting your site’s performance. Make sure to regularly clean out the spam by clicking the “Empty Spam” button in Comments -> Spam.

Bonus tip: I strongy recommend the NoSpamNX plugin to anyone receiving large amounts of spam. It’s a great “first line of defence” and can be configured to discard spam comments immediately instead of storing them in the database.

Delete pingbacks

If your comments table still takes up a lot of space even after you’ve deleted all spam comments, consider removing some or all the received pingbacks. While pingbacks can be useful as a way to be notified when someone mentions your content, old pingbacks lose their relevance quickly. Pingbacks are also frequently abused by spammers.

This query will delete all pingbacks received before March 1st, 2012:

DELETE FROM wp_comments
WHERE
   comment_type = 'pingback' AND
   comment_date < '2012-03-01';

Scan your site for malware

Check that your blog is free from malware and suspicious code by scanning it with Sucuri.net.

Find and fix broken links

Use Broken Link Checker to check your site for broken links, missing images, removed YouTube videos and similar issues.

Delete unused post and comment meta

Unused post meta keys are another kind of database cruft that can be left behind by long-since-uninstalled plugins and themes. You can use the WP CleanFix plugin I mentioned before or WP-Cleanup to remove them.

Alternatively, if you would prefer to do it without a plugin, the following SQL query will also remove all instances of the specified post meta key:

DELETE FROM wp_postmeta WHERE meta_key = 'unused meta-key-name';

And this query will do the same for the comment meta table:

DELETE FROM wp_commentmeta WHERE meta_key = 'unused-meta-key-name';

Finally, if you have a lot of registered users, you might also want to check for and remove unused user meta keys. Here’s a query to delete an unused piece of user metadata:

DELETE FROM wp_usermeta WHERE meta_key = 'unused-meta-key-name';

Also, see this tutorial for a more in-depth explanation of how to find and remove unused custom fields with phpMyAdmin.

Remove unused tags and categories

If you have a lot of unused tags or categories on your site, clean them up to reduce the database size and gain a little bit of performance. Both WP CleanFix and WP-Cleanup can help you get rid of unused tags.

Alternatively, this set of SQL queries will accomplish the same task (props to 4 Rapid Development):

DELETE FROM wp_terms WHERE term_id IN (SELECT term_id FROM wp_term_taxonomy WHERE COUNT = 0 );
DELETE FROM wp_term_taxonomy WHERE term_id NOT IN (SELECT term_id FROM wp_terms);
DELETE FROM wp_term_relationships WHERE term_taxonomy_id NOT IN (SELECT term_taxonomy_id FROM wp_term_taxonomy);

Remove unused shortcodes

If you’ve been blogging for a while, you’ve probably run into this problem: you uninstall a plugin or switch to a different theme, and now your site is full of shortcodes that no longer work. Obviously, going back and editing each post one-by-one is not going to work. You need a way to automatically remove the unused shortcodes.

Well, Search and Replace is just the ticket. It lets you search your posts for a piece of text and replace it something else.

Alternatively, here’s a query that will remove all instances of the specified [shortcode] from your posts (props to WPRecipes):

UPDATE wp_post SET post_content = replace(post_content, '[shortcode]', '' ) ;

Note that the above only works with self-closing shortcodes. For self-closing shortcodes like “[shortcode] content [/shortcode]” you’ll need to use regular expression search.

Delete commenter’s user agent

For each comment your blog receives, WordPress also stores the comment author’s user agent (basically, the web browser fingerprint) along with the rest of the comment. This can be handy for advanced users, but most bloggers will never need this information. You can shrink your database a bit by removing the user agent records.

Run this query to remove the user agent information from your database (props to RSA Blog):

UPDATE wp_comments SET comment_agent = '';

Delete unused images

Free up some disk space by deleting images not attached to any post or page. Go to Media -> Library -> Unattached, select all items, choose “Delete Permanently” from the “Bulk Action” drop-down and click “Apply”.

Another option is to use Upload Janitor or WP CleanFix to automate the process.

Optimize database tables

It’s good practice to optimize your tables regularly. Database optimization helps keep site performance steady and is especially useful after you’ve just made large change to the DB (like cleaning up all post revisions and unused meta keys). You can use WP-DBManager to schedule automatic DB optimization. WP-Optimize also includes the database optimization feature, but does not support scheduling.

Resources

For reference, here’s a list of all plugins mentioned in this post (in alphabetical order):

• Broken Link Checker – scan your site for broken links.
• Clean Options – detect and remove orphaned DB options.
• NoSpamNX – block spam comments.
• Search and Replace - find & replace text in your posts, comments, etc.
• Search Regex – find & replace with regular expression support.
• Upload Janitor – find and delete unused images.
• WP CleanFix – delete post revisions, unused meta, and much more.
• WP-Cleanup – delete revisions, unused tags, post meta, etc.
• WP-DBManager – manage and optimize your database.
• WP-Optimize – remove revisions, auto-draft posts, optimize tables, etc.

Final note: As you may have noticed, many of the “clean up” plugins – WP-Cleanup, WP-CleanFix, and so on – have a very similar feature set. So which should you use? Overall, WP CleanFix seems to be the most comprehensive solution, so I would recommend that one.

a href=”http://wordpress.org/extend/plugins/broken-link-checker/”

An update notification for a theme not hosted on wordpress.org

Download

• Client library (requires PHP 5 and WP 3.0 or later)
• Example theme
• Example metadata file

License

This library is licensed under the GPLand is distributed free of charge. If you find it useful, consider making a donation. Commercial licensing (e.g. for projects that can’t use an open-source license) is available upon request.

Quick-Start Guide

There are two things you will need to do:

1. Create a publicly accessible “metadata file” that describes the latest version of your theme.
2. Add the update checker to your theme and tell it where to find that file.

First, the metadata file. Open your favourite text editor and copy the following JSON code into a new file:

{
  "version" : "2.0",
  "details_url" : "http://example.com/example-theme/details.html",
  "download_url" : "http://examle.com/example-theme/example-theme.zip"
}

Replace the placeholder values with your own data. As you can probably guess, version is the version number of your theme. details_url specifies the page that the user will see if they click the “View version 1.2.3 details” link in an update notification. Set this field to your “What’s New In Version 1.2.3″ page or the theme homepage. Finally, download_url is the URL where the latest version of the theme can be downloaded. This field is optional. If you leave it out, the user will still get an update notification when a new version comes out, but there will be no “update automatically” link. They’ll have to download and install the update manually.

Upload the metadata file to your website. You can use any directory and file name you like; just remember that the file URL should be accessible from wherever someone might install your theme.

Next, lets add the update checker library to you theme. Copy the “theme-updates” directory from the client library to your theme. Then add the following to your functions.php:

//Initialize the update checker.
require 'theme-updates/theme-update-checker.php';
$example_update_checker = new ThemeUpdateChecker(
    'example-theme',
    'http://example.com/example-theme/info.json'
);

Again, replace the placeholders with your own settings. The first argument should be the name of your theme’s directory. For example, if your theme lives in /wp-content/themes/my-theme/, use “my-theme” here. The second argument should be the URL of the metadata file you just created.

Congratulations, your theme now supports automatic updates :) The update checker will automatically query the metadata file every 12 hours, checking to see if a new version is available. If it finds one, it will display a standard theme update notification on the Dashboard. Your users will be able to install the new version with a single click.

The ThemeUpdateChecker class

Class constructorThe library is configured by passing a number of arguments to the ThemeUpdateChecker constructor. They are, in order :

• $theme –  The theme directory name, sometimes called the “slug”.
• $metadataUrl – The URL of the theme metadata file.
• $enableAutomaticChecking – Enable/disable automatic update checking. If set to FALSE, you’ll need to explicitly call the checkForUpdates method to, err, check for updates. Defaults to TRUE.

checkForUpdates()
Manually trigger an update check. This is useful if you want to do update checks on your own schedule. checkForUpdates has no parameters and does not return anything. If you want to actually retrieve the latest update, use requestUpdate instead.

requestUpdate()
Retrieve update information from the configured metadata URL. Returns either an instance of ThemeUpdate, or NULL if there is no newer version available or if there’s an error.

deleteStoredData()
The update checker stores various update-related bookkeeping data in a DB option. Call this method to delete that data. This is can be useful is your theme provides some kind of “uninstall” feature.

addQueryArgFilter($callback)
Register a callback for filtering query arguments. Whenever the update checker needs to retrieve the metadata file, it will first run each filter callback and attach the query arguments that they return to the metadata URL. This lets you pass arbitrary data to the server hosting the metadata. For example, commercial themes could use it to implement some kind of authorization scheme where only paying users get automatic updates.

The callback function will be passed an associative array of query arguments and should return a modified array. By default, the update checker will append the following query arguments to the URL:

• installed_version – the currently installed version of the theme.

This method takes one parameter – the callback function.

addHttpRequestArgFilter($callback)
Register a callback for filtering arguments passed to wp_remote_get. The callback function should take one argument – an associative array of arguments – and return a modified array or arguments. See the WP documentation for details about what arguments are available and how they work. This method takes one parameter – the callback function.

addResultFilter($callback)
Register a callback for filtering theme info retrieved from the metadata URL. The callback function should take two arguments. If a theme update was retrieved successfully, the first argument will be an instance of ThemeUpdate. Otherwise, it will be NULL. The second argument will be the corresponding return value of wp_remote_get (see WP docs for details). The callback function should return an instance of ThemeUpdate, or NULL. This method takes one parameter – the callback function.

The site is still in early beta, so some features may a little rough around the edges or just plain missing. Nevertheless, I encourage you to go check it out and let me know what you think. All feedback is welcome.

What already works

• Add/remove sites.
• Monitor multiple sites with one account.
• Automatic daily scans.
• Email notifications.

What doesn’t quite work

• The crawler that I use is slow to get going. Sometimes it can take ~30 minutes before any progress is visible.
• Redirects are currently not followed.
• There’s a fair amount of false positives. Luckily, most of them are temporary and don’t show up when using the “persistent” filter.
• The site could use some UX love.

Screenshots

I am starting a new WordPress blog, and no longer updating an old one. [...] How can I lock the installation of WordPress down so I don’t need to maintain it? I have seen someone suggest making a static version, which sounds like a lot of work.

The top-rated answer is very good, but overly complicated. It involves custom code and .htaccess modification. I think I can offer a simpler solution. Here’s how you can turn your blog into a static site:

1. Make a backup. Just in case.
2. Disable comments and any other dynamic features your blog may have, e.g. contact forms.
3. Install WP-SuperCache and set the cache expiry time to 604800 seconds (= one week).
4. Fire up Xenu’s Link Sleuth and tell it to crawl your entire site. This will make WP-SuperCache generate static HTML files for all of your pages.
5. Delete all .php files and drop the WordPress database.

With all PHP scripts deleted, “expired” cache entries will never be removed, so the server will keep serving the same cached pages forever. Congratulations, your site now static :)

Alas, the aforementioned SE thread is rather old, so if I posted my answer there, no-one would probably ever see it.

Over the last two months, I optimized this site to load almost 2x faster. After the optimization was complete, the amount of Google search traffic that it receives increased by a whopping 5 percent. Here are the specific numbers:

November 2010

• 4.5 seconds.
• 58 832 visits.

January 2011

• 2.2 seconds (-105%).
• 61 751 visits (+5%).

If I wasn’t deliberately looking for changes in my organic search traffic, I probably wouldn’t even had noticed! The upswing is so tiny it might as well be a random statistical aberration. In fact, there’s a good change that is all it is.

Either way, there is some value in this exercise – it provides an upper bound. If you speed up your site by 100%, you probably won’t see more than a 5% improvement in your search traffic. Underwhelming, that.

And a couple of charts for you:

Site performance history from Google Webmaster Tools

Google Search traffic

Both charts overlaid

The overwhelming majority of visitors never leave a comment. Chances are, most don’t even scroll down to the comments section. So why waste their time and bandwidth by loading avatars that they’ll never see? A better option is to delay the loading of avatars until the user has scrolled far enough to actually see them.

I also promised to post the plugin that would allow you to implement this feature on your own WordPress site. So here it is.

Download

lazy-avatars.zip (3 KB)

Usage

1. Install and activate the plugin.
2. Open your comments.php find a line that looks like this:

   <?php wp_list_comments(); ?>

3. Add this line above the wp_list_comments call:

   <?php do_action('enable_lazy_avatars', true); ?>

This will enable the lazy-load feature for the avatar images in your comments section. If you want to use it everywhere on your site – e.g. in the sidebar or the admin panel – you can instead add the line from step #3  to your functions.php file.

The way it works is that the plugin replaces all avatar images with place-holder <div>’s.  Then it monitors the scrollbar position. When one of the place-holders comes into view, the plugin creates a new <img> tag inside the place-holder <div> and sets its “src” attribute to the original avatar URL.

With regards to styling, each place-holder has any CSS classes that the original avatar image had, plus two  more – “lazy-avatar” and “pending”. The “pending” class is removed once the avatar has been loaded. You can use this to apply a custom style to avatars that haven’t been loaded yet, e.g. a by adding a spinning “loading…” icon as the background image.

Compatibility

The plugin has been tested in the following environments:

• WordPress 3.0.4 and 3.1-RC2.
• Firefox 3.6, Opera 11,  Chrome 9 and Internet Explorer 9.

It will probably work fine in older versions of Firefox, Opera, Chrome and possibly Safari (not tested). However, it will not work in any version of Internet Explorer older than IE9. This is because old versions of IE don’t support the addEventListener method and the pageYOffset property.

If you’d like to write your own image lazy-loading script that is fully cross-browser compatible, take a look at jQuery’s scroll and scrollTop methods. There’s also an inView jQuery plugin that could simplify the task even further.

The plugin also uses custom data- attributes to store avatar image URLs. This is, strictly speaking, not a standards-compliant thing to do (except in HTML5), but I’ve found that it works well enough in practice.