Debugging a possible clash between plugins and/or a theme

from one of my favourite comics

Put your site into maintenance mode and then Disable any caching plugins and be aware you may need to clear your browser cache too, to ensure you are  seeing ‘new’ behaviour when you are testing.

Quick and Brutal Approach (gives you info the fastest)

deactivate all plugins except the plugin you trying to get working. This has the advantage of quickly telling you if the plugin does/does not work by itself:

  • Problem gone when just that plugin?  The plugin itself might still be causing the clash, but at least now you have some info to pass on to the developers.  Follow the’ problem gone’ after theme switch below.
  • Problem still there ? Switch to a default theme.  Themes do sometimes mess with wordpress operation.
    • Problem still there ? If you now have just the one plugin active and you are sure you are seeing updated pages, you can advise the plugin author that you are seeing the problem on a default wp theme and with no other plugins active.
    • Problem gone? Ok,  now go back to your theme.
      • If the problem reappears you know it is something clashing between your theme and the plugin.  Advise both authors with as much detail as you can.
    • Problem still gone now that you have your theme back?  Now slowly, checking after each activation, reactivate your plugins, starting with your most essential ones.  At some point the problem will re-occur, then you know the clash is between the most recently activated plugin and your new problem one.
    • Problem stays gone once all is reactivated? Weirdly this can happen.  Sometimes it is the order of activation that causes the problem.  Don’t close your eyes and celebrate – a plugin update could cause the problem to come back.  Now you may have to play around with activation sequences here to find the clash

Slow and Steady also gets there in the end

Another approach is step by step deactivation and  switch theme to default theme until the problem disappears.

At some point the problem may go away, then reactive the last plugin active and check if the problem comes back.   Now you know it is part of the ‘clash’ somehow.

Must use plugins

If you have plugins showing up as ‘must use’ plugins and the problem is still there after deactivating other plugins and using default theme, you may need to use ftp or your control panel file manager to temporarily move the must use plugins in case there is code in there that is causing the clash.

Warning for older themes, or perhaps not so well written themes

Most themes should keep their settings and widgets and all should be fine when you switch back to that theme.  There some that don’t.  Make sure you have a backup that you know how to restore from OR that you know your theme’s settings and what widgets were being used where.

Recently Active Plugins

Your temporarily deactivated plugins will be in ‘recently active’.   This makes it really easy to reactivate them.

If you are one of those folks who keeps a lot of deactivated plugins hanging around and you forget which ones you really need, don’t panic – WordPress very nicely gives you a week in which it remembers which plugins you had active recently.

Call current_user_can after init()

Running buddypress? Are you getting a debug notice like this:

The current user is being initialized without using $wp->init()

and you cannot figure out where it is coming from ?

Most likely one of your plugins is calling a user related wordpress function a bit early (see wordpress action sequence).   You could try deactivating them until the debug message goes away.  The last plugin deactivated will be it.  Let the developer know because his/her code may not be quite working the way it was intended to.

eg: current_user_can()  or possibly  wp_set_current_user()

These need to be used after the init action.  The plugin or theme might have something like

add_action ('plugins_loaded', 'some_function');

The action should be added later, when the current user has been initialised.

add_action ('init', 'some_function');



Force new windows on external links?

Don’t force your users to open new windows…. even on external links.

There are many reasons why it is a bad idea and not many reasons to do it.   There are maybe a few special cases where it is ok – but is it ever really necessary?  Personally I like to control the opening of tabs myself – I use the right click frequently at times – when I’m researching I open heaps of tabs, then work my way through them.  That doesn’t mean I want a website to forcibly open those links in new windows for me!   Unless of course it is my webmail or feedreader service – then it’s practically obligatory.

Let us assume we are intelligent enough to adhere to standards and take advice from the experts.  Let us assume we all want

And of course we’d like our plugin developers, wordpress developers, tinymce developers to help us in this mission.   This research was done for my own use to determine what my plugins should do.


  • forcing new tabs or windows is bad for usability (seriously, studies have shown it is harmful)
  • it is not recommended for accessibility
  • the methods to do it can cause invalid html
  • some folks think it doesn’t help your analytics (although one site had some thoughts on that)
  • it is not necessary… so why do it?  maybe just indicate an external link? or allow for optional js.

Who says no?

Possible reasons to force a new window on external links?

But I want to keep the user on my site…..

“Marketers love it because it allows them to link to external content without taking the reader off the page.”

This is a reasonable fear for a client to have. The user leaving the site and not being able to get back….In every single usability test I’ve done, opening external content in a new window makes this problem worse – not better.

quoted from the Stack exchange usability forum

Special cases perhaps?

  • webmail,
  • feed readers,
  • long lists of external resources.

If we need to do it, what is best way to deal with external links?

Best ways to handle external links

Indicate the external link.

See how Wikipedia  does it.  It classes links as external with a css class.  That css class is then styled with a background image.  It provides a clear visual clue as suggested here.   The css is something like:

 a.external {    background: 
    no-repeat scroll right center transparent;
    padding-right: 13px;}


style the rel=”external”



Force it open anyway?

If you really truly must force  open a new tab or window on an external link, consider:

target=”_blank” is invalid html

 rel=”external” or rel=”external nofollow”

data-rel=”external nofollow”

WordPress and external links

I’m a wordpress plugin developer.  Sadly at stage of writing there doesn’t seem to be a consistent approach in wordpress. Perhaps it’s tinymc’s fault – can it be configured ?

post author or comment author links in twenty-twelve theme

  • uses “rel=”external nofollow”,
  • but by default there is no js to force a window open links in meta sidebar or footer

  • no attributes, so not an issue

Links or link manager plugin

  • links are no longer a default feature in new sites, but can be added with link manager plugin
  • option to add target=”” and rel=(but only real relationships), not forced

Links in posts

  • (if added using visual editor’s insert link), then we get target=”_blank” ?
  • it’s tinymce allowing users to select ‘open in new window’ – can it be disabled?

external link plugins

even plugins that aim to help you manage outbound links note that opening new windows may have detrimental effects.  Semilogic suggests users may think you used a pop-under.

 Wordpress related discussions and requests:



Accessibility guidelines:

Usability advice on external links and new windows:

Web design advice on target=”_blank”

Contrary Arguments

One argument for new windows on external links, but many comments questioning this advice

Need help discussing with your clients?

Some tips on discussing decisions like these: