Seravo / wordpress

The WordPress project layout used by many of Seravo's customers, suitable also for local development with Vagrant and git deployment
https://seravo.com
GNU General Public License v3.0
102 stars 54 forks source link

Rely on running wp-development-up instead of custom Vagrantfile code #165

Closed ottok closed 3 years ago

ottok commented 3 years ago

The code in the Vagrantfile is bloated and obsolete anyway, it should simply be running wp-development-up after the Vagrant box is up so that all imports and pulls etc run correctly inside the Vagrant box without depending on the Vagrantfile contents. This makes the project template also better compatible and unified with using Docker.

Related: #164.

ottok commented 3 years ago

Seems Vagrant does not support running commands and sending any kind of input to them, so wp-development-up would always run non-interactively. Thus we need to keep duplicate code in Vagrantfile and wp-development-up.

From https://www.rubydoc.info/github/mitchellh/vagrant/Vagrant/Plugin/V2/Communicator#execute-instance_method

This method gives you no way to write data back to the remote machine, so only execute commands that don't expect input.

ottok commented 3 years ago

I think I solved this now by simply running wp-development-up via a system call, they are interactive.

This works now:

  1. vagrant up
  2. vagrant ssh -c 'wp option set blogtitle testi'
  3. verify on https://wordpress.local that the title changed
  4. vagrant destroy
  5. vagrant up
  6. verify on https://wordpress.local that the title is still there as changed

By triggering wp-development-up the wp-vagrant-load-db gets triggered correctly and database from shutdown dump is used.