Title: A conjecture Last modified: October 7, 2016 --- # A conjecture * [pjv](https://wordpress.org/support/users/pjv/) * (@pjv) * [9 years, 7 months ago](https://wordpress.org/support/topic/a-conjecture/) * It looks to me like starting with version 3 you guys have adopted a new development framework based on react and you are still learning it and you have more or less lost control of this plugin. Now those of us who are trying to use the plugin are kind of hostage to your learning your framework and build tools. * Whatever you decide about the future of development of this plugin, I can tell you for sure that there is nothing that it is doing that warrants a 1+ Mb (!!!) javascript file. I’m a WP plugin developer and I’m sorry but that is completely insane. * One developer’s opinion: from an architectural design point of view, using a deep and gigantic framework like react to build a fairly simple and limited WordPress plugin is just a bad fit. It’s like bringing a 70 ton bulldozer into your backyard to put up a garden shed. Viewing 6 replies - 1 through 6 (of 6 total) * [jwineman](https://wordpress.org/support/users/jwineman/) * (@jwineman) * [9 years, 7 months ago](https://wordpress.org/support/topic/a-conjecture/#post-8264410) * Hi [@pjv](https://wordpress.org/support/users/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](https://github.com/cloudflare/CloudFlare-Magento), [cPanel](https://github.com/cloudflare/CloudFlare-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](https://github.com/cloudflare/CloudFlare-Plugin-Backend) which contains all the common code to our PHP based integrations and we have the React/Redux app on the [frontend](https://github.com/cloudflare/CloudFlare-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 * Thread Starter [pjv](https://wordpress.org/support/users/pjv/) * (@pjv) * [9 years, 7 months ago](https://wordpress.org/support/topic/a-conjecture/#post-8265766) * Thanks for the reply and for providing all the context. It yielded an understanding of why you made the architectural decisions, though I still think they were/are poor decisions. * I meandered through the repos you linked and the amount of abstraction and the heaviness of the frameworks you are leveraging to attempt to use a single codebase for multiple platforms still seems bonkers to me. * Here’s why from two different points of view: * 1. Developer’s POV * I think at very best the end result on each platform you are supporting will be a massively over-bloated plugin that maybe kinda, sorta works but will likely be very brittle specifically because you are trying to support multiple platforms with one giant codebase and when you make fixes (for example) for WordPress, you are going to end up creating new issues for Magento. * I think you will always be chasing your tail and fighting with the scope of the abstractions and complexity of the dependency-tree in your codebase just to make really simple fixes that would take a couple lines of code and 10 seconds in a native plugin. * Again, I understand why you are trying to consolidate all your integrations into one codebase and I hope it ends up working out for you, but I think it’s unlikely. When I think of how streamlined and simple a WP Cloudflare plugin could be, leveraging the new v.4 CF API, it makes me feel tempted to write it myself ;^). * 2. End User’s POV * So I am someone who writes a blog on WordPress and a techy friend of mine told me I should use Cloudflare to speed things up and protect me from DOS’s (whatever that means). So I signed up for Cloudflare and figured out how to set up all that DNS stuff and then I installed the Cloudflare plugin in my WordPress. Now my admin area takes forever to load, at least the first time. Maybe I’m not using it right, but I thought Cloudflare was supposed to speed things up. And the settings page for the Cloudflare plugin also kind of acts weird – at least it doesn’t look and act like all the other plugins I use. * I’m not really sure how to stress how out of proportion it seems to me to force a 1.3 Mb .js filled with code abstractions supporting WP, Magento, cPanel, Plesk, Joomla, Drupal, whateverthehellelse, to download and be parsed by the browser for one obscure plugin that doesn’t really do much more than let me turn on and off CF features (which I could otherwise manage directly on the CF website) from within my WP admin. For crying out load, all it needs are a few buttons that shoot off a php-curl request! It’s a single Class file with a few hundred (at most) lines of code. * And now speaking as a non-metaphorical admin who runs a bunch of WP sites, you are at 3.0.6 and I have tested each release from 3.0 on and I am still running v. 1.3.25 on all my production sites. * You are listing HTTP2 push as a feature but as far as I can read in your changelogs, you disabled it in 3.0.2 and have not yet re-enabled it (though I think there is a workable, though not ideal, fix for the bloated headers problem that you can find here: [https://github.com/daveross/http2-server-push/commit/ae95e8149ae131d07a71fa35ec2d0f7e88d7d03f](https://github.com/daveross/http2-server-push/commit/ae95e8149ae131d07a71fa35ec2d0f7e88d7d03f)). * You are no longer making use of spam submissions and I can’t tell whether you are still doing anything about re-writing IP addresses for server logs as that has been dropped from the plugin description. * If you subtract out stuff that you could otherwise do on the CF website, can you tell me what the CF WP plugin is actually providing at this point? * [jwineman](https://wordpress.org/support/users/jwineman/) * (@jwineman) * [9 years, 7 months ago](https://wordpress.org/support/topic/a-conjecture/#post-8272408) * So yeah with regard to http2, its disabled right now while we test a 4k limit fix similar to the one you posted. * The spam submission functionality was removed because the API endpoint that consumed that data was deprecated, if we ever expose it publicly again we’ll bring it back. * The plugin still restores the original visitor IP, code [here](https://github.com/cloudflare/Cloudflare-WordPress/blob/master/cloudflare.loader.php#L8). * Our goal for the plugin to expose the settings you’re most likely to use so that you can edit them without having to visit Cloudflare.com and more tightly integrate with plugins that have cache purge functionality. * Thanks, John * [Jeffrey](https://wordpress.org/support/users/zeroandone/) * (@zeroandone) * [9 years, 7 months ago](https://wordpress.org/support/topic/a-conjecture/#post-8334676) * So well said. I upgraded to 3.0.3 and got a blank settings page, so I rolled back to 1.3.25. Then I upgraded to 3.0.5 and still got a blank settings page, so I rolled back again. Now I just upgraded to 3.0.7, and I STILL GOT A BLANK SETTINGS PAGE. This 406 error must be a very hard bug to fix. * I prefer to have a plugin that works than more features. * [thellimist](https://wordpress.org/support/users/furkan811/) * (@furkan811) * [9 years, 7 months ago](https://wordpress.org/support/topic/a-conjecture/#post-8334839) * Hi [@zeroandone](https://wordpress.org/support/users/zeroandone/), * In [this](https://wordpress.org/support/topic/3-0-5-blank-setting-page/page/2/#post-8276996) post we’ve figured out the reason of 406 error. * Currently the latest version of the plugin is 3.0.6. In version 3.0.7 this bug will be fixed. * Thanks * [thellimist](https://wordpress.org/support/users/furkan811/) * (@furkan811) * [9 years, 6 months ago](https://wordpress.org/support/topic/a-conjecture/#post-8448561) * Hi [@zeroandone](https://wordpress.org/support/users/zeroandone/), [@pjv](https://wordpress.org/support/users/pjv/), * Cloudflare WordPress Plugin 3.1.0 released. * **Changelog:** [https://en-gb.wordpress.org/plugins/cloudflare/changelog/](https://en-gb.wordpress.org/plugins/cloudflare/changelog/) * Thanks Viewing 6 replies - 1 through 6 (of 6 total) The topic ‘A conjecture’ is closed to new replies. * ![](https://ps.w.org/cloudflare/assets/icon-256x256.png?rev=2471183) * [Cloudflare](https://wordpress.org/plugins/cloudflare/) * [Frequently Asked Questions](https://wordpress.org/plugins/cloudflare/#faq) * [Support Threads](https://wordpress.org/support/plugin/cloudflare/) * [Active Topics](https://wordpress.org/support/plugin/cloudflare/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/cloudflare/unresolved/) * [Reviews](https://wordpress.org/support/plugin/cloudflare/reviews/) * 6 replies * 4 participants * Last reply from: [thellimist](https://wordpress.org/support/users/furkan811/) * Last activity: [9 years, 6 months ago](https://wordpress.org/support/topic/a-conjecture/#post-8448561) * Status: not resolved