I am a long time Drupal Developer, but it looks like I'm going to have to do some EE Dev work.

This question might become clear as time goes on, but wondering what experiences/best practices can be shared with the dev cycle.

In Drupal, I am accustomed to developing on a local MAMP environment; create various templates, CSS, custom modules, Features (that allow database centric functionality to be committed to code), etc. The very few database tweaks that can't be relegated to code via Views or Features are hand manipulated with each "push" of updates and enhancements.

Does this path make sense with EE? My initial impression is that design and development is carried extensively in the database, AND that the database is not very portable.

Looking forward to thoughts, input and experience.

  • Are you also using version control? You may want to explore some of the write-ups on EE with Git or other version control systems. Commented Mar 19, 2014 at 21:24

3 Answers 3


I've very little experience with Drupal since 4.x many years ago, tried to get into it at 6.x and 7.x the last being 2 years ago. Ultimately went with ExpressionEngine 2 (had 1.6.x experience in the past for this).

That said here are some thoughts.

Templates - these can be flat files, you can use the administrative control panel to sync between the database and your files. However, as far as I know their settings, such as enabling PHP, have to be configured in the control panel.

Your content basically sits in channel entries. Channels are like the tables, entries are like rows. I don't think there's a generic flow for this between development and production sites.

Add-ons that extend EE whether just in the control panel, for templating, or new field types, are a mix between flat files and being installed in the db (may be more than a simple flag of present/absent & enabled/disabled if they have their own settings or take advantage of hooks).

There's nothing like drush for EE as far as I'm aware. So for both versioning needs and managing your setup, it's all up to you how you want to go about it. There is devot-ee for add-ons and an add-ons like their monitor and dev demon's updater or something to that allow you to compare versions of your add-ons and simplify updating process (haven't used the latter).

templates, frontend stuff, add-ons, and EE itself can all be managed in one regard, but as far as keeping database changes in sync goes I don't think there's even an unofficial community standard kinda thing.

I could stand to be corrected, though!

  • Thank you for the feedback... You got me poking around with the comment about enabling PHP. I have not gotten to the the real nitty gritty - extending EE using PHP. That appears to be something to approach with caution according to Ellis Lab tech help ellislab.com/expressionengine/user-guide/templates/php.html
    – sea26.2
    Commented Mar 17, 2014 at 18:31
  • Right, generally that's what add-ons are for. It all depends on your situation, e.g. for me while I like to pretend I have a team of people... it's just me, so sometimes I'll want to get something done quick & dirty. When it comes to templating, even with PHP you'll have to get seriously acquainted with Parse Order.
    – notacouch
    Commented Mar 17, 2014 at 19:48
  • 2
    I would recommend avoiding PHP in templates at all costs. It's a fairly common practice for each project to have a custom add-on with any custom PHP code you need. It's safer and much more efficient to use add-ons for custom code than directly in the templates. Commented Mar 18, 2014 at 12:16
  • 2
    Also of note, check out github.com/focuslabllc/ee-master-config which allows you to apply a multi-environment setup to EE. It helps makes the installation very portable (except for content) Commented Mar 18, 2014 at 12:17
  • @user908998 I completely agree with what Jeremy Gimbel's comments. Would add if you end up using some kind of boostrap/multi-environment config, remember to keep copies of the config.php and database.php that the EE installation produced. It may come in handy during upgrades to put the bootstrap aside and use the original configs again, once done with the upgrade keep a copy of the updated config, run a diff, apply changes/additions to your bootstrap.
    – notacouch
    Commented Mar 18, 2014 at 18:10

That which is not portable in the database can be set in the config.php see http://ellislab.com/expressionengine/user-guide/operations/moving.html

You can write a script to set these dynamically based on the current server, that way you can use the same config online or offline. (also the database connection settings will need to match if they vary between the servers)

This way once your setup you can copy the database between servers without worrying about directory and db config mismatches etc.


Let me be 100% clear that I am not even close to an expert on this, but I've recently started using the development workflow described on Krasimir Tsonev's blog in order to enable a local development process.


So in addition to what is already suggested in terms of saving templates as files and using Master Config to set local database settings, Tsonev adds some code to a few system files so that all of your database changes are logged to a separate .sql file, which you can commit with your template changes. You then just need to run the .sql commands on the staging/production server to recreate all the database changes.

Probably worth a look.

UPDATE: Just ran into this plugin last night which appears to do the same thing.


  • is there more info on the latter? the ee-db-trace repo?
    – notacouch
    Commented Mar 20, 2014 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.