Month: May 2020

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.