Did you encrypt your vault file by any chance? Because in that case it won’t be able to load the file:
vault_sites = YAML.load_file(vault_file)['vault_wordpress_sites']
and execute the merge, resulting in that error.
Haven’t found a solution for this yet, that’s why I don’t encrypt my development vault files for now.
No, I am not encrypting. I just copied and pasted your code into the main Vagrantfile. Is that the correct method?
Yes basically, it should work?
Did you try outputting the vars:
puts site['env']
and
puts vault_sites[name]['env']
and see what the output is?
Is your site up and running besides this?
Thanks for the comment. It lead me to what I think is the problem.
I do not have an env set in my wordpress_sites.yml file. I was counting on the default settings in the all/main.yml file.
The error is gone. Now to get the triggers working.
I have the same problem you mentioned in your previous post. Can you show me an example of your dev wordpress_sites and vault setup? Sorry a newbie so I might have configured it wrong. The triggers are added to the vagrant file at the end correct?
If it’s licensed as an open source and working into an open source ecosystem I’m not sure the term “rip off” makes sense ?
How about “unethical”? Do the right thing — if you find it useful, pay for the license through Delicious Brains.
Delicious Brains choosed their bussiness model GPL based. It was their own choice. Has no sense to get upset if somebody fork it. Has no sense to wield “unethical” flag against GPL freedom terms. That is really “unethical”.
I’m sorry, but just because they’re using the GPL license doesn’t mean it’s suddenly fine to be using rip-offs of someone’s software.
How do you think we would react to people taking our paid plugins and then re-distributing them for free?
Do you think it’s okay to sign up for one of the many ‘GPL Clubs’ around, that give you access to a wide variety of WordPress plugins by paying a small fee? That fee doesn’t go to any of the people that wrote those plugins.
To use, modify or redistribute GPL software is not a rip-off. Rip-off implies something ilegal. If you are impeding the freedoms guaranteed by the license, that is a rip-off.
You were less wrong using “unethical” term since ethic is a grayscale zone and can be discussed.
You should keep in mind that you can write plugins for a lot of people just because the GPL ecosystem built a very big community of users. All this people adopt this ecosystem because they can feel it as their collective property. If you do not respect the terms of the GPL you are damaging that ecosystem. Wordpress is clear about it: “If you disagree, you might want to consider a non-GPL platform such as Serendipity (BSD license) or Habari (Apache license) instead.”
So, although I am not a friend of opportunism and I don’t like those GPL clubs, the dilemma is between two choices: To preserve the ecosystem or to preserve your personal profits. I understand that personal profits of software development are very important to software developers, but it can’t be defended with ethical arguments against GPL terms.
A metaphor: think in a lumberjack in the forest. He can persevere their profits against forest environment. If you, as a developer, make GPL software, you are seeding more trees in that forest. Otherwise, you are the lumberjack.
So, how can I survive as a developer in a GPL environment? This is a complex discussion and I’m afraid it exceed the topic of this forum. Anyway, it includes concepts like “real time economy”, “attention economy” and “economy of services”. I will be happy to discuss this further if you deem it appropriate.
Just to say that, in wp-sync-db case, I prefer clearly to buy a complete functional WP Migrate DB Pro plugin, and avoid to hack trellis to adapt it to wp-sync-db needs, but my personal situation is very hard, actually, without resources to cover my basic needs. So, to find free resources is mandatory until I get afloat.
So, unlist my previous thread was a bad decision:
https://discourse.roots.io/t/can-i-downgrade-composer/9703
Because this decision was completely based on a arguable opinion and, in strictly sense, it can be considered censorship. This kind of decision hurts me since internally I’m involved with the roots community (despite my low level as a front-end developer). I learned a lot and I got huge satisfaction here.
Hi! How can I apply this to my project? Do I have to overwrite the vagrantfile, the group_vars folder and create database in the root only or do I need to do something else?
Thanks
I made a fresh Trellis fork for this: https://github.com/Twansparant/trellis-db-sync
Basically, all you need to do is add a database/current folder in your project root and modify these lines:
Hi! I’m getting an error regarding the vagrant file.
Path: /Users/.../trellis/Vagrantfile
Line number: 174
Message: undefined method `merge!'And I’m getting:
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
an invalid or undefined variable.
Path: /.../trellis/Vagrantfile
Line number: 174
Message: undefined method `vault_sites'
Commented out that line for the moment but not sure how this can get solved. Just merged the latest trellis commits before.
Thank you very much in advance. 
My fork is probably out-of-date… Sorry about that! When I find some time, I’ll try and fix this error!
FYI. We have created trellis-simple-sync, a very simple library to synchronize database and the uploads folder between development and other environments. It don’t need any configuration.
With just one command, e.g.:
./bin/sync.sh staging example.com db push
./bin/sync.sh production example.com uploads pullAs of version 2.1.0, Vagrant no longer needs the vagrant-triggers plugin - to get the trellis-db-sync working after updating - remove the plugin from vagrant.default.yml and replace the trigger in the Vagrantfile to:
# Vagrant Triggers
trellis_config.wordpress_sites.each do |(name, site)|
#
# Get database credentials
#
site['env'].merge!(trellis_config.vault_sites[name]['env'])
db_name = site['env']['db_name']
db_user = site['env']['db_user']
db_pass = site['env']['db_password']
#
# Importing database
#
config.trigger.after [:up, :resume] do |trigger|
database_file = "../database/current/#{db_name}.sql"
if File.exists?(database_file)
trigger.info = "Importing database #{db_name}"
trigger.run_remote = {inline: "mysql -u #{db_user} -p#{db_pass} #{db_name} < /srv/database/current/#{db_name}.sql"}
else
fail_with_message "#{database_file} was not found."
end
end
#
# Exporting database
#
config.trigger.before [:halt, :suspend] do |trigger|
trigger.info = "Dumping database #{db_name}"
trigger.run_remote = {inline: "mysqldump -u #{db_user} -p#{db_pass} #{db_name} > /srv/database/current/#{db_name}.sql"}
end
end
The rest of the setup remains as before.
I had to remove the ~/.vagrant.d directory to delete vagrant-triggers plugin completely - you may want to backup before removing this directory but the user data is automatically regenerated on running vagrant.
The trigger seems to run a little slower than before but at least it works again.