Technology

WordPress plugin idea : relevant tag cloud

Once in a while, especially when trying to explain a widely used technology to a non-technical person, I get this feeling that things could be done better. And that’s exactly what happened recently while I was explaining tag clouds.

I know that there are plenty of variations on displaying and generating tag clouds – most used, most popular, recent, etc, etc, etc. But what I realized is that a relevant tag cloud plugin is missing in WordPress. Or, at least, is hard to find.

Many WordPress blogs these days are serving a particular niche, covering a specific topic. So, for them relevant tag clouds are not a problem. All tags are relevant, since they all share the same topic. However, there are plenty of blogs which cover a wide variety of topics.

Take my blog for example. I write about technology (tools, concepts, trends, etc.), movies, Cyprus, personal life, and lots of random bits about this and that. I tag all my posts. But the tag cloud is totally useless, because it shows all tags from all my posts. And what good are the technology tags for the reader who scrolls through movie posts?

So, I think there is a need for a relevant tag cloud plugin. I don’t know exactly how it should work and if it will work at all, but my ideas are the following:

When on the front page of the blog (is_home()), tag cloud can show anything at all – most used, most recent, most popular, etc.
When in the post or page (is_page() or is_post()), tag cloud should display tags which are used in all posts, that share tags with the current one.
When in the category (is_category()), tag cloud should display all tags which are used in all posts that belong to this category.
When in the archives (is_archive()), tag cloud should display all tags which are used in all posts within the archive time period.
When in search results (is_search()), search term should be checked against existing tags, and if found ,then show all tags used in all posts tagged by the search term. Alternatively, maybe, show a tag cloud for all tags used in the posts matching the search criteria.

I think such a tag cloud would be way more useful, especially for blogs that cover multiple topics. Especially, if the extra database load caused by generating such a tag cloud could be kept under control.

What do you think? Is it going to work? Is there something that I missed here? Is there are a plugin that can do this? Would you jump in and implement it or should I do everything myself?

Custom uploads directory for WordPress uploads

Tip 0 in this list of tips for a fresh WordPress installation mentions how to configure a custom uploads directory. By default, uploads go into wp-content/uploads/ folder, but you can easily change that in your administration. The tip gives to benefits for moving your uploads somewhere else:

Image URLs become shorter (http://img.mydomain.com/2009/06/system-crash.jpg vs. http://mydomain.com/wp-content/uploads/2009/06/system-crash.jpg).
The size of your WordPress folder will remain small. (Backups will be easier, and you can install and update your WordPress from the Subversion repository too.)

These are good, but I think there are more:

It’s easier to share the same uploads between several sites. For example, if your site is multilingual and you use a separate WordPress installation for each language, then you can have a single uploads folder for all your translated sites. (However, there is still something that needs to be done with the database, so it has attachment data properly).
In case you move your uploads into a sub-domain, you can save bandwidth. Caching can be improved, and you don’t need to send cookies any more. Static content, such as images, CSS and JavaScript files, often don’t need any cookies passed in the request, but if your site is using cookies for some pages, often cookies will be sent for static data as well. This advantage of course applies more to sites with a lot of traffic and static content.

WordPress theme change check list

I came across this post, with a self explanatory title – “13 Most Important Things to do When Changing the WordPress Theme“. This is particularly relevant to me, since I am updating my theme right this moment. And so, I thought, I’d just revisit the list items of that post with my own comments, since they are so fresh.

Take a backup of your current theme folder. That is always a good advice. Better even, take full backup of your blog, including the database dump. Why is the dump relevant for theme upgrade? No, not because I am obsessed with backups now that I lost all my archives. But because most themes these days include dynamic sidebars, which you usually fill with widgets. Widgets configuration is kept in the database. And when you are moving to a new theme, your dynamic sidebars often get out of sync, and you try to fix it fast by re-arranging widgets again. In case things go very wrong, it’ll help to have a database dump as well, which, when restored, will bring back your widget configuration.
Check for broken links. A new theme will hardly affect links in your content, but everything around it – headers, footers, sidebars, links to RSS feeds, etc – can easily get damaged. This happens especially often when you use a testing or development environment which is separate from your main production blog.
Look for possible security loopholes. Ideally, you should do this BEFORE you move your site to the new theme. The best approach here is to combine manual and automatic checks. Manual checks include reading the theme source code, checking the site in different browsers, from different IP address, while logged in with different access levels, as well as logged out altogether, etc. Automatic checks are provided by a whole bunch of applications, including some security oriented WordPress plugins.
Remove unnecessary code from your WordPress header. This has a lot to do with tightening up the security of your WordPress installation. The less information you give out to potential attackers, the better. I have no idea why this item is separated in that list from the previous one.
Make sure your RSS subscription link is correct. If you link to several feeds (posts, comments, category, etc) – check them all. Also make sure that you have them in your header for RSS auto-discovery to work. The best approach here is to use WordPress builtin functions for RSS links, not hardcode them by hand.
Check if all your pages are listed properly. Again, it’s not always possible to code your menus and navigation to work in every theme out there, but sticking to WordPress Codex ways you guarantee to minimize the troubles for yourself.
Put back your stats tracking code. I suggest to find and install the suitable plugin. There are many available for practically any statistics package. The plugin will usually take care of installing all the necessary codes, goal tracking, conversions, and the rest. Plus you’ll keep you configuration in simple and easy way via administration interface, rather than editing theme source files directly.
Check your website from different browsers. That’s the second best advice after taking a backup before even starting. Cross-browser issues are the most common to appear and the most nerve-breaking to fix. Even if you don’t know how to fix them yourself, still check your new theme for any glitches in different browsers, to at least know that you have them. Fixing them can be arranged separately. If you don’t have different browser versions available at hand, ask your friends or readers to help, or use web tools, such as BrowserShots.
Check if you sidebar content is correct. Especially so, if you had custom sidebars for the front page, categories, posts, pages, search results, archives, etc. Even more so, if you are using widgets (see above).
Re-evaluate your plugin usage. As the original post mentions, it’s a good time to see if you still need all those plugins you were using before. And there is another side to this too. Many heavily customized themes keep some functionality code in functions.php file. When moving to another theme, the functions.php from the old theme might not necessarily work under the new one. Maybe it’s a good time to move some of that code into more generic plugins and widgets.
Put back your AdSense / other ads code. This is somewhat similar to your statistics. If you use AdSense or any other well-known advertising service, you’d be better of with installing and configuring an appropriate plugin. If the ads are customized, than you should probably move them out of the theme code into separate files and then just include() where appropriate. Definitely worth a check after the move is done. While checking the site in different browsers, take a look at the ads as well, just to make sure all your visitors can see them properly.
Check if your favicon is proper. Ideally, this shouldn’t break by your theme change. While there is a way to specify favicon’s location in your theme’s header, I find it better to drop the favicon into root folder of your site – most browsers will pick it up from their automatically. And it will work even when your blog is horribly broken. Additionally, I don’t think changing your favicon often (even if ever) is a good idea. Favicon is like your site’s avatar. It takes time for people to get used to it and recognize it. Why change it when some of your visitors just got used to this one? Unless, of course, your favicon doesn’t represent your site at all anymore. Then – yes.
Look how you can optimize your blog. Yeah, well, true. However, before you start optimizing anything, make sure that you have the full backup (try restoring from it to a test blog), make sure that everything works before you start optimization, and make sure that there is any need for optimization at all. Premature optimization is evil.
Put up a post about the new design. This is a good idea. Before you do a full blown post however, maybe you should post a short update to your Twitter account (you do have a Twitter account, don’t you?). This way, your followers can point out any bugs in time to fix them before you notify the whole blogosphere, search engines, and RSS feeds. Once you are completely sure that everything works – yes, indeed, blog about it. Tell your readers why you changed the theme, if there are any new features, and how much effort it took you to put it up. A post like this would usually inspire at least a few of your readers to do something with their blogs. And that’s something that we definitely need – more and better blogs.

P.S.: even though the original post’s title says “13 things“, there are in fact 14 items on that list. I guess the counting went off, because it started from 0 and not 1.

Delete files dialogue in KDE = ugly

As I am getting used to KDE 4 more and more, I am enjoying it more and more. It delivers plenty of visual pleasure while being quite fast and user friendly. However, there this one tiny little thing which annoyed the heck out of me since ancient times. It’s the delete files confirmation dialogue. Every time I select one or more files to delete, here is what I get.

The more files I have to delete and the longer their paths, the uglier it looks. And you know what annoys me the most? It’s that fixing this ugliness is pretty simple. Just collapse and hide the list of files which are about to be deleted, and give a “Details…” button or link to expand the list for those who really care or want to double check. This way, the popup will be much smaller, providing enough of necessary information (“delete” vs. “move to Trash”, and “3 items” vs. “all these items”).

I don’t know how this managed to stay in for so long. Am I the only one who cares about this? Or are there so few KDE developers that nobody has the time to fix this? Do I really need to this myself? I hope not …

Fedora 11

Fedora 11 – code named Leonidas – was released just a few days ago. Having access to an excellent Internet connection in the office, I immediately downloaded it and upgraded. It didn’t go as smooth as I wish it did, and I still don’t have everything working properly, but I’m glad that I did upgrade.

Here are the issues that I came across:

I was upgrading using the preupgrade utility. It downloaded the packages nicely and created a “Upgrade …” option in the grub boot loader. Once I rebooted, the upgraded process started and everything was looking good. However, when the last package was installed, and a popup came up saying “Finalizing install process. Please wait, it can take a while”, the upgrade actually hang. The progressbar was going back and forward, but nothing was happening. I waited for about 40 minutes or so and decided to reboot the machine. Upon the reboot, it seemed like the upgrade process actually did everything it had to do. So that was a minor issue.
My dual monitor setup broke. I am using a Lenovo T61 laptop with an external Samsung SyncMaster 2053bw monitor. Laptop’s resolution remained at 1280×1024, but Samsung monitor went down to 1024×768 and it seems there is no way to push it up. This is probably due to new kernel and xorg, and I guess has something to do with kernel mode setting. I tried those few tips that I could find, but nothing worked. I still have the problem, so if you by any chance can suggest anything – I am all ears.
Once I got to my desktop after the upgrade, Firefox refused to start. It was crashing with a whole bunch of debug output, but nothing that made any sense. I had to spend a day in Opera, which turned out to be a nice browser for as long as you don’t need your extensions. Gladly, the Firefox problem as resolved the next day with the help of some folks in #fedora IRC channel. The issue was a plugin conflict (not addon, but plugin). Once I removed conflicting plugins and restarted Firefox – it worked automagically.
Flash was broken in the browser, but once I removed all plugins and re-installed the ones that I needed, the problem was solved.

That was pretty much all in the troubles department. Now for the good stuff.

My filesystem wasn’t upgraded to ext4. This is probably a bug or something, but I’m glad it wasn’t. I have a single / partition with /boot, /home, /var, and everything else on this same partition. Probably Fedora decided that it’s too precious for the upgrade.
Booting is faster now. I can feel it. And being on the laptop, I do lots of booting (between home and office, due to very different setups).
KDE 4 is a pleasantly usable stage. After using Gnome for the last year, I decided to give KDE 4 another chance, and it happily took it. It’s a fast, slick, efficient desktop. And I enjoy using it.
Firefox 3.5 beta 4 is way faster than whatever I had before. Some addons are still not supporting this version, but the speed with which it starts up and renders pages provides for some balance.

So, apart from having just one screen now, I am enjoying the ride. It was worth waiting for, downloading, and upgrading. And the screen … the screen will come.