Hi @davidanderson,
Sorry to know that you are experiencing this issue.
I understand that you performed a plugin conflict test, but the issue persists. Could you please also try switching to a default WordPress theme and let us know if that makes any changes?
Do you have any custom code added using a mu-plugin? If so, could you please temporarily remove it and see if that helps resolve the issue?
Can you please navigate to Tools >> Site Health >> Info and copy the info into the clipboard and share the same with us using Pastebin.com or Google Drive? This will allow us to understand more about the environment that you are using and help you further.
Looking forward to hearing back from you.
@heneart, I see that you have a separate topic opened for the issue where we have already followed up. Please follow up for any further assistance on that ticket.
Best Regards,
Nebu John
Hi,
Thanks for the reply.
I added a PHP filter to switch to the TwentyTwentyFive theme on that page. This has fixed the layout there. So, it must be something in the theme. What sort of thing should I look for? Note that the CSS file in wp-content/uploads/forminator/ *is* being enqueued on the page after changing the theme (as you can see by visiting the page previously mentioned and viewing the source), whereas on the default theme, it wasn’t. So, in some way, there is a conflict whose consequence is that Forminator does not enqueue its resources on the page.
David
Hi @davidanderson,
Thank you for getting back to us with more information.
It seems you are using a bespoke theme. We have noticed a similar issue reported when using the shutdown hook to buffer the data. However, can you please email us a copy of your theme file so that we can take a closer look at this for you?
Please upload that file to any file-sharing service like Google Drive or Dropbox and send us the download link to this email address, [email protected], using the following template.
Subject: ATTN: WPMU DEV support - wp.org
Please send:
– Link to your WordPress site
– Download link to the file
– Link back to this thread for reference (https://ww.wp.xz.cn/support/topic/form-does-not-display-work-correctly/)
– Any other relevant URLs/info
Looking forward to hearing back from you.
Best Regards,
Nebu John
Thank you; I have emailed the requested information.
P.S. And, as you’ll be able to see in the theme source, yes, the theme uses a shutdown hook and buffering.
Hi @davidanderson,
Thank you for getting back to us with the theme file.
I reviewed the theme code and observed that the following code in /framework/core/BUFFER.php is causing the issue.
add_action('shutdown', array($this, 'end_ob'), 0);
As per the code, the end_ob method of the current object ($this) will be called, which means output buffering is being closed or flushed right before the request ends.
I removed the code and tested on a lab website, and confirmed that the Forminator forms are loading.
I hope that helps.
Best Regards,
Nebu John
Hi Nebu,
Please can you clarify – are you asserting that a theme is not allowed to do this, that in some way it’s incorrect? As a WordPress developer, there’s nothing invalid that I’m aware of, and it is not preventing every other plugin on the site from enqueuing its resources. Why does it prevent Forminator? Will you be documenting this somewhere so that theme authors can be aware of what you don’t allow them to do – or is it something that Forminator will in future fix?
David
Hi @davidanderson,
I have pinged the Forminator developers for more clarification on this, and we’ll update you here once we have more feedback on this as soon as possible.
Best Regards,
Nebu John
Hi @davidanderson,
I hope this message finds you well. We have feedback from the Forminator team.
To clarify, we are not asserting that a theme is not allowed to hook into shutdown.
Analysing the code, we understand that what happens inside the end_ob() method interferes with how WordPress handles output buffering. WordPress core runs wp_ob_end_flush_all() on the shutdown hook with priority 1, which is intended to manage buffers at the end of the request. Because your code runs earlier, at priority 0, it closes or flushes the buffer before the core has a chance to do so.
WordPress prints <link> tags by echoing the generated markup directly from class-wp-styles.php.
do_action_ref_array( 'wp_print_styles', array( &$this ) );
echo $this->print_html;
Those echo statements write straight into the active output buffer.
When the buffer is closed or flushed earlier than WordPress expects, the plugins that rely on this mechanism are affected, while others are not, because they do not depend on styles or markup being printed through this path. Forminator does rely on it, which is why the issue becomes visible on your forms.
This behavior is not specific to Forminator, and it is not about blocking enqueues. It is a side effect of ending output buffering before the core has completed printing buffered output during the normal request flow.
I hope that helps. Please feel free to get back to us if you need any further clarification.
Best Regards,
Nebu John
Hello @davidanderson
We haven’t heard from you in some time, so I will mark this thread as resolved. If you have any more questions or need further assistance, please let us know!
Kind Regards,
Amin
Hi,
Thanks for getting back. It took me some time to work through this.
Ultimately I concluded that the most recent post from Nebu John is hallucinated (whether by him or by the developer he asked for help, I cannot say, and it does not matter to me!). The lines of code quoted from inside WordPress do not exist – either in the mentioned file, or any other file, in any recent version of WordPress (I didn’t check years-old ones!). Moreover, the description given of output buffering does not make sense (it assumes throughout that there is a single output buffer, whereas output buffers in both PHP in general and WP in particular are nested – for example, page caches use them); if something else nests inside WP’s buffer-handling, then that would be invisible to the relevant WP code and thus couldn’t itself cause a problem.
The problem is somewhere inside the theme, and relates to WordPress core’s code to “hoist” outputted styles from the footer into the header, which is where output-buffering does come in. I don’t have time to investigate exactly how it clashes, but the theme’s code contains assumptions that clash with the assumptions WP makes about how enqueued resources can be moved around; the comments in the function wp_start_template_enhancement_output_buffer() give some clues as to what the theme might be doing wrong, but being short of time, I’ve just short-circuited it all with:
add_filter('wp_should_output_buffer_template_for_enhancement', '__return_false', 999);
I expect that this slightly hurts browser rendering performance, by leaving CSS in the footer instead of the header. I can live with that!
Thanks for your help.
David
(I re-opened the thread just so that you can see what the final solution was, in case that will be useful for anyone else in future. Though commenting out part of the theme’s code did also un-break things, since I had no other known problems and it was hard to decipher what all the consequences of disabling those parts of the theme were – it had stuff that hooked in to filter its own output buffer and make modifications to it – I’ve not done that).
Hi @davidanderson ,
I hope you’re doing well, and thanks for confirming the issue with the theme.
In this case, it’s recommended that you reach,if possible, to the theme support so they can check and fix what happened on their end.
This is mainly so an update doesn’t break the fix that you’ve implemented.
Please let us know if you need further assistance.
Best Regards,
Williams Valerio
Hi @davidanderson,
Since we haven’t heard from you for a while. I’ll mark this thread as resolved for now. Please feel free to re-open this thread if you need any further assistance.
Kind Regards,
Nithin
