Breaks ability to activate or deactivate plugins

You will need to access your server via FTP or logging into the cPanel, then to your site’s root folder > WP Content folder > Plugins folder, and then manually delete the Cloudflare folder… After that you can install 1.3.24, either by downloading and uploading it to the Plugins folder while you are there, and then reloading your site’s plugins page and activating, -or- by uploading via your site’s plugin upload page and activating, -or- by doing a fresh install via the site’s add a new plugin area and activating…

Regards…

Hi All,

Marking this as resolved as the plugin appears to be stable now. Again I’d like to apologize for any issues this caused everyone. Please create new tickets for any new issues that come up.

Thanks,
John

Heads up to other people: when you were looking for a solution to your site being broken at random while having this bugged CloudFlare plugin version, you might’ve saved some options, for example in WP Super Cache. Since the sanitization (urlencode) of all POST and GET vars was turned on, when saving the WP Super Cache settings, it broke the cache directory set in /wp-content/wp-cache-config.php and you have to set it manually to:
$cache_path = WP_CONTENT_DIR . '/cache/';

Check for other stuff which you might’ve broken along the way of trying to fix this.

@jwineman, I assume you’re not sanitizing all the POST and GET vars any more with the new version?

@krysztof Correct, 1.3.24 no longer sanitizes all input.

Thanks for the reply ??

The way you are handling this is still prone to cause issues since you run POST variables named “cloudflare_zone_name”, “cf_key”, “cf_email”, “dev_mode”, or “protocol_rewrite” through your filtering function all the time, even if their use is not related to your plugin. It would be better if you instead did the sanitization when you are assigning the value of these variables to another variable in the function cloudflare_conf.

You can find information on sanitizing user input data in WordPress plugins here.

@jwineman, I don’t understand the code, but this seems to be a reasonable offering/consideration from @whitefirdesign…

I am hoping you will feel called to respond to what he is suggesting, here in the thread…?

@whitefirdesign @crzyhrse – Yes we’re planning on making major changes to the plugin including what WhiteFirDesign suggested. The goal of 1.3.21 – 1.3.24 was to patch the vulnerability and get the plugin back into a stable state before we make more changes.

@jwineman, thank you for this reply…

Kind regards…