Why not register shortcodes if is_admin dashboard?

I have observed the same issue with contact-form-7 a while back.

But note that registering shortcodes based on is_admin is doing_it_wrong (see gmazzap`s answer)

There are the two reasons that seem legitimate at first sight (and why they are wrong):

  1. (Unlikely) The plugin author tried to optimize the script to only register shortcodes when they are needed. In this case the author did not consider that the shortcode might be used in Ajax requests.

    Wrong because: This optimization does not provide any performance gain. It simply adds a value to the global “registered shortcodes” array.

  2. (This is the more likely one) The plugin author did intentionally disable the support for the shortcode in Ajax requests. With Contact-Form-7 this possibly is the case because forms can be set to “Submit via Ajax”. However, this feature requires the form to load additional javascript files which are not loaded when the shortcode is parsed via Ajax and javascript is added via enqueue_scripts().

    The author decided to disable the Ajax support to prevent bug reports like “Don’t use this: Form is displayed but clicking the Submit button does not work. Complete waste of time!”

    So the user will either see a guaranteed-working form or no form at all.

    Wrong because: Checking for is_admin is bad practice here. The conditon should check if the constant DOING_AJAX is defined and true.

Though most plugins do not use this kind of condition, the few that have that restriction possibly have it because of problems in the past.

When a shortcode is simply doing some output on the page there is no reason to add any admin-condition. However, when the shortcode does also enqueue js or css files then it makes sense to limit the usage to non-admin/non-ajax requests.

Leave a Comment