jwineman

@g-olly,

The IP rewrite functionality in WordPress only works at the application level, meaning only WordPress and its plugins will see the rewritten IP. If you need server wide IP rewrite for applications other than WordPress (like awstats etc) then you need to use mod_cloudflare.

Thanks,
John

Hi @artigianidelweb and @webitman,

We aren’t suggesting you modify file permissions, we occasionally see incorrectly permissioned files as the root cause of issues like this which is why we ask. 755 and 644 should be fine.

Are there any errors in the browser console?
Are there any errors in the PHP error log?

Thanks,
John

Hi @pjv,

Let me try to give you a little context into why we redesigned it this way. @thellimist and I are the only developers on the partners team, which is responsible for all of our 3rd party integrations. We have around ten integrations which are completely separate code bases for different platforms including Magento, cPanel, Plesk, and WHMCS.

Managing new feature development, bug fixes, and version migrations for all these plugins was too much work for two developers so last year we started rewriting them on to a common code base. We have a backend which contains all the common code to our PHP based integrations and we have the React/Redux app on the frontend like you mentioned.

The reason the JS is 1+MB is because ALL of the plugin logic lives there. Moving all the logic to the front end allows us to share more code between our plugins. When we implement new features we only implement them once on the front end. Then every plugin we support can get access to that feature immediately instead of a developer having to code that feature into the custom backend for each plugin. A majority of our bugs are also fixed once in the front end but apply to every other plugin which uses our React app.

I agree that using React to create a WordPress plugin is overkill but we decided to do it because we think it will help us maintain more stable integrations over the long term and push new features out faster.

Thanks,
John

So the root cause of this is caching right?

https://github.com/cloudflare/Cloudflare-WordPress/blob/master/compiled.js
https://github.com/cloudflare/Cloudflare-WordPress/blob/master/config.js
https://github.com/cloudflare/Cloudflare-WordPress/blob/master/lang/en.js

Are being cached on CloudFlare, or in your browser, or both. Doing a hard refresh on the plguin won’t refresh config.js and en.js. I think you’ll need to visit those URLs directly and do a hard refresh.

We’ll work on making sure these assets aren’t cached in the next release.

Thanks,
John

Hi @peopleinside,

We’re no longer supporting protocol rewrite and instead only supporting rewriting to https. If this was the only reason you were using the plugin I suggest you downgrade to 1.x.

Thanks,
John

@g-olly,

Sometimes what happens is Cloudflare users will do a full cache purge and if their site has a lot of traffic the requests from Cloudflare to the origin to get to cache the updated content are seen as an attack but this subsides after all the content is in cache again.

If your host is seeing a legitimate attack coming from Cloudflare IPs we would ask that they file a support ticket with us so we can investigate.

Thanks,
John

No worries! Thanks for using Cloudflare!