Cancel

Jeff Chandler

An Idea To Help Avoid Shortcode Conflicts In Plugins

Mark Jaquith recently performed a scan on a local copy of the WordPress plugin respository and was able to generate a list of basic quoted string shortcodes within the plugins. The list looks like it could go to the moon and back with some funky looking shortcodes that are not very descriptive. Mark notes that there has been some discussion on whether or a not, a directory should be built and published which notes all of the shortcodes in use from all plugins in the repository so that plugin authors can check and see if their own shortcodes would conflict with any other plugins or perhaps, make theirs compatible with another.

While I don’t dabble in as nearly as many plugins these days, I can say that I’ve never gone through the experience of dealing with a shortcode conflict. If you have, I’d love to hear your story.

Category:
Tags: , , ,
11

11 responses to “An Idea To Help Avoid Shortcode Conflicts In Plugins”

  2. I am against any form of a shortcode repository, it will be difficult to maintain, it has privacy issues and it is not necessary. Just introduce namespaces, like every decent programming language does to solve this kind of issues. Existing shortcodes do not have a namespace (yet) and new shortcodes can have one to prevent conflicts. A shortcode could be written like this, where namespace is optional.

    [namespace:shortcode]

    Create forum topic from comment

  3. Here’s one: WordTube uses [media] while Media Tags uses [media-tags]. A clash between two plugins, even though the shortcodes are – to human eyes – different.

    Now I know (from asking) that it’s a WordPress issue, but it doesn’t help!

    A list of ‘claimed’ shortcodes would be good, but given the number of plugins that aren’t tested as compatible with recent versions of WP, there’s have to be a way of saying, for example, that any plugin not testedwith the latest version (or latest version minus a dot point or two) can be released for re-use. We’re at 3.2.1; should anything not tested with version 3.x be removed, or highlighted in some way?

    Gary

    Create forum topic from comment

  4. I think the developers should start prepending the plugin name to the short code such that [youtube] becomes [mypluginYouTube] or [myplugin_youtube] or something similar and at the same time make it mandatory to build a UI to enter the same..
    Advanced users ca obviously remember the long name while casual users can use the UI

    Create forum topic from comment

  5. @Marcel – A directory wouldn’t be difficult to maintain if it was automatically generated. Any plugin added to the repository would simply be scanned on upload/commit, and could be tagged in a directory, noting nothing more than shortcode name & plugin from which it’s from.

    I don’t see why this would be a privacy issue; plugins hosted on the WordPress repo are open source and browseable via Trac already, so having an auto-generated list based on them would reveal nothing that isn’t already available.

    If a standard way of declaring namespaces and so forth was devised, a directory for them would be useful too. (For instance, to prevent conflicts of localization namespaces, plugin option namespaces, and so forth.)

    Create forum topic from comment

  6. Perhaps shortcodes should have an optional prefix if there might be a clash. Another optional param on the register shortcode function. WordPress should be able to tell that the same shortcode has been registered twice and automatically activate prefix usage.
    It doesn’t have to be activated from the get go but the option should be there.

    Create forum topic from comment

  9. @Namith: automatic prefixes are not a good idea for groups of related plugins.

    @Rick: regarding privacy you maybe right, but automatically generating a directory will not work. For example:

    add_shortcode($plugin_name . '_' . shortcode_names[$i], shortcode_function[$i]);

    and a lot of other constructions will be missed.

    Create forum topic from comment

  10. Mark Jaquith already admitted that by pointing out that his list was simple quoted shortcodes only. However, even more complex constructions could be noted in a section of the directory that lists plugins w/ indeterminate shortcode names, for example.

    Ultimately, the problem could be solved if WordPress added an optional plugin header parameter:

    Plugin Name: My Plugin
    Plugin URI: http://example.com/
    Shortcodes: [shortcode], [shortcode2]

    It’d be easy to parse automatically, could be revealed in the WP UI in some way, and so forth.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.