jroberts.gd

I’ve never had to do it myself, but I’ve read other maintainer’s blog or comment on the challenge of managing an open source project. While my preference would be for a public repo where changes can be validated through a PR process, I recognize the burden this places on contributors like you and I understand your reasoning.

Thank you again for your work and responsiveness.

Thank you Saumya for the quick response and patch. I’ve tested this version and it resolves the issue. I’m now able to use wp option pluck and wp option patch to execute operations like wp option pluck swcfpc_config cf_apitoken.

I’m new to how WordPress plugins repositories are managed. Can you help me understand why you’ve chosen to keep this particular plugin repo private?

For reference: https://nacin.com/2010/04/18/wordpress-serializing-data/

The changes would be in wp-cloudflare-super-page-cache.php, line 369 and 381 where the serialization is redundant:

$this->config = unserialize( $this->config );
update_option( 'swcfpc_config', serialize( $this->config ) );

Justin,

Thanks for the quick response. We’re only using this in a test environment at the moment. Do you think this might be worth opening an issue within the Gutenberg repo?

Maybe something like this would help?

$post = get_post( $post_id );

if ( !is_null( $post ) )
  $parent_id = $post->post_parent;
else
  $parent_id = 0;

• This reply was modified 7 years ago by jroberts.gd.

Same experience as @demaier.

While I agree with keeping core as up-to-date as possible, there is sometimes a situation beyond one’s control that requires the use of older core versions. We have one such legacy multisite (a gem of technical debt) that uses a Headway theme in such a way that updating core past 4.2.13 breaks the site. The Headway themes are no longer supported and updating is not an option as there are breaking issues also with that. While we are in the process of migrating to a new solution, the site must remain live for active campaigns. So yes, it is less than ideal, but it is at the latest minor branch version and plugins are kept updated where possible.

Wordfence 6.3.5 broke this site and I had to manually revert to 6.3.4. The failure here was fourfold:

1. I should not have allowed any plugin, no matter how respected, to autoupdate without first testing it in development.
2. Wordfence did not give their customers advanced notice of the breaking change (i.e. adding a dependency on a function present only in 4.4.0+)
3. Wordfence did not update their WordPress plugin page to change the minimum compatibility from “3.9 or higher”.
4. Wordfence released late on a Friday knowing their support staff are offline for the weekend.

The bottom line is that I now need to disable auto update for this plugin across all my production sites, and manually push updates using Ansible only after first testing in development. Not everyone has this capability or workflow in place to protect themselves.

Wordfence is good at security, but my guess is they are still growing as a development shop. They need to take lessons learned from the DevOps movement and improve in a hurry.

I’ve experienced a similar issue in which Wordfence, while it did catch a number of malware, failed to detect over 800 backdoor threats. I only became aware of them when using Sucuri’s server-side scanner which found multiple threats like this:

Warning: File possibly compromised: ./wp-content/uploads/sites/_input_1_OXK.php5. (php.backdoor.eval_REQUEST.008). Manual review recommended.

This was on an aged multisite using Headway and Gravityforms.