Hi. Any suggestions about changing DB_PREFIX during the remote provisioning, would love to see database tables begin with {db_prefix}?
Tried to change production/wordpress_sites.yml and wordpress-setup/tasks/database.yml with no luck
Specifically what did you try? (Post code)
I haven’t tried it, but setting a DB_PREFIX env var before provisioning your site should work
1 Like
I’m confused about the use case for doing this honestly. Wouldn’t you just want to change your table prefix during development to whatever it was going to be, then this becomes a non issue.
As you know its a kind of security issue, there were a lot of articles about it, one more extra way to protect your wordpress blog and database against hackers.
So sorry for my english, but Bedrock has config/application.php with $table_prefix = env(‘DB_PREFIX’) ?: ‘wp_’; as i do understand DB_PREFIX may come from .env file that generated during the provisioning , but how to add this DB_PREFIX to .env during the generation. I thought about adding a line to production/wordpress_sites.yml, for example, db_prefix: dbprefix that will go to wordpress-install/tasks/main.yml -> section ‘Create .env file’ and than to wordpress-setup/tasks/database.yml to create database with prefix for all the tables inside wordpress database. I’m not to vagrant at all to process all these steps. What do your think?
1 Like
oh, missed it. thanks!
If I want to rerun the server.yml playbook tag that generates the .env file, what tag would I run?
just add a parameter to the env block in group_vars/<environment>/vault.yml:
db_prefix: "wpextended_"
In there with db_password, auth_key, etc.
That’s the source for the environment variables trellis inserts into the Bedrock installation, if I understand correctly.
1 Like
What I meant is that I don’t want to rerun all of the tasks in the playbook. So I was wondering which specific task controls the .env creation.
Also, it seems from my tests that once a .env is created, you can no longer change it through the playbook. Does anyone else experience this?
.env creation would be app specific so it would be a task in the deploy.yml playbook not server.yml. And as far as I know with deploys, you shouldn’t/can’t run specific tags (unless you want to check the connection). Each deploy is it’s own release, unlike the server which is being modified when it’s provisioned.
1 Like
As @knowler says it’s just the deployment plays which would be run again, so it should be something you can do fairly often without much hair-pulling. ./bin/deploy.sh staging example.com from within Trellis (which you probably already know.)
Do you have to commit the change to the repo in order for it to get deployed through the deploy playbook?
I’m thinking of a scenario where you want to add a temporary change to the .env and don’t want to commit it to the develop branch.
I’d still do it in a branch, even if it’s not the develop branch. I’m always nervous of changing something without documenting it at least somewhere.
2 Likes
The change would take place within your trellis directory not the site directory,1 so technically no. While you do have to version control the site’s folder for Trellis to deploy it, Trellis doesn’t do the same with itself. You could make a temporary change to the group_vars, deploy, then revert them. But like @MWDelaney said, it’s a good idea to document changes.
1 This assumes you are following a standard Roots project structure.
2 Likes