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…