I have a lot of experience with css quickly and this worked OK until the site stopped serving up css changes – including launch-critical ones.

This first showed using Site Origin CSS editor – while the SO file on the server was been updating correctly but css served up has been ~ 12 hours stale across many browsers and 4 hard-refreshed devices, despite purging and disabling litespee dcache, optimole. I have no CDN and i host on hostinger.

I then disabled SO and moved css into Spectra’s Additional CSS panel, it worked briefly and then within a few hours the same issue – changes not showing.

This is driving me nuts. as the generally bugginess and WYSInotWYG nature of FSE has already cost me weeks and now just as i thought i could finally launch subject to a few tweaks i simply can’t do what I could always do well…?code css :(.

I have taken time to try and get to grips with how Spectra is injecting custom css, but i’ve really run out of options.

Again, caching ahd optimol disabled, no CDN yet, multiple devices hard refreshed, and in the original Site Origin case, SO was saving the css correctly on the server. It seems that Spectra is simply not updating the custom css – whether from third party editor or native to theme that gets injected into each page.

How can i get Spectra One to do this please.

Desperation is taking hold here.

<!– wp:paragraph –>
<p class=””>Cloudflare support blames my plugins which are bare minimum. THere are tons of posts about this issue on their forum but they get closed out after no activity for a few days with no response from cloudflare.. APO seems like an abandoned product. </p>
<!– /wp:paragraph –>

Undefined index: wp_db_temp_dir at wp-content/plugins/wp-db-backup/wp-db-backup.php:112

Here’s Line 112, which is inside of the wpdbBackup class.

$requested_temp_dir = sanitize_text_field($_GET['wp_db_temp_dir']);

Someone even made a pull request to fix this issue, but it has been sitting open, in purgatory, for years.

Based on the staleness of this plugin, I would not recommend it to anyone.

The problem:
We use WooCommerce and some time ago renamed a global attribute from ‘Available From’ to ‘Suppliers’. This has worked fine, until we disabled the redis cache (not the whole plugin). As soon as it’s disabled the old attribute is back and the new one disappears. We’ve only recently noticed this as we have a plugin that’s reliant on ‘Suppliers’ attribute and throws a warning if it doesn’t exists. It’s as if there’s a second old cache. After some digging it appears that deleting the transients when Redis Cache is disabled clears the problem and gives us back ‘Suppliers’.

It’s not very often we’d run with Redis Cache disabled, just during a bulk import or upgrade. but it does raise the question, is there more than just this attribute that has an old transient that’s been used while the cache is off that we don’t know about?
I’m fairly sure that transients should expire, so not sure why one being a few months old would be valid but seems to be.

As I said at the start, it’s not really a Redis Cache issue, but does present when you disable it. Not sure if the transients could/should be cleared if the cache is flushed/disabled?

Question:
Whenever we disable the redis cache for imports or upgrades, we always flush the cache then disable and when reactivating it we activate and flush the cache again just to make sure nothing old is in there. Does either disabling or enabling the cache automatically flush?

ps thanks for a great plugin.

So the Live Weather Station plugin should 1) warn at least on the backend that stale data is used and 2) the date/time on the widgets (at least on the outdoor widget, probably the same for all widgets) is current, though the input data is stale. This stems probably from the fact that it is a “virtual” weather station where the displayed data is synthesized – but stale input data will result in incorrect calculated data. So the widgets should show the date/time of the input data.

Error logs fill up with the following, and running WP-CLI without the --skip-plugins flag will cause any and all WP-CLI commands to fail:
PHP Fatal error: Call to a member function get_options() on a non-object in plugins/simplemap/classes/maps.php on line 116

The exact issue can be found in simplemap/classes/maps.php, a file which states This handles ONLY single location maps and also mentions Handles all our map making duties (well it will be taking over shortly anyway). Whether or not this file in fact handles “single location maps”, “all map making duties”, or both single and all maps is anyone’s guess.

But that doesn’t seem to matter anymore considering it’s been over 7 months since the developer pushed out a broken update, never once thinking to check if the last update was taking down sites because of errant code.

The method set_map_atts within this SM_Map_Factory parent class attempts to pull default map settings via $defaults = $simple_map->get_options(); but the $simple_map global (gross) object doesn’t actually contain that default data. Instead, the file simplemap/classes/simplemap.php actually contains the get_options method with default data, but isn’t assigned to that $simple_map global object.

Of the various possible fixes, the quickest might be to manually change line 116 in simplemap/classes/maps.php from $defaults = $simple_map->get_options(); to $defaults = get_option( 'SimpleMap_options' );. However, this call to $simple_map->get_options(); is strewn throughout the codebase so many times that it isn’t even worth trying to fix.

Not to mention this plugin makes liberal use of JavaScript eval(), a function that MDN itself clearly states Do not ever use eval!.

This plugin should be removed from the repository and a big red warning should be affixed to the top of the page: “DO NOT USE THIS DEAD PLUGIN!”

Because you only publish the Home Page once, Search Engines might think your website is outdated. This can be prevented by DISabling the following options.
Add article:published_time to Home Page?
Add article:modified_time to Home Page?

Shouldn’t that be ENABLING?

WPMU DEV member here, found this plugin through recent blog there, and very glad I did. Excellent work here. Thanks!!!

We face the issue of stale page cache on Frontends. My guess is that the Slave db update does not trigger hooks to update file cache on each of the Frontends.

Also we disabled wp-cron in favor of the real cron job triggering wp-cron.php

Question 1: what are the ways to trigger W3TC cache refresh on a Frontend via command line or a web request?

Question 2: how can a cache refresh event on the Backend be populated off to a command line script perhaps?

https://www.ads-software.com/plugins/w3-total-cache/