Archives

Sometimes, when you activate a plugin in the admin panel, you may see an error message like this:

The plugin generated 1 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.

This is usually caused by additional white spaces or empty lines at the beginning and/or end in one of the plugin's PHP files. PHP files should start with the <?php tag in line 1 column 1 and end with a ?> on the very last line. Additional empty lines before the starting- or after the closing tag can cause this (basically harmless) error.

Read more...

Pages do not offer manual excerpts by default

So, I wanted to add a small modification to my WordPress theme to use the (manual) excerpt as a meta-description tag and found out that there is no way to set the excerpt for pages but only for posts. Really? I found that hard to believe.

The truth is that pages can have excerpts, but they are disabled by default for some unknown reason. I'm sure there is even a valid reason, but I still want to use excerpts for pages.

The solution is actually a one-liner and can be added to any theme.

Read more...

The crux with the Like

As a matter of fact, there are a lot of privacy concerns with the viral Like and Tweet buttons that appear almost everywhere on the net. While the feature itself is nice and can certainly help to attract visitors and generate traffic, people often fail to see the risks. Do you really want allow Facebook to track ALL your surfing activity, because that's exactly what they can do with these buttons?

When you are logged into your Fb account (and I think, most Facebook users are permanently logged in most of the time) AND have your browser configured in a way that makes it possible to use the Like buttons (it must, at least, grant read access to 3rd party cookies), every page you visit that embeds such a button could - at least in theory - be tracked by Facebook. In theory, they know what pages you visit and can connect your surfing behavior to your account profile. Whether they do this or not isn't really relevant. Maybe they only do it for certain pages, or don't do it at all. Maybe they'll do it in the future - nobody really knows. What matters is that these buttons build the technical foundation to track users.

Read more...

One step further

Blue admin theme

The beta phase for the next major WordPress upgrade continues with the second public beta version, released today.

Noteworthy changes in Beta 2

• The blue admin theme has been finished and provides the same, new and smoother look as the previously updated gray color theme.
• The bundled jQuery was updated to version 1.6.1. This should not cause any troubles, but if you absolutely need to use a different (=older) jQuery version than the bundled one - here is how you can use any version of jQuery in the frontend while keeping the bundled version for the admin backend.
• Support for Internet Explorer 7 was improved and the admin panel should look better in this old and outdated browser.

Release schedule announced

According to the developers, the final release of WordPress 3.2 should be out by the end of June 2011 and there will be at least one (possibly more) release candidates before.

At a first glance, I did not find any problems except for the issue with the disqus plugin, which can be fixed easily. As always, you should not use the beta version on a production site, unless you have taken steps allowing you to quickly revert to a backed up stable version.

Disqus plugin breaks admin area of WordPress 3.2 beta

After installing the disqus plugin in WordPress 3.2 beta1, I began to notice severe problems in the WordPress admin area. Basically, all JavaScript related things stopped working - the sliding menus on the left did no longer respond and many other things were broken as well.

Using Opera Dragonfly, I quickly found a JavaScript error:

Uncaught exception: Syntax error, unrecognized expression: [href=edit-comments.php?page=disqus]

This is caused by a change in jQuery which was upgraded to version 1.5.2 in WordPress  3.2. Unquoted selectors are no longer allowed in jQuery 1.5.2, so this is a fairly easy fix.

Read more...

One thing I didn't know a few years back when I installed WordPress as a newbie was a technical issue with custom permalink structures. I figured that %category%/%postname% looks nice and it also was recommended by many so called SEO experts, so that's what I had chosen.

Now, years later, I have often read that using a non-numeric first element for a custom permalink structure is a very bad idea and the general advice by WordPress experts is to not use %category%, %tag% or %author% but instead %year% or %post_id% .  Even the official codex page does not recommend it.

For performance reasons, it is not a good idea to start your permalink structure with the category, tag, author, or postname fields. The reason is that these are text fields, and using them at the beginning of your permalink structure it takes more time for WordPress to distinguish your Post URLs from Page URLs (which always use the text "page slug" as the URL), and to compensate, WordPress stores a lot of extra information in its database (so much that sites with lots of Pages have experienced difficulties). So, it is best to have at least two path segments in your post's permalink structure such as /%year%/%postname%/ or even /posts/%postname%/

Basically, they are all saying the same: If you have lots of pages, using one of the bad link structures can badly affect the performance.

So, I run some tests to figure out how bad the impact really is.  I wrote a perl script that created "fake content" for a WordPress 3.1 test installation. The script created about 2500 pages with random content, nested only 2 levels deep and another 500 blog articles in 10 categories. This isn't huge - just a blog with 500 posts and 2000 pages - I'm pretty sure there are much bigger sites out there.

Read more...

That summarizes the changes for the recently released first beta of the upcoming WordPress 3.2.

Visual changes 

The admin area got a visual overhaul, the first one in years. The screen shot shows how it looks with the gray admin theme. It is noteworthy that the blue theme has not yet been updated and looks a bit weird in beta 1. This is a known (and documented) issue. In my opinion, the new admin theme looks smoother and preserves some screen real estate due to a more compact header. The changes are visible but they don't hurt the user experience - it still looks and feels like WordPress.

Admin theme

Full Screen editor

Twenty Elven

Read more...

Quick writeup with some helpful hints for migrating a WordPress theme to HTML5.

HTML5 is the upcoming standard for web documents, that's already set in stone. While the standard has not yet been finalized, it already looks very solid and consistent. One should expect some changes in the future, but don't be afraid you'll have to rewrite your entire theme when you make it ready for HTML 5 now. It's already safe to use and when done right, there will be no disadvantages, even for visitors who are not using one of the latest generation browsers.

Advantages

Keeping up with current or even future web standards is basically a good thing. By doing so, you gain access to new technologies and methods to create better web sites. You also ensure your sites will display with the same level of quality on many modern browsers and other web-enabled devices, because most of them are already supporting the new standard. There is a good level of backward compatibility, so using HTML 5 will not break your pages for visitors using an older browser that does not support it.

Read more...

There are several advantages of loading jQuery and other big JavaScript libraries from a CDN (Google in our case).

• It can save you some traffic. While jQuery isn't exactly big, jQuery-core and jQuery-ui are about 80K together, even when using the minified versions of the libraries.
• it saves 1 (or 2, in case you also need jQuery-ui) HTTP requests per page view on your server. Doesn't sound like the big deal, but on a busy site, it can make some difference.
• Even if your server is powerful enough, most browsers limit the number of simultaneous requests they make for one server. Spreading the load to multiple servers can reduce the page loading time for visitors, no matter how powerful and fast your server is.
• You are no longer limited to the jQuery version that comes with WordPress. While it is usually sufficient, there may be situations in which using a more recent version can be beneficial.
• And last, but not least: Google has more bandwidth than you. Always :)

WordPress 3.x comes bundled with jQuery 1.4.4. The WordPress back end heavily uses jQuery and jQuery-ui and for the back end, you should always stick with the bundled version. By default, your frontend templates will also use the bundled version, but this can be changed.

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...