fatjester

Ok, thanks!

Hello, I am trying to utilize this hook from a plugin, but it never seems to fire. Does it have to be done as a mu-plugin with specific alphabetical name, or is there a more supported method to utilize this?
Thanks!

A good question. More capabilities for various features would be nice in the long run, but I understand that would be a lot of work and would require more planning.

For now a single capability instead of a hard coded role would suffice as it wouldn’t impact the default plugin in any way (where you would give the capability to the administrator by default) except to give developers a way to expand access to other roles.

I don’t mind taking the risk of users breaking things if I give them access to so – as it is now, I either need to give them full admin access or I need to fork your plugin (which I’ve done for now), both of which have the same risk.

You need to add this filter to your theme:

add_filter( ‘wplmi/force_update_author_id’, ‘__return_true’ );

It is, but you need to add the filter he made to your theme (or make a plugin):
add_filter( ‘wplmi/force_update_author_id’, ‘__return_true’ );

Hello,
We had the same error.
It looks to be related to an underlying product they are using for their options panel.

This plugin fixed it for us:
https://github.com/Freemius/freemius-fixer/

Hope this works for you.

This is a snippet that we use in conjunction with this redis plugin:
https://www.ads-software.com/plugins/purge-varnish/

function flush_preview_post($option_name) {
  if($option_name === 'public_post_preview'){
    wp_cache_flush();
  }
}
add_action( 'update_option', 'flush_preview_post' );

You should be able to replace the wp_cache_flush() with the flush function from whatever redis plugin you use. You might want to flesh it out a bit so it only runs when the redis plugin is active.

My Apologies,
This looks like it wasn’t caused by an update, but a coincidence involving several sites where several clients had inadvertently disabled the option.

Thanks for looking, and sorry for the incorrect bug report!
Chris

Thanks so much for the update to the plugin!
Things working great!

-Chris

No problem,
Here are my steps to reproduce.

1. fresh install of wordpress (I use the default docker container with mariadb)
2. open site’s mainpage in chrome, open chrome devtools, click network, click the main html file, look at “Headers”, notice under “Response Headers” there is no “Expires” header.
3. install and activate the “Custom Sidebars” plugin
4. refresh the site’s mainpage and look at the headers again, notice there is now an “Expires” header set to “Expires:Thu, 19 Nov 1981 08:52:00 GMT”
5. deactivate the “Custom Sidebars” plugin
6. refresh the site’s mainpage and look at the headers again, notice the “Expires” header is gone.

As noted earlier, this is from the plugin creating a php session for all users.
In php if a session is created, it defaults to expiring the page to prevent sessions from caching.

Let me know if you have any other questions about replicating the issue.

Thanks,
-Chris

Hmm,
4 weeks without any reply.

Bummer ??

-Chris

Hello,
Just checking in on this.

Thanks,
-Chris

This also started for us today after we updated to WP 4.3 on a multisite with a network activated version 1.1.8

Same here

@pierre: I can second that the new data.php solves this – I had the same issue.
Thanks!