Archives

Ideas matter

While I do not know anything about the motivation behind this software, I kinda like the idea. It shows creativity and inspiration. It's a pretty cool idea and something completely new (at least, I've never seen a similar piece of software).

Read more...

Fonts are a matter of personal taste, especially the size. People are different, some prefer smaller sized text, others can't stand it. Visitors have different browsers, are using different screens, different resolutions, DPI settings and even different zoom levels and if you are using a non-standard font for your page, browsers might have to substitute it with an available font. No matter how carefully you select the font and its size, it will most likely not please everyone. Allowing visitors to quickly change the text size and remember their preference is convenient and can improve reading experience.

The goal(s)

• Allow visitors to change the font size of articles in a convenient way, providing 2 simple buttons to increase or decrease the font size.
• Save the selection to a cookie, thus making it persistent for later visits.
• Make it look nice so that no ugly and disturbing page reflows happen due to changing the font size after the page has been loaded.
• Use jQuery where possible.

First, I only want to change the font size for the actual content. The header, footer and sidebar should not be affected, only the posts and pages, because this is what people are actually reading and where text size matters most. This is fairly easy to achieve because most WordPress themes use a wrapper class for posts, so it should be sufficient to change the font size for this class. For my theme, posts and pages are wrapped within a <div class="post"> and the actual content of the post (the article text or excerpt) is wrapped into another <div class="content">.

Read more...

I am still seeing it quite often: People using the <a> tag to insert anchors (link targets) in web pages. Doing so will instantly make your page violate XHTML 1.1 standards. The name attribute was dropped in XHTML 1.1, so anything like:

<a name="foo">...

can no longer be valid XHTML code.

The reason why it was dropped should be quite clear. Use the id attribute, simple as that. Using id attributes to mark sections of a page (for example, the container holding all the comments for a blog entry) is common practice anyway and important for many modern web technologies, because these technologies often need to address elements by their ID attribute values. It therefore makes sense to use them as link targets in longer documents.

The old <a name=""> notation is basically just creating unnecessary and avoidable code. That's why it was dropped and can be seen as obsolete.

Modern browsers can very well handle id attributes as link targets, but some older may not be able to do.

Summary: Create fully XHTML compliant asynchronous Facebook like and Twitter tweet buttons for your WordPress blog using a pure JavaScript approach and implemented as a simple WordPress template function. Small, clean and lightweight.

Yes, I'm talking about the Facebook like (or recommend) and Twitter tweet buttons. Implementing them on your site is fairly easy - Facebook has a developers page where the anatomy of a like button is documented and you can even use it to generate the HTML code. For twitter, you can find similar information here.

With all that information, it should not be hard to add such buttons to your blog by simply creating the necessary HTML code and fill in the permalink of the article to like or tweet. The result will be a page with working like and tweet buttons but the code will no longer be valid XHTML and all the IFRAMEs may delay the loading process of your page more than necessary. So, there must be a better way, right?

Read more...

A while ago I blogged about the Syntax Highlighting Evolved plugin for WordPress, a great and invaluable plugin to publish well-formatted and readable code in your blog articles. It is based on the well known JavaScript syntax highlighter by Alex Gorbatchev.

The difference to conventional syntax highlighters is that the formatting runs on the visitor's browser, using modern JavaScript DOM tree modification methods to convert the plain and unformatted code block (usually a <pre> or <code> element) into a formatted and syntax colored display.

The conventional method performs all the processing in PHP on the server and typically uses GeSHi, the most popular and complete syntax colorizer for PHP. GeSHi takes a chunk of code and produces the HTML- and CSS formatted output which can then be embedded into your blog post, wiki article or whatever else you publish. While syntax coloring and -formatting is not really complex, it involves a lot of text matching and "search and replace" operations and can therefore put significant load on your web server, unless you are using one of the more sophisticated caching solutions that allow you to serve static pages to most anonymous visitors.

Offloading this process to the visitor's browser makes therefore sense and can help with the sever load.

Read more...

I have long been looking for a plugin that would enhance WordPress' comment system with some AJAX features, specifically, it should:

• a) enable AJAXified comment posting without the need to reload the entire page after a comment had been submitted.
• b) enable AJAXified comment paging so that people who read larger amounts of comments do not need to reload the complete page.

There have been a number of solutions for both a) and b) but none that combined everything into a single plugin and some of the AJAX commenting plugins are outdated and incompatible with recent releases of WordPress and many modern themes.

Read more...

WordPress 3 has been out for quite a while now and they've already left the .0 version behind and are now at 3.1. For me, the release of 3.1 was a sign to re-evaluate a possible upgrade.

I've skipped version 3.0, because internal tests on my server have shown a significant drop in performance, especially script execution time. Now, with all the new features, a small drop in performance would be understand- and acceptable, but for me it was in the range of 40-50 milliseconds PHP execution time for every single page view - a bit too heavy for my taste.

3.1 (and possibly all the 3.0.x iterations before) have brought back some performance. It is still a tiny bit slower than 2.9, but it is now in an acceptable range and on the positive side, WP 3.1 puts less stress on the database and only slightly more load on the PHP side than my old version 2.9 did.

So it was time to upgrade my test installation, which is an exact copy of the live site to see if anything would go wrong and find possible problems with the (few) plugins I'm running.

Issues while upgrading from 2.9 to 3.1.1

The upgrade went smooth except one issue that caused my custom permalink structure (/category/pagename) to stop working. After some research I found one of the installed plugins to be the culprit. The multipage-toolkit plugin, which I had installed to allow publishing longer articles split into multiple pages, breaks custom permalink URLs. The fix is easy and is described here. After applying it, everything went back to normal and I found no further side effects. The (slightly) modified version of the multipage toolkit continues to work after the fix.