Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

When developing a plugin, I usually test it with the following themes before public release:

  • TwentyTen by Automattic
  • TwentyEleven by Automattic
  • Coraline by Automattic
  • Duster by Automattic
  • Hybrid by Justin Tadlock
  • News by Justin Tadlock
  • Prototype by Justin Tadlock
  • Retro-fitted by Justin Tadlock
  • Responsive by ThemeID
  • PageLines by PageLines
  • Buttercream by Caroline Moore
  • Catch Box by Catch Themes Team
  • Suffusion by Sayontan Sinha

Are there any other recommendations out there that you should test your plugin with for checking compatibilities?

share|improve this question

closed as not constructive by kaiser, Brian Fegter, Rarst Oct 2 '12 at 21:19

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I would like to see the reasons why you pick those themes for testing. A better question is why, not what. –  Rilwis Sep 3 '12 at 14:54
    
@Rilwis I already added a close vote - even when answering it. –  kaiser Sep 3 '12 at 15:08
1  
Please elaborate on which kinds of plugins do you mean so they need to be tested with theme and what kind of testing you are actually interested in. It's a broad topic. –  Rarst Sep 3 '12 at 15:29

2 Answers 2

Themes, anyone?

I don't test »against« or »with« themes. Just with some other plugins that might conflict (but I normally leave that open until something happens - you'll never figure out all edge cases).

At least, you're intercepting/extending/altering stuff via filters. So why test against themes, when you're modifying core functions?

If you're intercepting the_content filter for example, then why would you take a look at themes? If they jump in at priority 99999999, then you're anyway too late and the chance that they change it in another release is that high, that you wouldn't be able to follow anyway.

Imagine, that you'd check every filter - with for example the all-hook - jump in and move your priorities around until there's no chance that you'd miss it, then you'd bring the system down to its knees. It is possible. But it doesn't work in real live.

Debug

WordPress, as well as PHP got a bunch of error handling stuff on board. This means, that everything that fails, will be output - as long as it's turned on. Do that in any case in your local copy... and abort in live code!

Dump output

My best advice is to simply build yourself a really neat and easy debugging environment. When I write my classes, I normally add debug output to any containing method. This ways I can see what happens and when it happens.

Why am I doing this?

Simple: Errors will occur at some step. So normally you would start adding points where to stop, look at the output/returned data and then step forward until you catch the error. I'm just making my life easier with a simple switch, that allows me to output this stepped data: One tab in my meta box in the shutdown hook at a time. If the result isn't what I expected, then error/wrong piece of code happens right before that.

Check output/return

debug output

This allows me to jump in, whenever something fails. It also allows me to reproduce error prown installations and see what happens without any additional effort.

Check hooks

The other thing I often use it var_dump( $GLOBALS['wp_filter'][ current_filter() ]; to see what else is attached to the hook, where I'm currently jumping in.

Never ever output errors in live installations

When you look at how I did it with the »Dynamic image resize« plugin - a plugin that is a better TimThumb (replacement) - then you'll see how I avoid output for

  • Users that don't have the right privileges
  • Owners that forgot to turn debug stuff off by accident
  • Guests

As you can read from the comment above: I assume that no one has turned on DEBUG stuff while using a caching plugin. In this case: No one will be able to help.

Conclusion

At least it's Open Source. And if there's really some caveman who does it... then it's not your fault if things fail. You can't catch any edge case. :)

A last word

Why don't I test for missing hooks, etc.?

There are »Theme development standards« that every valid theme should follow. If they don't, then they're simply not on my radar. Imagine, that I'd give a note with for e.g. _doing_it_wrong() for every case something fails. This would bloat my code to approx. 10 times of the original size - without catching everything that could be written wrong.

Now imagine, that someone got a really crappy theme and I'd throw 10 messages at her/him with one plugin. What would happen if we'd all care about that? 1.000 messages?

share|improve this answer
    
I would love to just not support all the s*** themes, but since I sell a premium version of my plugin it makes commercial sense to test against themes that do things wrong. Also If you are trying to manipulate menu items (or things like that) different themes do different things (and still follow convention) - some use a query, some use a wp 3.1+ menu etc. –  Daniel Chatfield Sep 5 '12 at 16:09

I test with:

  • TwentyTen
  • TwentyEleven
  • Buttercream
  • PageLines
  • A Genesis Theme
  • A Wootheme theme
  • A few custom themes I have made (and will release at some stage) deliberately designed to test plugins by doing things the wrong way. Some of the things that I test for because too many bad theme authors exist:

    • Whitespace/content before get_header
    • No get_header
    • No wp_head
    • Change the jQuery version from the bundled one to some old fu*** up version in the admin panel
    • Ridiculously large banners automatically inserted after the heading on the plugin page - yes I'm looking at you JetPack
    • Turn error_reporting(E_ALL) on

I also test against all the popular caching plugins (they like screwing things up)

EDIT: Oh and the plugins that provide a mobile version of the site.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.