Compare to VVV

[ottok]

Compare our Seravo Vagrant box to the develop branch of the official WordPress Vagrant box: https://github.com/Varying-Vagrant-Vagrants/VVV

If there are any developer tools, speed optimizations etc cool things, consider copying them over to our image. Note however to keep the PHP/Nginx part in parity with our production environment, there should be no surprises when developers push their sites to production.

[ottok]

Other commonly used Vagrant boxes are Flywheel Local and Scotchbox https://scotch.io/bar-talk/announcing-scotch-box-30-and-scotch-box-pro

[ottok]

And a Docker based one: https://github.com/10up/wp-local-docker-v2

[ottok]

And now also from WP Engine: https://wpengine.com/devkit/

[l3ku]

VVV seems somewhat similar to ours at least when compared to Flywheel and WP Engine. Have not tested the dev environment from 10up. Some differences based on brief testing:

• VVV has no support out-of-the-box for self signed HTTPS certificates (however, planning to do so https://varyingvagrantvagrants.org/docs/en-US/references/https/)
• VVV has sort of a "dashboard" starting page that includes some information regarding how to get started. Should we add some kind starting page, too (like we do with our production sites)?

• VVV has some additional tools that we don't have:

• VVV has support for more extensive config.yml options. Maybe we should look into some of those options more deeply?

---


# This file is a YAML formatted file. YAML indenting is done in spaces not
# tabs, and whitespace is significant. If you don't stick to this, it will
# fail on provision

#
# IMPORTANT, if you change this file, you have to reprovision,  no exceptions
# Do this by running either this command:
# vagrant reload --provision
#
# Or, if your machine is already turned on:
# vagrant provision
#

# These are your websites, and their names map on to the folders they're
# located in. See the docs for how to define these, and what all the keys
# and options are
sites:

  # latest version of WordPress, can be used for client work and testing
  wordpress-one:
    skip_provisioning: false
    description: "A standard WP install, useful for building plugins, testing things, etc"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    hosts:
      - one.wordpress.test

  wordpress-two:
    skip_provisioning: false
    description: "A standard WP install, useful for building plugins, testing things, etc"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    hosts:
      - two.wordpress.test

  #mysite:
  #  description: "My website"
  #  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  #  hosts:
  #    - mysite.com

  # The wordpress-develop configuration is useful for contributing to WordPress Core.
  # It uses the built WP to serve the site
  wordpress-trunk:
    skip_provisioning: true # provisioning this one takes longer, so it's disabled by default
    description: "An svn based WP Core trunk dev setup, useful for contributor days, Trac tickets, patches"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template-develop.git
    hosts:
      - trunk.wordpress.test

  # The following commented out site configuration will create a standard WordPress
  # site in www/example-site/ available at http://my-example-site.test.
  # Remember, whitespace is significant! Tabs and spaces mean different things
  #example-site:
  #  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  #  hosts:
  #    - my-example-site.test

  # The following commented out site configuration will create a environment useful
  # for contributions to the WordPress meta team, .e.g WordCamps, .org, etc:
  wordpress-meta-environment:
    skip_provisioning: true # disabled by default, this takes a long time to provision
    repo: https://github.com/WordPress/meta-environment.git


# Utilities are system level items rather than sites, that install tools or packages
# the core utilities install tools such as phpmyadmin
utilities:
  core: # The core VVV utility
    - memcached-admin # Object cache management
    - opcache-status # opcache management
    - phpmyadmin # Web based database client
    - webgrind # PHP Debugging
    - tls-ca # SSL/TLS certificates
    - mongodb # needed for Tideways/XHGui
    - tideways # PHP profiling tool, also installs xhgui
    #- php56
    #- php70
    #- php71
    #- php72
    #- php73

# vm_config controls how Vagrant provisions the virtual machine, and can be used to
# increase the memory given to VVV and the number of CPU cores.
# It can also be used to override the default provider being used within Vagrant.

vm_config:
  # For WP core development we recommend at least 2GB ( 2048 ),
  # If you have 4GB of RAM, lower this to 768MB or you may encounter issues
  memory: 2048
  # CPU cores:
  cores: 2

  # this tells VVV to use the prebuilt box copied from the USB drive at contributor days
  # once set to false, do not change back to true, and reprovision
  # wordcamp_contributor_day_box: false

  # Due to a limitation within Vagrant, the specified provider is only respected on a clean `vagrant up`
  # as Vagrant currently restricts you to one provider per machine
  # https://www.vagrantup.com/docs/providers/basic_usage.html#vagrant-up
  # provider: vmware_workstation

# General VVV options
general:
  # Backup the databases to the database/backups subfolder on halt/suspend/destroy, set to false to disable
  db_backup: true
  # Import the databases if they're missing from backups
  db_restore: true

[l3ku]

Maybe we should direct some effort to support multisite configuration into config.yml with the aid of Seravo/wordpress#81? I don't think that we can directly compare VVV with our Vagrant environment, because ours is only intended for serving a single site, whereas VVV seems to have support for subdomain installations for multiple sites (wordpress-one, wordpress-two etc).

Does @ottok have anything to comment about the results above, or can this issue be closed? I also have created a shared Google docs document comparing also to other local environments, but not linking it here due to this being a public repo.

[ottok]

Other alternatives to compare to:

Docksal
Command line based, wp-cli support
docksal.io

Vagrant
Command line based. Has a WP focused conf.
vagrantup.com

Local by Flywheel
GUI, SSL
localwp.com

DesktopServer
GUI, SSL
serverpress.com

[ottok]

These are based on directly on docker-compose, but on a custom cli tool that creates the different files and environments, including docker-compose files: https://10up.github.io/wp-local-docker-docs/, https://lando.dev/