What’s the biggest gripe you have with free WordPress themes?

Posted on

By Michael Fields

The past couple of weeks, I’ve been working on a new theme for WordPress. I started redesigning this site and thought that it would be a good idea to code it really well and release it for free on WordPress.org. Then I learned about post formats and thought it would be a great idea to incorporate this new functionality.

I’m just about finished and was wondering if anyone would want to help me out by letting me know the #1 thing that you have found frustrating when using free WordPress themes. Here’s mine:

Lack of a unique titles across all views including custom post types, taxonomies and dated archive pages.

Just trying to cover as many bases as possible before I unleash this beast. Please leave a comment and let me know what NOT to do in my theme.

Thanks!

16 Comments Comments are closed

  1. Eric Mann January 3, 2011 at 10:51 pm

    Required plug-ins that aren’t bundled.

    Several themes I’ve used in the past have been dependent on one plug-in or another to work right. Some major feature or layout element was rendered by a specific 3rd party system that didn’t come with the theme (I had to download it myself).

    The problem is, sometimes the plug-in updates but the theme doesn’t … so you’re tied to a specific version of a plug-in and can’t take your site forward without hacking it or begging the developer.

    If you want to include plug-in functionality, it should come bundled together … not delivered piecemeal.

  2. Michael Fields January 3, 2011 at 11:04 pm

    Great point! Absolutely no plugin functionality has been included in the theme thus far. I’ve been pruning functions.php the whole time I’ve been developing and have been sure to move all custom functionality to a child theme as to not pollute the main theme.

    I have added support for a few plugins that I personally use. There is support for wp_pagenavi (css + php auto-discovery and replacement of wp_defaults) as well as a custom stylesheet for SyntaxHighlighter Evolved. Theme does not rely on these plugins to work. Just allows them to be integrated faster if a user chooses to install them.

    While adding support for all of the post formats, I ran into somewhat of a dilemma with the audio format which relates to your gripe. Without a plugin, the audio post will just display the content as entered by the author. Which means that they will have to install a plugin to get a fancy flash player. I intentionally did not bundle one of these plugins because I wanted to give users a choice in how their media is displayed. Would you do it differently in this situation?

  3. Jarret January 4, 2011 at 4:50 am

    I would think it would depend on what your targeted user base of the theme is going to be. If it is going to be targeted to just average bloggers I would include something in as I wouldn’t want to have to force users to try to install something.

    However, if your target base was more technical users I would leave it up to them. Of course it is hard to say exactly how your theme will be adopted by each group of users but I think you can target a certain group based off of what you offer in the theme.

  4. Thomas Scholz January 4, 2011 at 5:31 am

    Not using PHPDoc in PHP code.
    Bad or no prefixes for functions, classes and variables.
    Missing filters for custom functions.
    Hard coded paths for wp-content and uploads.
    No POT-File or no I18n at all.

    I had some more obscure problems with free themes, but these are the most common ones I can think of.

  5. Michael Fields January 4, 2011 at 8:14 am

    Thanks for all of the examples. Most are covered so far. I’m using a mostly action-based system much like Thematic or Genesis which means that most of the functions can be un-hooked or replaced with customized versions via child theme. There are also a few basic filters in place. Everything’s totally prefixed. This practice is second nature for me these days. This function was taken directly from the theme. I hope to have as much documentation as possible included inline. Currently, theme code is “localization ready” I guess. Unfortunately, I only speak one language which makes the process a bit less intuitive then I would like it to be. That being said, I have read quite a few articles on the subject and feel like I am doing it correctly. If you would have a few minutes to look it over, I would love to have your input on it. I will also look into generating a POT file as this is something that I have not done before.

    Thanks again for all your suggestions! If you think of anything else feel free to post.

  6. curtismchale January 4, 2011 at 1:34 pm

    The thing I hate the most is non-semantic class and id names like pad100

  7. Thomas Scholz January 4, 2011 at 2:05 pm

    Actions are good, but sometimes a child theme author just wants to add or replace a small string. Filters are handy then.

    The plugin Codestyling Localization is very helpful for I18n. It will find all translatable strings and generate a POT file.
    I don’t have much time, but if you send me your theme I take a look.

  8. Rachel Nabors January 4, 2011 at 4:35 pm

    I’m also working on a theme for myself that I’m planning on releasing. It will be dependent on one of your plugins, which you advised me not to incorporate into the theme’s functions because media uploads are going to change in the future. While I hate the dependency (what happens when you stop developing the plugin?), there is simply no way around it. Alas.

    Sometimes I think theme developers get carried away with adding functionality that’s available–often better implmented–with plugins. For instance, a user might not want to use my theme’s google analytics options when there’s a plugin they already use that will do the job much more to their satisfaction.

    I absolutely detest when people mix in presentational code with the theme, like logo image placeholders and such. I know how to use stylesheets and child themes. I don’t want to spend the beginning of my project stripping out all the presentational stuff just so I can get it working my way.

    But I’m not a average Joe blogger who just wants to slap up a blog with a logo image up top. So take my words with a pinch of salt!

  9. Michael Fields January 5, 2011 at 5:41 am

    Seriously?!?!?! Are you telling me I have to go back and delete all of these as well as .redBackgound and .pinkBorder?!?!!?

    Just kidding ;) I totally agree with you and would never include such code in my projects.

  10. Michael Fields January 5, 2011 at 5:58 am

    It will be dependent on one of your plugins

    Is there any reason that it has to be dependent on the plugin? I mean the plugin allows you to associate images with taxonomy terms. Which is a cool feature, but is a very small percentage of what the theme does.

    What I have done with my new theme is to create something that will work great without any plugins. Users will definitely be able to have better looking and functioning sites if they install certain plugins. Like I hinted at above, the best possible format for an “audio” post would probably be some sort of Flash or HTML5 mp3 player. I have made a choice not to code this functionality into my theme because there are plenty of available solutions out there and the user should be able to choose to use the one best suited for their purpose. If I were to choose one for them, not only would they be locked into it, but then I would have to support this extra code.

    I absolutely detest when people mix in presentational code with the theme, like logo image placeholders and such.

    I have never seen this before and it would drive me crazy! Rest assured that there is nothing like it to be found in my theme :)

    I decided to go with the built-in header image feature. It’s not perfect, but it saves me from creating one of those fancy theme options pages.

  11. Michael Fields January 5, 2011 at 6:02 am

    Thanks! I’ll give the plugin a test spin when I am closer to the finish line. Which is looking to be pretty soon actually. Had a really good session today and things are looking good! I’ll have to go over it again and do a quick filter scan… there’s one function that could really use some love in this department.

    I’ll definitely shoot you a link to the developer release when it’s ready. Would be awesome to get your thoughts on l18n. No pressure though, if you don’t have time that’s totally understandable :)

    One quick question though: Is it important to localize the string passed to php’s date() function? Seems like it is.

  12. Michael Fields January 5, 2011 at 6:06 am

    @Jarret I would totally agree with you a few years back but ever since WordPress started allowing users to directly install plugins from wordpress.org it is far from a hard thing to do.

    It’s kinda strange, there is no target audience for this project! Or I guess you could say that the target audience is everyone. My goal here is to make a theme that anyone can use which I thought would be easy. In hindsight, it’s proven itself to be a lot harder than making a theme that would satisfy a certain niche.

  13. Thomas Scholz January 5, 2011 at 1:21 pm

    Yes, dates should be localized. But in most cases WordPress does this already for you: there are get_option( ‘date_format’ ) and date_i18n(). Adding a filter with some context wouldn’t hurt.

  14. Michael Fields January 8, 2011 at 8:11 pm

    I think I have this whole localization thing down now. I really appreciate you chiming in and pushing me to make sure that this was handled well. I really couldn’t figure out how to use the Codestyling Localization plugin, but this is probably because it’s the first solution I tried and really didn’t understand what was going on. I was, however, able to generate a POT by using Poedit which definitely took some time to figure out, but I’m pretty confident using it now. I found it really helpful to see the POT file and then go back and make adjustments.

    I still have no experience translating a theme and have one more question if you don’t mind. Is it better to have the .pot and all the .po and .mo files in a “languages” directory. I found a couple of themes doing it this way and it looks solid. Just wondering what your thoughts were.

  15. Thomas Scholz January 8, 2011 at 8:27 pm

    Once your theme becomes popular, I hope it does ;), you will get translation files from other people. If you have more than 3 or 4 such files, you probably want to put them into a separate directory anyway.

Fork me on GitHub