dccharron

You won’t believe this. Siteground.com has moved from Linux to Nginx. I’ve only just become aware of it. No doubt it was buried behind some changes to T&C that I did not read.

Under Linux they recommended the use of a plugin called SG Optimizer that controlled the caching. I purposely had never implemented it. Then I started having problems with Woody Snippets not being executed on each load. I knew right away that it was caused by caching. So I decided to try SG Optimizer to see if I could manage caching a bit better. But it did not help. The problem persisted.

So I deleted SG Optimizer thinking that I had returned to my previous situation. Little did I know that SG Optimizer added dozens of rules to the .htaccess file to control caching. When I deleted SG Optimizer, it left those rules in the .htaccess file. I never noticed.

My guess is that Siteground automated their move from Linux to Nginx. To do that, they would have had to automate the conversion of the .htaccess file rules to nginx.conf. If they did that transfer for my website when I had SG Optimizer installed, they would have copied all those caching rules left behind by their plugin! Siteground don’t permit clients to view or modify their nginx.conf file. Frustrating.

Ok. Here’s the messy bit that’s probably causing the problem. Siteground have decided to implement something called “Static Cache to NGINX Direct Delivery”. You can read it here: https://www.siteground.com/blog/nginx-direct-delivery/

My reading of this feature is that Nginx is deciding if a page can be served from cache by looking at its contents after processing by the CDN (WordPress). If it considering just the final HTML and Javascript, it would treat pages as cacheable even when they contained a PHP snippet. I’m sure you can see that this assessment would be wrong. It would completely ignore the dynamic nature introduced by the execution of that PHP. And Nginx delivers its own headers (like the rules in the .htaccess file overriding any headers in the HTML). In other words, there is nothing I can do to “force” the page to be treated as uncacheable since I can only do so in the HTML header. So frustrating.

I’ve got a ticket outstanding with Siteground and have explained that I either need Nginx Direct Delivery turned off on my website or they need to supply me with a trick to defeat Nginx assessment and force it to treat my pages with snippets as dynamic contents and, therefore, uncacheable.

PHP snippet simply contains:

date_default_timezone_set('Australia/Perth');
echo 'As at ' . date(DATE_RFC2822);

It runs near the top of the page (it appears with text asking the visitor to click on refresh if the date/time are old). The symptom is as follows:

When displaying the page the first time, the display shows the correct (current) time. However when displaying the page later using the same browser, the cached page is displayed (showing the old date/time).

I have tried various header changes and removed all .htaccess caching commands. I’m using SiteGround.com as my host. They claim that they are not doing any special kind of caching. I have checked that “Cloudfare” is Inactive, SuperCacher is “off”.

I’ve removed all caching from .htaccess and there is no caching plugin installed. The installation is running on NGINX. I’ve checked the URL with redbot.org and it shows that the cached page is usable for 180 days despite my meta tags in the head section as follows:

<meta http-equiv="expires" content="Sun, 01 Jan 2014 00:00:00 GMT"/>
<meta http-equiv="pragma" content="no-cache" />

I have tried other combinations of meta tags with no success.

I have used PHP snippets on several other pages. They only run the first time the page is accessed. After that, they only run if I click on Refresh (<F5> or circular arrow on browser). Any help you can supply would be most welcome.

It’s surprising that Elementor doesn’t permit SEO tag editing. That said…

Options 1: Looking at the Elementor documentation they recommend certain plugins and addons https://docs.elementor.com/article/126-elementor-related-plugins In that list it recommends “Yoast SEO”. Yoast is quite popular and would probably let you edit your SEO data without having to leave Elementor’s editor.

Option 2: To return to the Basic Editor, you might find that you have to de-activate Elementor. You should be able to re-activate Elementor without loss of data once you’ve finished your SEO data changes.

Personally I try to avoid plugins like “Elementor” because, in order for them to provide all of their wiz-bang functionality, they often interfere in your ability to make specific edits.

Hi @skierpage

Many thanks for tracking us down. I too maintain an old website that uses TwentyTen and it’s responsive plugin. I would happily have moved to another theme but have been unable to find one with a similar flavour. In essence, I would have to rewrite dozens of pages and hundreds of posts to get the website up and running to anyone’s satisfaction.

Like you, I haven’t used Subversion for a long long time (10+ years) and my knowledge of building a WP theme or maintaining one (or the responsive plugin) isn’t what is needed for your proposed TwentyTen fork. I agree with Todd’s assessment that using a plugin at least leverages the work being done by the WP team to the theme itself but this will come to an end some day. Once that happens we’ll all be forced to find another theme and any work done to the plugin will be a waste of time.

Happy to correspond further on this issue.

Many thanks. I must confess I had never looked in the Settings before. I found the option to turn it back on. Great relief. Now I’ll be able to gradually work through all my uses of the old shortcode to convert them to the new structure and shortcode. Thank you for the great plugin and for all your hard work.

Yes. I saw the “Code” view you mention. My experience is that when I do edits in “Code” view, when I save my changes, the editor second guesses my changes and makes its own changes to my code. Impossible to control. I kept fighting with the editor. The editor kept winning. During the past 8 years, I’ve grown accustomed to being able to do certain things in WP. But I can see that WP is heading in a completely new direction more suited to novices who don’t understand HTML and aren’t interested to learn. For now, the Classic Editor let’s me keep using WP the way I have been but I suspect that, in the not too distant future, I’ll be forced to find a new platform.

Yes. The new “Block” editor has HTML view but it is very different to the Classic Editor Text view. You should install the Classic Editor if you want to avoid having these extra HTML attributes being added automatically.

Would recommend you install and activate “Classic Editor” plugin. This will give you the “Text” view to edit your HTML.

The new Block editor also has an HTML view but it is quite a big change from “Text” mode.

Thank you for the solution.

Thanks @generalnick300

What you are suggesting will probably work but, due to a deadline, I decided to abandon this plugin. Instead, I built my own solution (my own PHP and Javascript). I even added my own security (encrypting the stored data just in case). It took me 7 very long days.

My existing websites are still using the cfdb plugin and are working fine despite
“Options => Security => Can See Submission when using shortcodes”
having a value of “Administrator”.

I agree that your suggestion is probably what I needed but since my existing websites were working fine, I was reluctant to open up any security hole by changing the value to “Anyone” (it does sound pretty scary). I was aware that “security” had been the issue that caused the plugin author to move outside of “official” WP plugins. I’m sure he’s fixed up any issues (if any even existed).

Thanks for taking the time. I have flagged this thread as “Resolved” in the hope that it helps someone else who hits the same snag. I’m sure they will find it useful.

It is working again. I am not sure when it started working again but I think it was after WP core 4.9.6. Thank you for your very useful plugin.

Surprise, surprise!

I was about to follow @sterndata suggestions but decided to try the update one more time and it worked! I then tried it on 6 more websites and they too all worked.

Thanks @sterndata for the tips but it seems I won’t need them after all.

I’ve added the filter to my child theme functions.php and can confirm that it has fixed the conflict.

Many thanks for the explanation of Open Graph. Love it or hate it, I realise that Facebook is very powerful in the world of social networks. I don’t want to disadvantage my clients by turning off the Automatic sharing. So I’ve turned it back on.

No. Not sure it helps. I’m not familiar with and did not even know I was using “Open Graph Meta Tags”. I assume that you wanted me to add this filter my child theme’s “functions.php”.

It seems simpler for me to just turn off Jetpack’s “Sharing” feature called Automatically share your posts to social networks. I know this is probably using a hammer instead of tweezers but it’s a much more “obvious” approach.

I’ve alerted the author of the Insert PHP plugin as you suggested.

Thanks for confirming the conflict.

I was trying to distil the problem to its simplest form. I thought the purpose of our discussion was to get to find the cause of the problem not to discover some flaw in my PHP. The question at hand is ‘Why does turning on a feature in Jetpack cause a fatal error related to an attempt to redefine a PHP function?’

The simple PHP “code” I sent you uses the same function name “cleanup” (for the purposes of continuity in our discussion), it is not the “real” code of my “cleanup” function.

My “real” code really does “clean” something. But it has no bearing on the cause of the problem. I’m convinced that if you installed both Jetpack and Insert PHP and created a page with the simplified code I sent, you should find that it fails with the fatal error.