Add extra config to main.yml

jgraup commented 7 years ago

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 --admin_email=user@example.com --url=http://dev.example.com; wp core multisite-convert; wp site create --slug=basic-example;'

joemaller commented 7 years ago

These are fantastic suggestions, thanks for taking the time to submit this. I'll see what I can do about getting these all working.

joemaller commented 7 years ago

Before getting to specifics, I went through the config.yml file and attempted to clarify and better document each setting. Those options are tested and used, the values in ansible/defaults/main.yml are fallbacks and not intended to be changed.

Specific issues from above:

$table_prefix

Done: 4161d11198362f000

web_dir

I really haven't tested this at all. My reason for putting the value into a variable was simply to be able to programmatically assemble installation paths on the server. Changing the web_dir to something other than site would require overriding a number of settings on the base box. It might be doable, but I don't think it would be worth the complexity. If the install path is a huge problem, it's probably better to use a database migration tool to alter paths.

A similar option is wp_dir which can install WordPress to a specific subdirectory.

DB users in wp_config

This setting is comes from the base box, wp_user@localhost is the sole DB user with full access to everything. I'm open to use cases where it would make sense to add additional DB users to each instance. Remember, the goal of this project is to mimic managed hosting environments and simplify away configuration options that are unavailable on those hosts.

Hostname

This can be changed in the Vagrantfile. Just specify any hostname before the Vagrant.configure block, Ansible will inherit the hostname from the VM and the dev site will be available at that address. Here's an example:

# add a fake-TLD '.dev' extension
$hostname = $hostname.gsub(/(\.dev)*$/, '') + '.dev'

# Override the above, hostname will be dev.example.com
$hostname = 'dev.example.com'

Post-install scripts

This is probably beyond the scope of what I want to do with this project.

But if you've got a shell script, it's very simple to have Ansible call that script from a post-tasks block. Using the Ansible Script module, it'd look something like this:

  post_tasks:
    - name: Run post-install script
       script: scripts/do_stuff_with_wp-cli.sh

You could also just paste the commands into a command or shell.

joemaller commented 7 years ago

@jgraup I think most everything has been covered. Re-open or start a new issue if there's something you'd like to see carried over from here. Thanks again for this.

jgraup commented 7 years ago

Thanks @joemaller. I appreciate everything you've done so far. Been busy with other things but I hope to revisit this sooner than later.

ideasonpurpose / basic-wordpress-vagrant