You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What it allows beyond the current option 4 site pull down:
pulls down / imports a multi-site by targeting a remote alias group, all sites, not just 1
hook based architecture to allow personalized, customized overrides based on the deployment (basically spider bash if name matches, useful to abstract webaccess disable from the rest for example)
2 different types of routine options: Mirror vs Development (difference discussed below)
forcible rewriting of base_url to match deployment
Mirror mode vs Development mode
Mirror mode would be you are trying to setup / work on a staging server. You'd run this from stage to connect to production and pull it down. This would give you a mirror copy of the system with everything automatically enabled / disabled to make it happy on stage vs prod. Using a similar technique you could technically push EVERYTHING the other direction but usually people add content on Live so that wouldn't work. This also would allow all your settings.php's to work without serious rewrites as it requests matching usernames / passwords on the environment to match prod (would need an option to not do this obviously)
Development mode would Mirror, then sql sanitize, use localdb credentials and forcibly overwrite the credentials listed in the local copy of settings.php. This gives you a clean room with a command by leaching down, then getting rid of all the stuff that's got security implications. Great for vagrant and pure dev servers that don't need any of this stuff mirrored.
The text was updated successfully, but these errors were encountered:
https://github.com/btopro/elmsln-vagrant/blob/master/scripts/pull-down.sh is almost ready for prime time (when it is it'll be moved to the main elmsln repo).
What it allows beyond the current option 4 site pull down:
Mirror mode vs Development mode
Mirror mode would be you are trying to setup / work on a staging server. You'd run this from stage to connect to production and pull it down. This would give you a mirror copy of the system with everything automatically enabled / disabled to make it happy on stage vs prod. Using a similar technique you could technically push EVERYTHING the other direction but usually people add content on Live so that wouldn't work. This also would allow all your settings.php's to work without serious rewrites as it requests matching usernames / passwords on the environment to match prod (would need an option to not do this obviously)
Development mode would Mirror, then sql sanitize, use localdb credentials and forcibly overwrite the credentials listed in the local copy of settings.php. This gives you a clean room with a command by leaching down, then getting rid of all the stuff that's got security implications. Great for vagrant and pure dev servers that don't need any of this stuff mirrored.
The text was updated successfully, but these errors were encountered: