I’ve updated the website of my company, Exove, last Thursday.

After spending three months of getting the design and the implementation just right, the site has been finally released. I never thought that making a company website for a company that makes websites for other companies would be this hard. But we are more engineers than copywriters…

During the development, I implemented a specific plugin to WordPress to create some dynamic parts of the site, such as carousels and accordions. They pick their content from a set of other pages, so your textual content does not get crowded with HTML.

The site is bilingual and for that I needed to reimplement quite a big portion of functionality of WordPress theme tags. These are in a specific class that gets instantiated using Singleton pattern in every theme file, and then provides site menus and other similar content in a proper language.

I found a lot of limitations in the current thinking of WordPress themes. Someone should reimplement the theme support with Smarty to allow better flexibility and control of the content. Now, WordPress provides too much HTML from inside.

Maybe I’ll roll my sleeves when Exove updates their website next time…

As you probably can see from the site, I’ve done some major changes in the look’n'feel.

The previous site visuals where from 2004 (I think), so it was a proper time to do something for it. I’ve been designing Nomadig.com again and again with half a year interval, but finally my design struck me as decent enough to go live.

The new design has removed a lot of bells and whistles around the content itself, and also modernised the look’n'feel quite a bit. The old site was built in several phases that were not connected to each other, resulting a bit different kind of items to various sections. This should be now fixed.

I’ve also removed a lot of advertisements that didn’t bring any value. Only Google ads are served from now on. The sidebar got a box shaped ad, as they seem to be getting a lot of image ads. I do hope that the ads do not interfere too much with reading the site — they need to interfere that much that someone ends up reading them, seeing some value in clicking and thus generating a bit of income to keep up the site.

There are a lot more changes under the hood. I upgraded to the latest WordPress and removed most of my custom stuff to the Nomadig.com theme.

The old site had three different content management systems. Besides WordPress, there was my own page editor for content pages and then one image gallery for photo section. Remember, that the site has existed a long before WordPress had pages outside blog. Now all pages are under WordPress. Some configuration was needed to get journal in its old location. I also installed a set of new plugins to get better archive display, and to handle some CMS style features.

Most of the URLs have now changed due to the radical reorganisation. I’ve written .htaccess file that handles most them, such as images, gallery photos and some other items. Further, I wrote a simple PHP script that handles the content page redirects. All redirects give “moved permanently” HTTP status code to inform search engines to update their databases.

As always with site updates, if you see something not working properly, add a comment or send me an email.

The website of my current company Exove is now open at both exove.com and exove.fi.

The whole site runs on top of WordPress that has been patched somewhat to support two languages within a single installation. Compared to Nomadig.com, Exove’s site has extensive amount of WP pages for static content. The Exove blog is not on the top level, but it has been moved one level down with an extension.

WordPress has been improved a lot during the two years I’ve been using it. Back in the old days, I had to hack the WP itself to get more advanced tricks to work, but now I just need to install a plug-in and configure it properly. The theme support has removed a real pain and it allows the site to stay visually the same even if the WP is upgraded.

Exove has an extensive amount of theme modifications, as the system supports two languages using one WordPress instance. The language is selected based on the domain name, and a few tricks have been used to make sure that English and Finnish pages do not get mixed up. All of them are on the template level, so the system should be upgradeable easily.

The company specialises in designing and implementing Web 2.0 services for digital marketing. Our specialties include corporate blogging and community based services that drive the stakeholders and the company to work together and create added value with an exceptional rate. We provide also consulting and training.

If you are interested in our services, please get in touch with me.

I finally got enough time to upgrade Nomadig.com journal to the latest version of WordPress. The transition was soothingly smooth — these guys seem to know what they are doing — as there were not even minor hiccups.

To serve my readers, I decided duplicate the WP installation and upgrade the duplicate. After I found the duplicate working well, I switched the blogs.

The process required also duplicating the database, as otherwise the production blog would have gone haywire.

Follow these easy steps to upgrade from WP 1.5 to 2.0.2 with a duplicate settings.

1. Make a copy of the WP directory, for example, cp -a journal journal2.
2. Dump MySQL database to a file, mysqldump -u user -ppassword --opt database > ~/wp_backup.sql.
3. Create new MySQL database.
4. Add use new_database; in the beginning of the dumped file.
5. Upload the edited dump to MySQL mysql -u user -ppassword < ~/wp_backup.sql.
6. Change the blog and WP admin URLs in the new database to refer to the new WP directory. I used phpMyAdmin to find the rows and edit them.
7. Edit wp-config.php file in the new WP directory to refer to the correct database.
8. Edit .htaccess in the same directory to use correct rewrite URLs.
9. Test that you can view and log in the new WP installation.
10. Upgrade WP as instructed in codex.wordpress.org.
11. Test everything.
12. Change the blog and WP admin URLs in the new database to refer to the old WP directory.
13. Dump the new database to file, mysqldump -u user -ppassword --opt new_database > ~/wp_2_backup.sql.
14. Add use database; (the old database name) in the beginning of the dumped file.
15. Edit wp-config.php to refer back to the old database.
16. Edit .htaccess to use correct rewrite URLs.
17. Upload the version 2 db over the old database, mysql -u user -ppassword < ~/wp_2_backup.sql.
18. Rename the old WP directory, mv journal journal_old.
19. Rename the new WP directory, mv journal2 journal.
20. Test that everything still works.
21. Write an entry about the upgrade. Remember to be specific.

Lately I’ve received a fair amount of comment spam in the blog. Fortunately, most of it is wiped away by Spaminator and none has passed through WordPress’ moderation queue for a really long time (knocking wood).

The most recent change in the spam comments is that there is no body, except two quotation marks (”"). Spaminator does not care about these, and they end to the moderation. I clean the queue twice a week or so, usually when writing new articles. So there are not a pain, but still somewhat annoying.

I checked Wordpress.org and found no mention of this issue except one entry in the forum. Maybe I should dive into the code and get this fixed — but on the other hand, I haven’t yet upgraded to WP 2.0. Spaminator could also tackle them with small modifications. Time will tell whether I get heated up with them and actually do something for it.

Yesterday evening, when fooling around with the site, I made an unpleasant discovery: the feeds were not working correctly. You can probably imagine my horror, as I tried to follow the RSS link at the bottom of the journal page and got nothing.

After checking out that PHP code is really working, I noticed that WordPress sends out 304 status code (not modified) even for those browsers that haven’t requested anything yet.

This discovery led to WordPress bug database that had a ticket related to this problem. Somebody had fortunately solved the problem and there was a diff file.

Unfortunately either the diff or the patched file was broken or not in sync, and I had to apply the patch by hand. The feeds seem to be working properly now, but if you have any issues, please get in touch with me.

Sometimes I see a sudden jump in the hits through ShortStat, and I’m left to wonder whether some busy site has linked to Nomadig.com, a search engine robot has gone wild or the site has been sucked by an offline browser.

The spikes of the first kind are more than welcome. More traffic here, more potential audience to be served. The second is usually okay, but there are some search engines that nobody is really interested in and their robots are not behaving properly.

The third category drives me nuts — the offline browsers are stupid enough to suck every possible page that has been linked in. This causes problems when the same page can be reached using different URLs and the site uses these variations. The same page can be fetched several times, increasing the bandwidth usage that at the end of the day costs me money. And these suckers are fast; they can fetch several pages in a second, eating bandwidth and processing power from the rest of you.

Until today, I wasn’t able to tell what caused the spike without downloading the raw log file and then trying to analyse it by finding an IP address that showed up again and again in relatively short period. As the log file contains information about all downloads, including image, JavaScript and CSS files, the task is burdensome.

A week ago I got that a-ha moment, when I suddenly realised that all required informaiton is stored in the ShortStat database. I could fetch the data with a relatively simple SQL statement and then organise it to a suitable structure for rapid analysis and print-out.

The process is very simple:

1. Read all requests for the past X seconds from the database, organised by the IP number and the browser string.
2. Count the number of requests per distinct IP number and browser string pair. Store the first and the last access time of these requests.
3. Calculate the time span between the first and the last access, and use that number to calculate average hits per second.
4. Show the number of hits, average hits per second, time span, IP address and the browser string sorted by the number of hits to the user. There is a lower limit for the hits to keep the list relatively short.

I fancied first doing that whole stuff in an SQL statement, but the timespan calculation was impossible feat for MySQL — at least without creation huge unions.

If you are interested in this, go to my ShortStat page at www.nomadig.com/shortstat/ and click link Leeches at the top of the page to see who is leeching Nomadig.com during the past 24, 48 or 72 hours.

I can make the code available, if someone is interested in using the system.

I’m on a long vendetta to get Nomadig URLs more search engine friendly — the aim is to replace all URL parameters with a path that has the same information.

When I launched the site, I was too lazy to make a proper link structure for the journal section. That was fixed when I installed WP 1.5 and got the rewrite rules in order.

After I finished the new URL schema for reviews a week ago, the front page requested my attention. I had changed the front page links to reviews, but for some reason most of the links to journal were in form of /journal/index.php?p=….

I was using the guid field from the WordPress database. For most of the posts, it contains a proper URL with year, month, data and the post name with dashes. But for other posts, it had still index.php?p=…

To cut the long story short, I had to add a new function to the front page PHP code to create proper links to the articles, and use that function every single time the front page has a link to journal. Now the links are brilliantly search engine friendly.