Category: Developer Tooling

DevKinsta: Initial Thoughts and Feedback

I’ve used a variety of local development environments over the years and some of them have done a decent job – but none of them have been the one. Back in January when I first saw DevKinsta announced over on WP Tavern I was excited to give it a try. I’ve finally tried it and wanted to share some thoughts and feedback on DevKinsta.

Installation (on Windows)

DevKinsta uses Docker to containerize the various services DevKinsta launches. Docker utilizes Windows Subsystem for Linux 2 (WSL2) under the hood which is part of the Windows Operating System. You’ll need to install it and Docker if you haven’t already.

The official documentation suggests you need to have Hyper-V and Containers enabled in Windows Features (Settings–>Control Panel–>Programs and Fetaures–>Turn Windows features on or off) but I have neither enabled on my system. All I have installed on my system is the Virtual Machine Platform and Windows Subsystem for Linux.

Once you have WSL2 and Docker installed and enabled you can actually install Kinsta. The Kinsta portion is straightforward.

First Installation Screen

Kinsta installs itself in Users\{user}\AppData\Local\Programs\DevKinsta which still seems a bit weird to me. But I’ve seen other apps doing this as well. I’m not a huge fan of having so many places to look for installation applications (above, Program Files, Program Files (x86), AppData\Roaming, etc.) but I’m guessing this is the new and Microsoft sanctioned way of doing things?

Choose the location for DevKinsta to install.

Once the install is complete you see the completed screen and can run DevKinsta. Woohoo!

The Completed Install Screen for DevKinsta

Running DevKinsta for the First Time

The first time you launch DevKinsta it will take a while to launch (I’m guessing at least several minutes for most folks). This is because DevKinsta is downloading the images it uses with Docker…and I do mean images plural: devkinsta_fpm, devkinsta_db, devkinsta_nginx, devkinsta_mailhog, and devkinsta_adminer (that’s five images if you weren’t counting).

DevKinsta Downloading Images. 1 / 5 indicates it is on the first of the 5 images.

After this first time things move much more quickly. The normal loading screen you’ll see is gone in a flash. I expect there will still be occasional slowish starts as Kinsta makes changes to the underlying images and these changes need to be applied to the containers running on each of our local systems.

Your Day-to-Day DevKinsta Loading Screen

Creating a New Site

Once DevKinsta is loaded you are provided with a slick UI and three big options: New WordPress site, Import from Kinsta, and Custom site.

The Create New Site Screen

Adding a new site is extremely simple. Give the site a name and provide a username and password and Kinsta takes care of the rest.

New WordPress Site Screen

Note that Kinsta is making all the decisions for you if you take this route. If you need to customize your install you’ll use the Custom Install option. Using this option you can choose a PHP version, enable HTTPS, select a specific WordPress version, create a Multisite and so on. Still pretty simple and straightforward.

Custom Site Screen in DevKinsta

The Docker Warning

At some point you’ll be warned by Docker that Docker has detected Windows files being shared into a WSL 2 container and that this may result in poor performance.

Lets break that down a little. Windows Subsystem for Linux 2 is a Windows component that provides a light Linux installation. Docker uses WSL 2 when creating containers. If you mount files from your Windows filesystem to the container (which is utilizing WSL 2) the speeds deteriorate. You really want to have your files mounted inside of the container.

I usually spin up containers from within WSL to avoid this problem but Kinsta didn’t. Why not? Because Kinsta wants you to be able to browse and edit those files in your native Windows filesystem and when they are inside the container they are available on the Linux filesystem and not the Windows filesystem.

Now technically that isn’t entirely true. You can setup a network share from which you can access files within your Linux container, but that all is a bit messy. Maybe someday they’ll add an option that allows you to have the files reside in the container rather than on the Windows side and we’ll see some performance boost, but I understand why they did it this way.

Docker Warning About Using Windows Files in WSL 2 Container

The Individual Site Dashboard

Once the setup of your new site is complete you get a nice dashboard that allows you to manage your site.

Most of the Site Dashboard Screen
The rest of the Site Dashboard Screen

You can see the features yourself so let me just point out a few of the highlights:

  • You can quickly open the site frontend or backend (WP Admin).
  • The Database Manager (Adminer) is easily accessible.
  • The site host provides the URL and the site path provides the file system location of your site.
  • You can toggle SSL/HTTPS on.
  • Information about the database is clearly presented allowing for easy remote access.
  • You can easily toggle WP_DEBUG on and off.

There is one glaring omission – there is no one click access to the terminal. Instead you’ll need to whip out some command-line expertise – or read the DevKinsta documentation.

Settings

The Settings are rather sparse – two that I think deserve attention here. First there is the option to enter a site path – this is the local filesystem location for projects. This isn’t for a specific project but for all projects overall.

The Settings Screen
The Rest of the Setting Screen

The second is configuring what you want the default username and password to be for WordPress installs. It’s a minor convenience but still nice.

Visual Studio Code Dilemma

VSC has this killer extension (err extensions) that allow one to work on remote (or virtual) systems as if they were local. Unfortunately, when you attempt to connect the kinsta_fpm container to VSC you are dropped in the root directory and the Kinsta files are nowhere to be found.

You can break out by using File–>Open Folder and navigating to /www/kinsta/public/some-site but it isn’t ideal. I’d love to see a tighter VSC integration.

How Does It Compare to Local?

Overall I’d say it compares pretty favorably to Local. Personally, I don’t like having my dev servers installed on my local host, I want them virtualized or containerized. This reduces the surface area open for attack on my local machine and helps avoid munging of my system which happens on occasion by even the best intentioned software.

How Does It Compare to VVV?

DevKinsta is simple to use and its reliance on Docker rather than Vagrant/VirtualBox is attractive to me. However, VVV still comes with more tools – PHPUnit, Xdebug, Composer, NodeJS, git, and Subversion being the most notable in my opinion.

I’d love to see these tools included with DevKinsta as well…NodeJS especially needs to be there for folks to do Gutenberg development.

Summarize/Expand on Missing

I like a lot about DevKinsta but there are some features that are missing of varying importance. I’m going to summarize up those I’ve already listed as well as add a few more below.

  • High Priority
    • Addition of button on Site Info to launch shell.
    • Addition of NodeJS.
    • Addition of PHPUnit, xdebug, and Composer.
    • Addition of git and subversion.
    • Be open source.
  • Medium Priority
    • Addition of Apache as a web server option.
    • Better integration with Visual Studio Code.
    • Provide the option to use the GUI to manage wp-env.
  • Low Priority
    • Provide option to use WSL 2 filesystem rather than native Windows filesystem to improve performance.
  • Low Low Priority
    • I’d like to see more logging detail on what DevKinsta is doing while updating my Docker containers. Not because I actually need to know but it soothes me to see the logging scrolling past indicating that no, this software has not frozen.
    • I’d like to see more logging detail in general without having to dig for logs.

Conclusion

DevKinsta is a solid option for a local dev environment. I’d like to see them open source it and think this would facilitate faster innovation. The lack of Gutenberg support built-in and the lack of native tooling is a big bummer for me. I’m leaning towards using wp-env at least for the moment.

Your thoughts?

Headless WordPress

For step-by-step instructions on using WordPress as a headless back-end with Gatsby as the front-end see the GitHub repo

Interesting Note: We’ll be looking particularly at static site generators (SSGs) of which Matt Mullenweg is not a fan.

What is Headless?

  • Some confusion regarding terms due to inconsistent use within community (which tends to happen):
    • In a generic sense, “head” is the front-end (UI) of a site (do we actually use it that way?) so “headless” is a site without a front-end.
    • “Headless” sites have existed in the WordPress ecosystem using the REST API.
    • More recently, the term has been used in association with Static Site Generators (SSG’s) such as Gatsby, where WP serves as the back-end (“headless”) and Gatsby serves as the front-end (“head”).
    • While other languages (Go: Hugo, Ruby: Jekyll) provide SSG’s, the most popular are in JS and these are often referred to as using the Jamstack (JavaScript, API, Markdown).

Why Use Headless?

  • Performance Gains
  • Scalability
  • Reduced Cost (at scale)
  • Security Improvements
  • Decoupled UI
  • Use Latest JS Frameworks
  • Separation of Concerns (SoC)

Downsides of Headless

  • Now maintaining two separate sites – WP back-end and front-end.
  • The complexity of front-end frameworks (e.g. React) reduces productivity in the short-term.
  • Loss of plugin functionality (most WP plugins won’t work in a static environment).
  • Must be rebuilt every time a change occurs.
  • Takes a long time to build (depends).

WP Plugins for Generating Static Sites

WP Static Hosts

WPGraphQL

Learning More

Resources

Questions

  • WP Search? wp-search

Things I’ve Learned Using Flywheel Local

Where Local Lives on Windows

All sites are installed in a Local Sites folder at a path something like C:\Users\username\Local Sites.

The software itself is installed at:

C:\Program Files (x86)\Local\

You can find the component server software used by Local in the extraResources subdirectory. nginx, php, mysql, mariadb, and mailhog are yet one level deeper inside lighting-services.

Within the specific server software folder you’ll probably need to find the desired binary (e.g. if you are confusing a code editor). For me this looks like: \php-7.3.5+6\bin\win64\php.exe.

Note, however that you’ll want to edit the configuration files inside of your specific Project within Local Sites. For example, php.ini can be edited at \Local Sites\nameofsite\conf\php\php.ini.hbs.

Why .hbs? This seems to be the extension for Handlebars Templates and while I normally think of Handlebars being for templating code it apparently can also be used in config files, thus allowing for dynamic values in Local’s config files.

Turning Off PHP Debugging for Local

~/Local Sites/nameofsite/conf/php/php.ini.hbs

Change display_errors = On to display_errors = Off.

Configuring Local to Work with Composer

  • Composer won’t detect Local’s PHP by default, need to navigate to it manually. Path should be something like: C:\Program Files (x86)\Local\resources\extraResources\lightning-services\php-7.3.5+6\bin\win64\php.exe.
    • Don’t allow Composer to setup php.ini file.
  • I’ve been unable to get Composer running with Local with either the Windows Composer installer (see towards bottom of page) or the manual method. The problem appears to be that the local provided PHP binary was compiled without SSL support.
    • Unfortunately, it isn’t as easy as passing an o

What Local Is

  • Local, under the hood, appears to be a fairly straightforward XAMP setup (where X is Windows, Linux, or MacOS). Don’t get me wrong, the UI layer is beautiful and overall its wonderful to worth with.
  • The UI is an Electron app (similar to Slack).
  • It uses the Handlebars Templating language in config files (as mentioned above).
  • It utilizes Google’s SwiftShader, a “high-performance CPU-based implementation of the Vulkan, OpenGL ES, and Direct3D 9 graphics APIs.”
  • In addition to the fundamental packages of nginx (web server), PHP (language server), and MySQL/MariaDB (database servers) it bundles the following with the install:
    • 7-Zip – For managing compressed files
    • Adminer – A database management interface (not sure why phpmyadmin isn’t included instead, I find the latter more intuitive/powerful)
    • WP-CLI – for command-line WP management
    • WP Engine DevKit – not exactly sure how this factors in yet, its tooling from WP Engine for working with WP
    • Mailhog – catches all mail sent by WP and allows you to review it
    • ngrok – allows for sharing of one’s local dev server quickly and easily
      • This worked very well for me!
    • Cygwin – allows one to run some generally Linux native applications
      • rsync – copying/syncing/moving files
      • ssh – SSH duh 🙂

Why I’ve Decided to Stay with VVV…for now…

I’ve used a wide variety of local dev environment solutions. From WAMP to Docker to Vagrant they have all had their benefits and limitations. I don’t expect to find the perfect solution.

The one I’ve been using for perhaps a year now is VVV, which uses Vagrant under the hood. There are challenges with using it but I’m fairly comfortable with it and at the moment the limitations of Local are too significant for me to make the switch.

FWIW, I’ve outlined the salient issues below:

  1. Closed Source – Local, unlike most other local dev solutions, is closed source. I’m not against using commercial software but being oss is generally a boon, imho.
  2. Premium – Most other local dev solutions are also free. Local’s basic version comes for free but they have a premium version that costs $20/mo. This makes more uncomfortable than a solution that is premium only. freemium’s have a tendency to move basic functionality from the free edition to the premium edition when they don’t see the desired uptake of their premium edition. I’m not saying that will happen with Local, only that it makes me nervous.
  3. Speed – While theoretically Local should be faster than virtual options I haven’t found this to be significantly true. VVV is no speed demon in my experience, but neither is Local. Whatever small amount of performance I might gain isn’t worth the cost in migrating to Local.
  4. Native – In general I prefer my tools to be as portable and self-contained as possible. This means I favor solutions that use virtualization technologies under the hood…Local used to but has now adopted a native approach. Since 3 doesn’t seem to be a huge win (at least for me), 4 becomes a bigger problem.
  5. Compatibility – This is actually the nail in the coffin for me. All of the others I could probably live with but the inability to use certain core development tools with Local (on Windows) just doesn’t work. Specifically, I have been unable to discover how to get Composer working with Local.