The Setka Editor Demo: How We Did It
Senior WordPress Developer at Setka
Kolya Korobochkin has been a developer and knowledge contributor in the WordPress community for 10 years. While writing code, he looks forward to writing tests, automates and research for open source solutions, and sometimes creates and shares his thoughts on WordCamps and Github’s code.
Our thoughts on practices that we used when developing the Setka Editor WordPress plugin.
Here at Setka, our goal is to develop new tools for visionary thinkers who need to efficiently create powerful, meaningful content. That’s why we’ve released two products for brands, publishers, and media professionals:
A WYSIWYG content editor for creating articles with multiple columns, special blocks, animations, and versatile extensions.
A tool for managing the editorial process of media and content teams.
Each of these products is an independent service, but can easily be integrated with a variety of content management systems and e-commerce platforms: WordPress, Drupal, Magento, Ghost, and many more.Although our clients only see the end result, there’s a lot of hard work that goes into these tools behind the scenes. In this article, we’ll discuss and describe the practices that we used when developing the Setka Editor WordPress plugin.
Preparing the demo
After about a year of closed development and testing with a few pioneer clients, we were ready to show off Setka Editor to the general public. Given a list of the desired plugins and themes, our platform can automatically create and set up WordPress sites, dramatically simplifying our workflow.
We wanted to create a full demo, rather than a single page, because it would give us the opportunity to show off Setka Editor’s interaction with other plugins and custom themes.
We also knew that WordPress Multisite wouldn’t be right for this situation. Although we actively use the multisite feature for our own company website and blog, it’s not the best choice for a platform where many users can use different plugins and themes.
Requesting a Setka Editor demo
Users can request a Setka Editor demo by filling out a form with their contact information, including their name, email address, and company. Once we’ve captured this information, we take the following steps to create a demo:
Create a new Setka Editor account with the predefined default set of styles.
Create a new standalone WordPress installation, including the core files and database.
Install the latest stable version of the Setka Editor plugin on the WordPress installation.
Set up the Setka Editor account that was created in step 1.
Send the user the information needed to access the demo.
Installing Setka Editor
In step 3 of the process, we install the Setka Editor plugin on WordPress. However, this step requires more than just copying files and activating the plugin—we need a little more work in order to get things up and running.
Usually, a user enters a Setka token (a unique account license key) on the plugin settings page. This enables the plugin to perform external HTTP requests to the Setka Editor backend service. In addition, the saved token allows the plugin to automatically accept push events with new CSS files if the user makes any changes.
Many user commands can be performed not only through the WordPress interface, but also in the terminal (either manually, or with bash scripts). For example, you can run the following terminal command when in your site directory:
Storing project builds
When setting up the Setka Editor demo, we had to think long and hard about how we would store the plugin builds.
Some developers choose to use a separate, secondary git repository (or a custom branch in the repository). Each commit in this repository contains only the build files required for the production environment.
This approach has a few benefits, namely:
You can easily view your list of versions from a website (e.g. GitHub or Bitbucket), a desktop application (e.g. Sourcetree), or within the terminal.
It’s easy to deploy and switch versions (if necessary) by cloning the repository and checking out specific tags or commits.
SVN (or Subversion), is a version control system similar to Git.Read handbook
WordPress offers an alternate version control system in the form of Subversion (SVN), which is intended for distributing free and open-source plugins. We decided to use SVN to store project builds, as well as all versions of the Setka Editor plugin. You can easily roll back to a specific version of the plugin using the WordPress command-line interface:
Our final decision was to store plugin builds as ZIP archives plus MD5 hashes on Setka’s content delivery network (CDN). Storing builds this way has a few concerns that we need to be aware of:
While developing a WordPress plugin, it’s good to have not only a public stable build, but also beta versions and even work-in-progress (WIP) versions for the QA team. In addition, users should be able to create demo instances with these WIP builds.
In 2017, Setka became a VIP technology partner of Automattic, the parent company of WordPress. We now have additional build releases for the WordPress VIP platform, which is slightly different from the plain WordPress versions. Although we have a separate branch for WordPress VIP, we maintain a single codebase for both types of builds.
Continuous integration/continuous delivery
Here at Setka, we use continuous integration/continuous delivery (CI/CD) practices. CI/CD is a development philosophy in which small changes to the codebase are merged onto a single branch multiple times per day. Merging these changes so often allows you to find bugs and failures early one, before they cause performance issues and crashes in production.
CI/CD system is a separate system/service which is often already integrated with a control system version (Github, Gitlab) and requires only an additional config in your repository. We use the GitLab CI/CD tool here at Setka for performing steps such as validating code standards, testing, building plugin archives, and deploying.
There are a lot of other good CI/CD platforms out there, such as Travis CI, which is free for open-source projects. For the most part, CI/CD tools are fairly similar. The main differences are the types of integrations and additional services that each one supports, which is why it’s good to do your research and try out different platforms before you decide on a solution.
The GitLab CI/CD configuration is stored in the .gitlab-ci.yml file in the project root directory. Below, we’ll discuss the various components of a basic GitLab configuration file, including running validations, making builds, sending notifications about successful pipelines.
We have four separate CI/CD stages for our project. Some developers choose to condense the code in the “notify” stage into the “deploy” stage.
This code designates a job in the “test” stage with the name “PHP Code Style.”
This code is a template of a job in the “build” stage for building a tar.gz archive and its associated MD5 hash.
The construction “.build:demo: &build_demo” indicates the following information:
The job has the name “.build:demo”.
The dot in front of the name indicates that this is a hidden job (i.e. a job that does not run).
“&build_demo” is an alias for this job fragment. As you’ll see below, we can reuse this configuration for other jobs and environments.
“before_script” indicates the code that is run before the job: in this case, installing the required modules for the npm package manager. “script” indicates the code that is run during the job: creating a tar.gz archive with the grunt-contrib-compress plugin, and then create and write an MD5 hash into the dist/wp-md5sum file.
“artifacts” indicates a path that will be saved and passed to the next stages in the CI/CD pipeline.
This code is another partial configuration of a hidden job with the alias “staging”. The variables are here omitted for simplicity. The “/^staging$/” regular expression indicates that the job runs on each commit from the “staging” branch in Git.
This code is similar to the above example, but it makes production builds and runs on each pushed tag.
This code combines two previously defined job fragments (“build_demo” and “production”) into a single job. The “<<” construction indicates a merge operation.
After building the tar.gz file and MD5 hash, we push to the Setka Editor CDN with the AWS Command Line Interface (CLI) tool. As before, we define a new hidden job with the alias “.deploy:demo”.
This code combines the “deploy_demo” job with the production environment, and establishes the dependency “build:demo:production”.
This hidden job sends a Slack notification when the pipeline has successfully executed.
This code combines the “notify_slack” job with the production environment.
The goal of Setka Editor is to create a WYSIWYG, user-friendly environment that makes it easy to build attractive and compelling content for your website. In order to achieve this ease of use, however, we’ve had to put in a great deal of work behind the scenes. We hope you’ve found this window into the Setka Editor development process both interesting and illuminating.
For more technical insights and tips on using Setka Editor, stay tuned to the Setka blog. Want to try things out for yourself? Sign up for a free demo today, to see why so many of our customers love using the Setka Editor plugin.