Blueprint by Tiny
Return to
Return to Tiny.cloudTry TinyMCE for Free
Search by


The Setka demo: How we made it

Originally published on between 2017-2021 and migrated during 2021/22. Some details may have changed since the original version was published.

Nikolay Korobochkin

Senior WordPress Developer, 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.

The following are our thoughts on practices that we used when developing the Setka 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 no code design tool for creating articles with multiple columns, special blocks, animations, and versatile extensions.

Setka Workflow

A workflow tool for managing the editorial processes of media, content and editorial teams.

Each of these products is an independent service, but can easily be integrated with a variety of Content Management Systems (CMSs) and e-commerce platforms: WordPress, Drupal, Magento, Ghost, and many more.

Although our clients only see the end result, there’s a lot of ‘behind the scenes’ development work that goes into building these tools. In this article, we’ll discuss and describe the practices that we used when developing the Setka WordPress plugin.

Building the Setka demo

After about 12 months of closed development and testing with a few pioneer clients, we were ready to demonstrate Setka 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’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 demo

Users can request a Setka Editor demo by filling out a form we take the following steps to create a demo:

Create a new Setka 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 plugin on the WordPress installation.

Set up the Setka account that was created in step 1.

Send the user the information needed to access the demo.

Installing Setka

In step 3 of the process, we installed the Setka plugin on WordPress. However, this step requires more than just copying files and activating the plugin – we needed to do a little more work to get things up and running.

Usually, a customer 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 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:

wp setka-editor login YOUR_TOKEN

Storing project builds for the Setka demo

When setting up the Setka 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.

If you tend to commit small files (i.e. not dozens of compressed CSS and JavaScript files), you can view the content and changes of each version.

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.


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 plugin. You can easily roll back to a specific version of the plugin using the WordPress command-line interface:

wp plugin install setka-editor --version=1.25.0 --force

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.

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.



The CI/CD pipeline is one of the best practices for devops teams to implement, for delivering code changes more frequently and reliably

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.

 - test
 - build
 - deploy
 - notify

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.

PHP Code Style:
 stage: test
  - composer install --quiet --no-interaction --no-progress --optimize-autoloader --classmap-authoritative
  - php vendor/bin/phpcs --standard=phpcs.ruleset.xml

This code designates a job in the “test” stage with the name “PHP Code Style.”

.build:demo: &build_demo
 stage: build
   - npm install
   - npm run-script buildPluginTar
   - md5sum dist/setka-editor.tar.gz > dist/wp-md5sum
     - dist/

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.

.staging: &staging
 environment: staging
   - /^staging$/

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.

.production: &production
 environment: production
   - tags

This code is similar to the above example, but it makes production builds and runs on each pushed tag.

 <<: *build_demo
 <<: *production

This code combines two previously defined job fragments (“build_demo” and “production”) into a single job. The “<<” construction indicates a merge operation.

.deploy:demo: &deploy_demo
 stage: deploy
   - aws --profile $EDITOR_PROFILE s3 cp --acl public-read dist/setka-editor.tar.gz "s3://${BUCKET_NAME}/${DEMO_PLUGIN}"
   - aws --profile $EDITOR_PROFILE s3 cp --acl public-read dist/setka-editor.tar.gz "s3://${BUCKET_NAME}/${DEMO_PLUGIN_LATEST}"
   - aws --profile $EDITOR_PROFILE s3 cp --acl public-read dist/wp-md5sum "s3://${BUCKET_NAME}/${DEMO_PLUGIN_MD5}"
   - aws --profile $EDITOR_PROFILE s3 cp --acl public-read dist/wp-md5sum "s3://${BUCKET_NAME}/${DEMO_PLUGIN_MD5_LATEST}"
 when: on_success

After building the tar.gz file and MD5 hash, we push to the Setka CDN with the AWS Command Line Interface (CLI) tool. As before, we define a new hidden job with the alias “.deploy:demo”.

 <<: *deploy_demo
 <<: *production
   - build:demo:production

This code combines the “deploy_demo” job with the production environment, and establishes the dependency “build:demo:production”.

.slack: &notify_slack
 stage: notify
   - php bin/notify-slack.php

This hidden job sends a Slack notification when the pipeline has successfully executed.

 <<: *notify_slack
 <<: *production

This code combines the “notify_slack” job with the production environment.

Final thoughts

The goal of Setka is to create a no code, 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 development process both interesting and illuminating.

For more technical insights and tips on using Setka 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 plugin.

Give Setka a try

Get a demo from our Customer Success team or try Setka for 14 days, free.

Related Articles

  • Content Marketing & Design

    12 best landing page elements to lift conversions

    by Paul Posea in Content Marketing & Design
Subscribe for the latest insights served straight to your inbox every month.

Deploy TinyMCE in just 6 lines of code

Built to scale. Developed in open source. Designed to innovate.

Begin with your FREE API Key
Tiny Editor
Tiny logo
Privacy Policy - Terms of Use© 2022 Tiny Technologies Inc.TinyMCE® and Tiny® are registered trademarks of Tiny Technologies, Inc.


  • TinyMCE
  • Tiny Drive
  • Customer Stories
  • Pricing