Determine if shortcode is present or active

Good question. You weren’t very specific about the context for your question, so here are some things you might try:

– If you know the HTML that this shortcode outputs, you can search for it in the resulting page. This would be after the page was fully rendered.

– if the shortcode is one you wrote, you can have it output something to the error log whenever it’s used, with more information about the context.

– If the shortcode is used in a text widget, you can extract the text widgets from the database and look through the content of those for a matching text block.

– if the shortcode is called through PHP (such as do_shortcode(‘[whatever]’)) you can search through the code for the shortcode tag.

– you could use remove_shortcode to disable this code, which would result in the text for it being displayed on the page for you to see.

– if the shortcode is introduced into the page through a custom field or some page builder shenanigans, disabling it would make it easier for you to find.

Hi,

I want to start output buffering just before the contact form page / widget is being displayed. Why? Because I use wp_redirect (a redirect) inside my shortcode and without using output buffering I get the “headers already sent” error. An user of my plugin requested a redirect feature.

Guido

• This reply was modified 8 years, 2 months ago by Guido. Reason: typo

Hi again,

I might have found a (very) easy solution, just start output buffering directly after the opening tag of my shortcode file.. how does that sound?

<?php
ob_start();

Guido

Hmm. Your shortcode shouldn’t be outputting anything – shortocdes should return their content so that it can be further processed.

Your solution could work, but it’s going to be pretty fragile. You don’t have access to things that might be output BEFORE the shortcode is called, so other plugins and themes might not be compatible w/ your plugin.

Or, are you looking for the redirect to happen AFTER the form is processed?

Hi Guido – besides what ancawonka correctly points out, a PHP redirect will never work from a shortcode because HTML output has already occurred after headers were sent. All the shortcode output buffering (incorrectly assuming it would otherwise work) in the world would not help change this fact.

The only way to redirect from within any content output, shortcode or not, is to output (or compile for subsequent output) a JavaScript redirect inside of <script> tags.

BC

Hi @ancawonka and @bcworkz,

Thanks for your responses.

If user adds a certain shortcode attribute in shortcode, it will redirect to a custom Thank You page when sending the form. If this attribute isn’t added, a default Thank You message is displayed (via a return).

Somehow it seems to work, when adding ob_start() directly after the opening tag in my shortcode file, although headers should already be send as you pointed out. But both of you advice me not to use OB because it isn’t a solid solution, so I quit using this.

@bcworkz: The js window.location does work, but is slow and inline js is not allowed as far as I know.

Maybe the only solid solution is a seperate settingspage where users can set their redirect (so using wp_options)?

Guido

• This reply was modified 8 years, 2 months ago by Guido. Reason: typo

I didn’t say a JS redirect was a good solution, only that it avoids the headers already sent ?? Somehow it escaped me that we have a form handler that can do PHP redirects.

Speaking of JS, why not have an AJAX driven form and thank you message? A completely separate thank you page seems so Internet 1.0! Maybe have an easy way for users to execute any desired conversion code with this message as well? It could be placed inside an enqueued footer wrapper function, then called from the AJAX response handler. Just a thought.

If you stay with a page redirect, why a separate settings page? Couldn’t it be a widget setting? Then different widget instances could redirect to different locations. This would be important for those tracking conversions. This appears to bring up the inability to identify widget instances again, except this time the widget could include an ID with the form data.