When to use which plugin output method?

2 Views

I’m a Drupal dev, getting into WordPress. So far as I can tell there are a few different methods by which a plugin can output content on to a WordPress site:

  • Shortcode
  • Rewrite API
  • Widget API
  • “Template tag” (ie instructing themers to call a PHP function from your plugin in their theme)
  • Actions API

Which do you use and when? Are there any good articles covering such a topic out there?

Post Views: 2

Related posts

Leave a Reply

1 comment

  1. This highly depends on what you need.

    General answer on the question

    • The Rewrite API basically does all the URl rewrite stuff.
    • The Shortcode API is meant to be an easy to use extension approach for people who want to extend their posts/content with the text/html editor. As an alternative, you also/extend use the quicktag buttons in TinyMCE to insert the shortcode (layer above shortcode-abstraction-layer).
    • The Widget API is normally used to build small plugins that go into dynamic_sidebar()s in theme templates, that offer such possibility.
    • The Actions/Filter API (actions are low level filters) allows you to insert or modify any stuff in core/themes/plugins/widgets/muplugins/dropins, that offer do_action()-hooks or apply_filter( 'name', $args_1, $args_etc )-filters. You can use them with add_action( 'name', 'callback_function_name' ); (class method approach: add_action( 'name', array( $this, 'callback_method_name' ) );).

    So you can use everything as you want, but you should try to make it as easy for the user as possible. Offering template tags generally isn’t a good idea. It’s better to hook your main function into a hook, that the user has to add to his template: do_action( 'plugin_special_hook' );. This way you avoid errors and warnings/notices in case your plugin isn’t activated.

    If you use Widgets, you have an UI that the user can use to adjust possible options.

    If you use Shortcodes or TinyMCE buttons, then you got some other possibility to adjust the output.

    If you got filters or hooks, then the output is generated without users involved. Or you got a Settings API admin page, where the user can adjust the output.

    The rewrite API got nothing to do with above mentioned – it’s not about output, it’s about routing requests.

    Names are just for organization … and hooks

    MU-Plugins come right after DropIns in load order and have access to the earliest hook muplugins_loaded. Then you got plugins with the plugins_loaded hook. Then there’s the after_setup_theme hook for plugins. Then all the rest follows with init.

    Normally the rule of thumb is to drop everything that’s not UI, into a plugin – if it has options, use a normal plugin, else use a mu-plugin. The rest goes into a theme. Or a child-theme (overriding of parent themes files possible, without loosing changes on updates of parent theme).

    Replace Core parts

    If you need to modify a pluggable.php function, you go with a DropIn. Hint: Don’t override pluggables, as this is normally too error prone.

    APIs whereever you look

    There’re as well some others APIs, as for e.g. the WP HTTP API, and others. Make sure, that you use them, as else the sky would fall on your head (sooner or later).