Expressionengine 2 and git (version control)

Didn’t quite get all the example files on gist just yet, but here’s the shell script. It has two user configs, which are explained in the file. Everything else is auto-detected. Feel free to help me improve it if you have suggestions!

deploy_ee2.sh

Again, my production server for this project is in a suPHP environment, so there are some things here regarding permissions that will be irrelevant for most EE installations. Modify them to your liking.

(Speaking of… does anyone know of a way to run a TRUE/FALSE test in a shell script and in PHP for whether or not we’re running in a suPHP environment?)

Here are the relevant changes needed in the config.php, constants.php, and database.php files in order to get a dynamic EE installation going.

These are all really useful suggestions.

We’re also working out a similar workflow. But I’ve got an issue with the highly desirable method of moving the system folder above the webroot. What happens when you have to update EE to a new build or version?

I’ve read that the installer can’t cope with this scenario; and that you’re obliged to move the system folder back down, switch your paths accordingly, carry out your installation and then move it back up again. Seems a little convoluted.

How do any of you deal with updating EE when the system is above the root?

Updating the system above webroot is not a problem anymore. I actually just upgraded a sandbox from 2.1.3 to 2.1.4b and didn’t have to do anything special. The exception was that when the Documentation says to access your /system/ directory, you just access your masked version instead (/admin.php for example)

Ah. Thanks Eric, that sounds v. reassuring.

On-topic: I have used this .git scheme with EE for a while now, and it has worked well for me.

Off-topic: Seb and Erik, what are the advantages of moving system files above the webroot? I assume it’s to protect from attacks, but what kind of attacks, specifically? What is at risk, the credentials in the database.php?

Off-topic: Seb and Erik, what are the advantages of moving system files above the webroot? I assume it’s to protect from attacks, but what kind of attacks, specifically? What is at risk, the credentials in the database.php?

Indeed. The primary purpose is the direct access of files like database.php and config.php which contain sensitive information. Thankfully EE ships with a conditional check so the files can’t be executed directly anyways. But an extra layer of security is not a bad thing in this case. That’s the main reason I move the system directory above webroot.

I’ve spent the last two weeks trying to figure out a workflow using EE & Git and this thread has been super helpful so thank you guys.

I’ve been following the setup described by “PM Center for Inquiry” on this thread and everything seems to make sense all except for how to handle the DB. If everyone is working locally and we’ve got staging and production users on the remote server how does all the DB info get resolved? Do you install plugins locally per developer and track that in git and then push to the remote server? Won’t that overwrite actual content? Do you install plugins and initiate flat template files on the server then pull them down? I’m still a little lost when it comes to the DB workflow.

Any help is GREATLY appreciated.

Thx

We manually export the production DB and import it locally. Everytime. It’s kind of sucky but most other solutions have more drawbacks than advantages.

Just to be clear though, the DB contains the site’s content, the system’s settings and any other plugin (add-on) settings and content. A lot of the system’s base settings that are normally held in the DB can be overridden in the config file. If you pm me I’d be happy to share with you our ‘evolved’ config file.

However there are many addon-ons that create their own DB tables (low variables, supersearch, tag, freeform etc) with their relative content and settings. If these have already been used, compiled or configured (ie you’re developing on a pre-existing site) then importing and exporting the DB is the simplest solution.

Having said that, you may want to consider Navicat or explore some of the other more involved solutions discussed over on stackexchange.