• Resolved Paul

    (@paultgoodchild)


    Hi,

    We’re the developers of the Shield Security plugin and we have a couple of dynamically generated pages – namely our setup and scanner wizards.

    Unfortunately we’ve become aware of issues with the wizards and it’s been narrowed down to your plugin.

    We dug into it and it seems you’re incorrectly calling wp_footer().
    Here is the codex:
    https://codex.www.ads-software.com/Function_Reference/wp_footer

    Quote:

    Put this template tag immediately before </body> tag in a theme template

    NGG is not a theme. It’s a plugin. It shouldn’t be firing wp_footer().

    I see you run a check to ensure it’s a “valid request”. Your extensive IF/ELSE block doesn’t take into consideration that 1,000,000 other plugins might do things that you’re never going to be aware of.

    You don’t, fortunately, get to decide who runs wp_footer() – the theme does that.

    So, please remove your call to wp_footer() in your plugin. It’s breaking our stuff, which is adhering closely to the WordPress codex/coding guidelines. wp_footer() should be called by themes, not by a plugin.

    If you need to insert your custom footer stuff, please do so in a way that is unlikely to break other plugins who don’t need or correctly function with forceful calls to wp_footer().

    This says nothing of your forceful “jquery fix” code which is part of what’s upsetting things. You feel it’s okay to force jquery on everything because your plugin uses it. Also not playing fair.

    Your cooperation is much appreciated.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Imagely

    (@imagely)

    @paultgoodchild – Thanks for the feedback.

    We are well aware that themes are the ones that call the wp_footer() function, this is a standard expectation under WordPress theme best practices, and noted slightly further down the page you referenced as something plugins often use for their JavaScripts (which is what we are doing).

    Now, given themes are the ones typically generating pages they would accommodate the use and call of the wp_footer() although you appear to be describing your plugin as creating a page that does not. We can appreciate your plugin page may not require that function call although it is something that should be handled all the same as an expectation for other plugin authors as I understand you are noting. The call to the “footer” should always be available.

    We’re happy to look into this further although I do not have a timeline on when we would be able to refactor all of our code to address the issue your plugin’s pages with out a “footer” are having trouble with. If you can provide any additional specifics of where you plugin is having problems perhaps we can work together to write some additional third-party compatibility code.

    This would also likely be best if sent to us as a Bug Report. Please send us this Bug Report (https://imagely.com/report-bug/ … please reference this topic) so we can get a better look under the page at your concern.

    Please include as many details as you can about your concern and the issue at hand so we can move on this as fast as possible.

    Thanks!

    – Cais.

    Thread Starter Paul

    (@paultgoodchild)

    Hi Cais,

    Thanks for getting back.

    Your response is basically saying that:

    • Our plugin has a problem because it doesn’t adequately cater for the footer
    • We should write our plugin to cater for the footer
    • You might consider writing plugin-specific code if we submit a bug report
    • But you might not have the time

    That’s a frankly ridiculous response.

    Our plugin should be able to generate and output any HTML that fall outside the scope of the front-end theme display/processing, without having to cater for wp_footer or wp_head, or any other front-end processing/hooks.

    Your response is caged within the pre-supposition that we’re doing it wrong. We’re not. We should be able to output HTML without your plugin forcing your HTML on it.

    That is your error. Not ours. Having to actually forcefully run wp_footer() points to a problem with your logic. It should be handled by the theme. You shouldn’t have to force the issue. My guess is you found themes that didn’t do it, and instead of doing what I’m doing and reaching out to the developer, you decided to force the issue.

    Don’t couch your response in the assumption that we’re doing it wrong, just because it might take a long time for you to fix it.

    Our page isn’t a front-end HTML page. It’s a page. It’s a page because all requests that load a text/html block in a browser are “pages”.

    Your response and approach to coding, in what is essentially a shared environment, represent a mightily selfish approach to WordPress development.

    Plugin Contributor Imagely

    (@imagely)

    @paultgoodchild – You still have a couple of options to consider. First, please send us a Bug Report (https://imagely.com/report-bug/ … please reference this topic) so we can get a better look under the page and this will get the issue closer to our developers; and, second, adding the following to the site/your plugin code might also help:

    define('NGG_DISABLE_RESOURCE_MANAGER', TRUE);

    Although the above may create other unexpected results. The above is also more for troubleshooting than anything else although it can be used as needed.

    – Cais.

    • This reply was modified 6 years, 7 months ago by Imagely.
Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Forcefully executing wp_footer() – not compatible with other plugins’ is closed to new replies.