ideasonpurpose / basic-wordpress-vagrant Goto Github PK

I do this every time, might as well automate it.

http://raveren.github.io/kint/

Require Kint in local wp-config.php and auto-download the library into the top level.

Just in case someone's using Roots. Or migrating from roots.

Add this to the generated wp-config.php:

define('WP_ENV', 'development');

After vagrant up and vagrant provision I still get this:

## vagrant-hostmanager-start id: 1234

value	basicwp.dev

## vagrant-hostmanager-end

Assume value should be an IP address right?

I already have vvv and a couple of other boxes running that can add to my hosts file so certain this isn't an issue with writing to the file.

Other info - I dumped a WPEngine backup into sites as detailed in the setup guide 👍

Please help!

Currently I have a basic.dev box setup and an @basic alias in my ~/.wp-cli/config.yml to point to http://basic.dev/.

@basic:
    ssh: [email protected]/var/www/wordpress/ 

Outside of Vagrant I can run wp @basic theme list but I'm prompted for a password.

Do you have a work-around for password prompting when using an @alias outside of the vagrant box?

Should be pretty simple, ref #36

The vars/wordpress.yml file is actually a leftover of doing this already, maybe change that file to "settings" and default to the full download url for WP Latest with a note about installing other releases.

Three warnings:

==> default: Running provisioner: ansible...
    default: Running ansible-playbook...
[DEPRECATION WARNING]: Instead of sudo/sudo_user, use become/become_user and 
make sure become_method is 'sudo' (default). This feature will be removed in a 
future release. Deprecation warnings can be disabled by setting 
deprecation_warnings=False in ansible.cfg.

TASK [wordpress : include] *****************************************************
[DEPRECATION WARNING]: You should not specify tags in the include parameters. 
All tags should be specified using the task-level option. This feature will be 
removed in a future release. Deprecation warnings can be disabled by setting 
deprecation_warnings=False in ansible.cfg.
included: /Users/joe/Desktop/njhi.dev/ansible/roles/wordpress/tasks/install.yml for default

TASK [wordpress : Attempt to install missing plugins from WordPress.org] *******
[DEPRECATION WARNING]: Using bare variables is deprecated. Update your 
playbooks so that the environment value uses the full variable syntax 
('{{missing_plugins}}'). This feature will be removed in a future release. 
Deprecation warnings can be disabled by setting deprecation_warnings=False in 
ansible.cfg.

Errors should never pass silently.

Hey Joe,

I setup this bash script to quickly name a project, pull a version of basic-wordpress-vagrant, pull the latest WP, generate the folders, and then vagrant up - https://codepad.co/snippet/x9TwyHwH

./new_vagrant.sh $NAME

Is this something that would be better done in Ansible? It works, but I'm curious if there is a better way. More so because it would be nice to automate some WP-CLI tasks after the build and I don't know how to do that without going through vagrant ssh.

See KSid/windows-vagrant-ansible and trellis/windows.sh (also the Trellis Vagrantfile). Ansible will run on the VM.

Setting a custom value for wp_dir is not working right. ref: #36

this can roll in with the install_plugins option, something like this:

install_dev_plugins:
#    - debug-bar  # https://wordpress.org/plugins/debug-bar/
#    - query-monitor   # https://wordpress.org/plugins/query-monitor/

What it would take to modify the php version included here.

I wrote a bash script to modify this project and create clones with multiple versions of WordPress. A common folder was then copied to all versions to test how a plugin worked across the various WP installs. I'm curious if I could do the same with the PHP - 5.3, 5.4 & 5.5.

PWD (script directory)
├── common_folder
├── wp39-php55.dev
│   └── site/common_folder
├── wp42-php55.dev
│   └── site/common_folder
└── wp431-php55.dev
      └── site/common_folder

I realize the task to change the WP version was pretty straight forward. But maybe it is this easy?

# Path to Ansible task
yml=$(cat $base/$dirname/ansible/roles/wordpress/tasks/install.yml)

### REPLACE THE ANSIBLE WP VERSION w/OUR VERSION
wp_url_latest="https:\/\/wordpress.org\/latest.tar.gz"
wp_url_version="https://wordpress.org/wordpress-$VERSION.tar.gz"

echo "${yml/$wp_url_latest/$wp_url_version}" > $base/$dirname/ansible/roles/wordpress/tasks/install.yml

I find myself wanting to migrate to using this box more often that not but I need to ensure the DB and Host settings are closer to my existing environment.

It would be nice to add some things to the config.yml or allow some flexibility with these settings. Adding these as overrides in the config can keep the project lean and mean.

Some of these work, some fail.

Based on ## 0.1.0

• $table_prefix - /site/wp-config.php

I can directly modify the template file but using the config will keep the changes in one place.

table_prefix: 'wpbwv_'

• web_dir - /site/ to /wordpress/

403 Forbidden when modified, but WordPress does install to the directory supplied.

web_dir: 'wordpress'

• wp_config - Access denied for user 'a_user'@'localhost'

Changing db_name seems to work OK but the other settings seem to fail. Possibly set here.

wp_config:
  db_name: fruit_loop_tables
  db_user: a_user
  db_password: a_password

• $hostname

While it's handy creating a .dev, trying to sync with an existing site is rough. An override for the $hostname would be ideal. This does work well when setting the override after your fake-TLD.

hostname: 'dev.example.com'

• Post Install Scripts
  This is probably an Ansible thing, but it could be really handy for me to use WP-CLI to switch the site to multisite, install required plugins, and import a more complex database.

scripts:
  post_install: ./scripts/do_stuff_with_wp-cli.sh

Example: Update WP-CLI, install WordPress, convert to multisite, and add a site.

# do_stuff_with_wp-cli.sh
vagrant ssh -- -t 'cd /var/www/wordpress/ && sudo wp cli update --allow-root --yes; wp core install --title="Basic Site" --admin_user=admin --admin_password=password [email protected] --url=http://dev.example.com; wp core multisite-convert; wp site create --slug=basic-example;'

Two use cases which should work out of the box:

• WP Engine's restore point dumpfiles are named mysql.sql and arrive in wp-content
• WP Migrate DB dump files have names like website_wp-migrate-20150903035557.sql
• BackUpWordPress dumpfiles have names like database-example-com-1431114127.sql

All of those should work out of the box. There's got to be a way of using Ansible's with_fileglob to check the three primary directories: /*.sql, /site/*.sql, /site/wp-content/*.sql. I had something like this early on, but simplified to get everything working.

I had a coworker recently try this project and on initial vagrant up there seems to be a failure when doing the Pull-sync.

TASK: [wordpress | Pull-sync fresh WordPress onto local site directory] ******* 
failed: [default -> 127.0.0.1] => {"failed": true}
msg: unsupported parameter for module: use_ssh_args

FATAL: all hosts have already failed -- aborting

PLAY RECAP ******************************************************************** 
           to retry, use: --limit @/Users/myusername/main.retry

default                    : ok=9    changed=6    unreachable=0    failed=1   

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

Anything stand out as the culprit?

Host OS: Ubuntu 14.04
Guest OS: 'Ubuntu_64'
VirtualBox: 5.0.16 r105871
Vagrant: 1.7.4

Attempting to start up VirtualBox & vagrant this morning via vagrant up, I got the following error message:

Command: ["hostonlyif", "create"]

Stderr: 0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to create the host-only adapter
VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterfaceWrap, interface IHostNetworkInterface
VBoxManage: error: Context: "RTEXITCODE handleCreate(HandlerArg*)" at line 71 of file VBoxManageHostonly.cpp

I then did the following:

sudo /Library/StartupItems/VirtualBox/VirtualBox restart

yielding this error message:

"sudo: /Library/StartupItems/VirtualBox/VirtualBox: command not found"

Attached is the relevant vbox.log:

140704_vboxlog.txt

Not sure if you need my vagrantfile, but here are the contents of that:

Vagrantfile.txt

Trying to restart VirtualBox failed:

sudo /etc/init.d/vboxdrv restart
yields this message:

Stopping VirtualBox kernel modules ...done.
Starting VirtualBox kernel modules ...failed!
(modprobe vboxnetflt failed. Please use 'dmesg' to find out why)

I was then informed that the issue is entirely a VirtualBox issue.

I ran this command:

$ dmesg | grep VirtualBox
getting this result:

[ 5067.037574] warning: `VirtualBox' uses 32-bit capabilities (legacy
support in use)

Then I ran

sudo modprobe -v vboxdrv
which did absolutely nothing after I entered the password at the prompt:

$ sudo modprobe -v vboxdrv
[sudo] password for selfspunwebs:

Trying this:

$ sudo apt-get install linux-headers-generic build-essential
got me this:

Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version.
linux-headers-generic is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Then I tried this:

sudo depmod -a
and then modprobe again:

sudo modprobe -v vboxdrv
which again yielded nothing.

The moderator of the virtualbox.org forum on VirtualBox for Linux suggests that I install a Linux guest like mint in VirtualBox for testing purposes. Before I do that, I was wondering if you have any feedback for me on the above.

Please advise.

Thanks.

No point in running the scrape options from 'wp option get active_plugins' task if 'Load dumpfile into the database' was skipped.

This would eliminate some ignored red text too.

Not sure if you've seen http://vccw.cc but they have an interesting wp-cli scaffold package: https://github.com/vccw-team/scaffold-vccw

Since this project is pretty basic it might be fairly straight forward to create one for this project.

[ deleted ] -- wrong repo

These errors are from the v0.0.10 release while v0.0.9 is working fine. Both are fresh copies with fresh versions of the latest WordPress.

I'm really not sure what happened. Things have been pretty smooth for a while but just recently I can't vagrant up. I'm not sure if it was something added/modified when I ran through installing VVV via an online tutorial.

I figured I would ask here since you're pretty good at spotting this stuff from a mile away. Any suggestions on why it's failing?

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ideasonpurpose/basic-wp'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ideasonpurpose/basic-wp' is up to date...
==> default: Setting the name of the VM: sandboxdev_default_1456727636251_51431
==> default: Clearing any previously set forwarded ports...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostly
==> default: Forwarding ports...
    default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: 
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default: 
    default: Guest Additions Version: 4.3.34
    default: VirtualBox Version: 5.0
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
    default: /vagrant => /Users/username/sites-VAGRANT/sandbox.dev
==> default: Running provisioner: ansible...
    default: Running ansible-playbook...

PLAY [all] ******************************************************************** 

GATHERING FACTS *************************************************************** 
ok: [default]

TASK: [wordpress | Make sure /site directory exists] ************************** 
ok: [default]

TASK: [wordpress | command mktemp -d /tmp/wordpress-XXXX] ********************* 
changed: [default]

TASK: [wordpress | Download and extract WordPress] **************************** 
failed: [default] => {"failed": true}
msg: unsupported parameter for module: list_files

FATAL: all hosts have already failed -- aborting

PLAY RECAP ******************************************************************** 
           to retry, use: --limit @/Users/username/main.retry

default                    : ok=3    changed=1    unreachable=0    failed=1   

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

I may be still using an old version of this repo, but it would be nice to include the path in ~/.wp-cli/config.yml so you can type wp from anywhere after vagrant ssh.

~/.wp-cli/config.yml

path: /var/www/wordpress/

Whenever version-everything is done, use it to version the Readme, Vagrantfile and playbooks.

Since it wasn't working before, it's a little jarring to have the giant orange tables just show up all of a sudden. Add a boolean to config.yml

Symlink from known location instead of downloading fresh on each vagrant up

https://github.com/ideasonpurpose/basic-wordpress-vagrant/blob/master/ansible/roles/wordpress/tasks/database.yml#L11

ERROR: Syntax Error while loading YAML script, /private/tmp/wpe-ignore/ansible/roles/wordpress/tasks/database.yml
Note: The error may actually appear before this position: line 11, column 85

- name: Found dumpfile
  debug: "msg='Populating database from {{ dumpfiles.stdout_lines | last | relpath(\'/vagrant\')}}'"
                                                                                    ^
We could be wrong, but this one looks like it might be an issue with
missing quotes.  Always quote template expression brackets when they
start a value. For instance:

    with_items:
      - {{ foo }}

Should be written as:

    with_items:
      - "{{ foo }}"

For Windows and possible Ansible-less Mac/Linux boxes, try Vagrant's ansible_local provisioner instead of the shell fallback.

Also test speed vs running Ansible from the controller vs locally on the Vagrant box.

Ansible has been installed on our base box since ideasonpurpose/basic-wordpress-box@b6330d1 but I should probably check the version...

https://mediatemple.net/webhosting/wordpress/

Not sure what changed, just started seeing this.

Not Ansible: Same issue with Ansible 2.3.0 (dev) and ansible 2.1.2.0 (homebrew).

Not Vagrant version: Tested with 1.8.7 and 1.8.6.

I've been having trouble getting ssh-agent to remember keys across restarts, might be related.

These are slightly cleaned up for readability

TASK [wordpress : Pull-sync fresh WordPress onto local site directory] *********
fatal: [default]: FAILED! =>  {
   "changed": false,
   "cmd": "/usr/bin/rsync
          --delay-updates
          -F
          --compress
          --archive
          --rsh 'ssh -i /Users/joe/Sites/iopwp/.vagrant/machines/default/virtualbox/private_key -S none -o StrictHostKeyChecking=no -o Port=2222'
          --out-format='<<CHANGED>>%i %n%L' \"[email protected]:/tmp/wordpress/wordpress/\" \"/Users/joe/Sites/iopwp/site/\"",
   "failed": true,
   "msg": "Received disconnect from 127.0.0.1 port 2222:2: Too many authentication failures for vagrant
           Connection to 127.0.0.1 closed by remote host.
           rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
           rsync error: error in rsync protocol data stream (code 12) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-51/rsync/io.c(453) [receiver=2.6.9]\n",
   "rc": 12
 }

and

fatal: [default]: FAILED! => {
  "changed": false,
  "cmd": "/usr/bin/rsync 
          --delay-updates 
          -F
          --compress
          --archive
          --rsh 'ssh -i /Users/joe/Desktop/basic-wordpress-vagrant/.vagrant/machines/default/virtualbox/private_key -S none -o StrictHostKeyChecking=no -o Port=2200'
          --out-format='<<CHANGED>>%i %n%L' \"[email protected]:/tmp/wordpress/wordpress/\" \"/Users/joe/Desktop/basic-wordpress-vagrant/site/\"",
  "failed": true,
  "msg": "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
          Someone could be eavesdropping on you right now (man-in-the-middle attack)!
          It is also possible that a host key has just been changed.
          The fingerprint for the RSA key sent by the remote host is\nSHA256:S6SrBPR638bAJMLhjFN08mxNaBgplai6/k9AjxRNTKs.
          Please contact your system administrator.
          Add correct host key in /Users/joe/.ssh/known_hosts to get rid of this message.
          Offending RSA key in /Users/joe/.ssh/known_hosts:187
          Password authentication is disabled to avoid man-in-the-middle attacks.
          Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
          Received disconnect from 127.0.0.1 port 2200:2: Too many authentication failures for vagrant
          Connection to 127.0.0.1 closed by remote host.
          rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
          rsync error: error in rsync protocol data stream (code 12) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-51/rsync/io.c(453) [receiver=2.6.9]\n",
  "rc": 12
}

Thanks to @Wowfunhappy for finding this

@joemaller - thanks for the talk last night. I'm excited to dive into vagrant and this solution has me up in running is seconds.

Unfortunately, as I'm attempting to pull a live site into this local dev environment I am getting a timeout. Mainly because the database is fairly massive. Is it possible to adjust the php settings?

FATAL PHP ERROR: type => 1 message => Maximum execution time of 30 seconds exceeded file => /vagrant/site/importbuddy/lib/zipbuddy/zbzipziparchive.php line => 97

A little more info about the error source. I'm using Backup Buddy and it requires two files:

• importbuddy.php - all the heavy lifting
• backupbuddyarchive.zip - site archive (can include database and/or files)

Would it be possible to support HTTPS with this setup? Or is that too far off 'basic'?

My theme for Black Buddha is designed for HTTPS but is flexible enough to work with http. It would be great to have the option.

What needs to happen so we can have several sites staged simultaneously on the same controller/host machine without IP collisions?

I ran into issues using vagrant up on a mac with the latest ansible and vagrant versions.

On running vagrant up on a clean install of release version v0.0.11 I got the following:

TASK [wordpress : scrape options from `wp option get active_plugins`] **********
fatal: [default]: FAILED! => {"changed": true, "cmd": "wp option get active_plugins --format=json", "delta": "0:00:00.389455", "end": "2017-01-11 19:05:58.031778", "failed": true, "rc": 1, "start": "2017-01-11 19:05:57.642323", "stderr": "Debug (bootstrap): Using default global config: /home/vagrant/.wp-cli/config.yml (0.011s)\nDebug (bootstrap): No project config found (0.012s)\nDebug (bootstr]ap): No package autoload found to load. (0.143s)\nDebug (bootstrap): ABSPATH defined: /vagrant/site/ (0.144s)\nDebug (bootstrap): Begin WordPress load (0.146s)\nDebug (bootstrap): wp-config.php path: /vagrant/site/wp-config.php (0.147s)\nError: The site you have requested is not installed.\nRun `wp core install`.", "stdout": "", "stdout_lines": [], "warnings": []}
...ignoring

On going to the IP address the vagrant environment was assigned I got the following:

WordPress database error: [Table 'wordpress.wp_options' doesn't exist]
INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('nonce_key', ')S6tc0P`(9l>xcU[d tIJ{ q,0x$7yz@pI{{)DyWeDw;8lGQ^8:J0_,~e@/^c~0t', 'no') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`)

WordPress database error: [Table 'wordpress.wp_options' doesn't exist]
INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('nonce_salt', 'K}!mD)I_,jxf[4AfI,4|6x5cU)lZKB.EAS5|n|<|L;Qg(!:M[<*0[&}SbbL`4L%4', 'no') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`)

Seems to be more widely used and might solve the multiple simultaneous instance issue from #6

https://github.com/smdahlen/vagrant-hostmanager

Based on the new WP-CLI release today and the fact that this project downloads the latest WordPress -- it might be a good time to update; http://wp-cli.org/blog/version-0.25.0.html

Importantly, due to the nature of these changes, WP-CLI versions prior to 0.25.0 will be incompatible with WordPress 4.7.

This may just require a rebuild of the basic box -- https://github.com/ideasonpurpose/basic-wordpress-box/blob/master/ansible/roles/wp-cli/tasks/main.yml#L5

As noted here:

The mu-plugins directory that is contained within the snapshot includes several WP Engine scripts. These scripts may conflict with components of your local environment, or cause errors altogether. We suggest that you remove the mu-plugins directory’s content (which can be found within the wp-content directory) to avoid conflicts.

This isn't an issue. I just wanted to say you created exactly what I wanted. WPengine export, fast, and easy. Thank you!!!

Neither of these are essential, just nice to have.

Test Data
Considering this is barebones, it might be worthwhile to add a link to the WP Theme Unit Test page and/or a link directly to the Test Data XML file.

wget -O test-data.xml 'https://wpcom-themes.svn.automattic.com/demo/theme-unit-test-data.xml';

If you could figure out how to import through WP-CLI then that would be cool.

Data Migration
I would also recommend an alternate to WP Migrate DB. Consider Duplicator which is free as well. A little better rating with far more active installs. I personally use BackupBuddy but it's not free.

Anyway, just some suggestions.

My computer froze and I was forced to restart my computer. All my vagrant boxes are in VirtualBox and in a Powered Off state. Is there an easy way to turn them back on like nothing happened? Or is everything lost?

• Merge in WP-Engine's backup omissions list
• add a link back to this project

Just dump a bunch of if ( !defined('FOO') ) checks before define('FOO', true), like this:

if ( !defined('FOO') )
    define('FOO', true);
if ( !defined('BAR') )
    define('BAR', true);

The new version of WP-CLI is barfing on our wp-config.php file because it defines WP_DEBUG for us but we're not checking whether WP_DEBUG is defined before defining it ourselves.

Need to be more clear about why Vagrant is asking for a password.

hyperdb and hyperdb-1-1 should be removed

The link in the update section to config.yml appear to be broken/missing.

Also include the WordPress release archive in config.yml's comments:

https://wordpress.org/download/release-archive/

Just happened due to some problem with Advanced Custom Fields.

Anyone have thoughts on switching the base box from Apache to Nginx?

Seems to me that there's not really any reason to be concerned with which server architecture is running, so long as the PHP environment matches what's offered by the big managed hosts. I've been switching some other projects from Apache to Nginx and it's a lot lighter and easier to configure.

Also PHP7 (ideasonpurpose/basic-wordpress-box#8) seems to want to run as a FastCGI process, which makes PHP ambivalent about which server platform it's running on.

http://www.ansible.com/blog/ansible-2.0-launch

The command is wp rewrite flush --hard, more here: http://wp-cli.org/commands/rewrite/flush/

see ideasonpurpose/basic-wordpress-box#4