EasyEngine v4 Development Begins

Posted by Rahul Bansalon Category NewsTagged , ,

EE v4 development begins!

Update: I have published a followup post providing more details.

After a long hiatus, during which we worked mostly on bug fixes and security patches, we are back in full swing with EasyEngine’s development.

EasyEngine v4 will have a “sub-set” of the current feature-set. In technical terms, this is another round of refactoring, and hopefully a final one! I am not a big fan of refactoring big projects, but sometimes you have no choice! 😐

We are aware of the many pending feature requests- this release will not have any additional user-centric features, but focus on the developer side of things.

v4 Goals

We are developing v4 in PHP, based on the WP-CLI project. Current goals are:

  1. Make v4 modular with something like ee packages , based on WP-CLI packages. This is the primary goal of this version. We not only wish to support adding new commands but also adding new arguments to existing commands. As an example, ee site create commands could have ee site create example.com --laravel which as the argument suggests, can be used to set up a Laravel site.
  2. Reuse as many things from the WP-CLI project as possible. Going ahead, the idea is to contribute back more frequently. We wanted to use WP-CLI as a “framework,” but as it is a “project” itself, it took some time to figure out how to get started.
  3. Move some core features to packages, depending on the success with ee packages. Our plan is to remove some core features such as mail stack, admin tools,  HHVM support & W3 Total Cache support and move them to EasyEngine packages. The remaining features will be left to the community.
  4. Make migration from v3 to v4 smoother by having fewer v3 releases during v4 development. This will effectively deprecate some v3 features.
  5. Move EE admin tools into its own repo and maybe manage it via an EE package.

That’s it! No new features! In fact, as mentioned, we plan on removing some features from the core and turning them into packages.

It is always hard to maintain something that we don’t use ourselves. This is why I firmly believe that packages are the right direction for some features.

Call for contributors

In the past, a common reason why EasyEngine users did not contribute when asked is because they did not believe they had the Python skills needed.

These users should find it easier to contribute to v4, now that the project has been shifted to PHP and WP-CLI.

Another motivation to contribute is the package system. You can now build EE packages that can be completely free, paid or free packages that make consuming your premium offerings easier. In any case, we will help you with package distribution.

Some ideas for packages you may consider are shared hosting support or integration with a premium backup service.

We are also considering setting up a marketplace for EE packages, but it’s too early to say more.

How do I contribute?

The first thing you should do is join the #v4 channel on EasyEngine’s slack team.

You can also join the v4 project on Github – https://github.com/EasyEngine/easyengine/tree/feature/v4.0.0 . As always, all core development will be visible to all.

Some other ways you can get involved:

  1. Design/Architecture – If you know WP-CLI inside & out, please contact us ASAP. You are most wanted! ?
  2. Development – You can work on any open issue, or even better, create some packages. ?
  3. Testing – If you are familiar with PHPUnit/Behat, you can help with testing. ✅
  4. Documentation – We do not anticipate many changes with EE commands themselves. But existing documentation can always be improved ?

If you feel you can contribute in any other way, please join us! You can reach out to us on Twitter or Facebook.

Links: EasyEngine on Github | Join EasyEngine Slack Team

Update: I have published a followup post providing more details.

9 responses to “EasyEngine v4 Development Begins”

  2. Sounds interesting.
    Will you still support Modules like Mail and such after moving to php?

  3. Hmm, I was assuming the GUI interface for managing server.
    But good to see some progress.

    Keep it up

  4. I am not sure moving from Python to PHP is such a good idea. I am new to EE but I think its power comes with the fact that it is based on python and not dependant on PHP. Being dependant on PHP will make it less and less portable. E.g. changing the PHP versions? What about bash scripting? Did I misunderstand anything here? Creating a WP CLI package is fine, but moving EE into a PHP package as a dependency to WPCLI is a strange proposition…

    Why is that happening? What are the pros and cons?

    • I am new to EE and still getting the hang of it, but I am kinda bummed out of this direction. Python is far superior as compared to PHP. Making EE dependent on WPCLI in my humble opinion is not a smart move — unless of course, I misunderstood this.

      Here’s an example! Every backup solution I tried which depends on PHP is broken. Duplicator, UpDraft, BB, MWP, VPress, etc.

      I might be doing it wrong, but delete your WP site then try to one click restore them with these solutions. Since the are dependent on PHP and WP, and there’s nothing there… none of the solutions worked. I went far ahead to try to restore sites over new installation but several solutions tripped.

      EE is Python and Bash, I went ahead and built a Backup/Restore CLI which knows EE, it’s NGINX architecture, and is inherently just needs one single command to backup/restore, without any dependency on PHP.

      That’s true form of one click (or one command in my case) site restore, with no dependencies.

      So, my next move was to build EE’s wrappers for Bash, ZSH’s Oh My ZSH, maybe even something with Go. But PHP dependency will make things worse.

      “We are developing v4 in PHP” <> that’s like saying hey, people PHP was fun, but “We are developing WP v5.0 in ROR” and it will only support the subset of features you had before.

      So, I recommend another approach, instead of abandoning Python, and Bash, why not just build an EE’s wrapper for WPCLI.