11 EE-Tastic ways to speed up your development

Nov 04
2009
11 EE-Tastic ways to speed up your development

So, I’m going to assume that you all know what Expression Engine ExpressionEngine is and does – Originally built as a ‘blogging’ tool, it has quickly become a market leader in Content Management Systems and I not only use Expression Engine ExpressionEngine for all my freelance projects, but I’m also spearheading the adoption of it amongst my day-job, building enterprise level high traffic sites in the Framework.

I’ve decided finally that I should really get down in writing some of the techniques that I employ for the building of my Expression Engine ExpresionEngine websites. My last post raved about the recent ExpressionEngine and CodeIgniter (EECI2009) conference that I attended in Leiden, Holland – if you haven’t read it yet, I recommend you do! However, in the meantime here are my tips on minimising your development time and maximising your output.

Rename your ‘system’ folder

It’s somewhat irrelevant what you name it – it can be something such as ‘admin’ or ‘cms’ or something like that – but I recommend renaming it away from the standard. In fact, if you want. We chose ‘framework’ since that’s what it is (as per the EE Screencasts from Ryan Irelan!)

Change your ‘weblog’ reference

Since, 9 times out of 10 – you’re not going to building a ‘blog’ site – it’s a good idea to go into your Admin > System Preferences > General Configuration and change the entry in the ‘weblog designation word’. We used to use ‘section’ – however, the word ‘channel’ now seems to be gaining popularity and so we’ve started adopting that. You could quite easily call it ‘pages’ or ‘articles’ or what ever you want.

Setting your site up for languages

It may not necessarily be needed, but it’s always good to have it set up anyway – you never know when a client ‘may’ decide that they want to have multi-lingual content at some point in the future. simply create physical folders for each language in the root of your site (such as /en) and then in there copy your index.php and path.php. Then simply open your /en/path.php file and update the $system_path to refer back to your system folder ‘../system/’ and the $site_url should include your folder name (i.e. ‘http://www.sitename.com/en/’). Once set up you can then use a custom weblog field and the global arrays to refer and pull out the appropriate language content.

You then need to tell your site to load a ‘language’ by default. The simplest way of doing this is to use a .htaccess file with ModReWrite. An Example of this is as follows :

RewriteEngine On
RewriteCond $1 !\.(gif|jpe?g|png)$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !^/framework
RewriteCond %{HTTP_HOST} .
RewriteRule ^(.*)$ http://www.nameofyoursite.com/en/ [R=301,L]

Remove your index.php from the URL

There are many ways to get this accomplished – but by far the easiest, is to simply use a ‘.htaccess’ file in your root. Using the ModReWrite functionality of Apache, you simply create a file in your root (if you’re using language, put it into your /en/ folder) with the following :

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /en/index.php/$1 [L]

Simply repeat this for any other language folders you have (make sure you change the /en/ value to match the other folders

then, in your control panel, go to Admin > System Preferences > General Configuration and remove all references to index.php from the fields there.

Create global arrays

I find that people don’t use Global Arrays enough in their EE driven websites. The use of global arrays in your path.php file is a great way to have common values and settings available irrelevant of where you are in your EE site. It also is extremely handy when it comes to ‘multi-lingual’ sites when you need text and navigation options to be loaded in different languages without any complex if statements.

In your path.php file, you create an associative array against the $global_vars variable. An example of this is as follows :

$global_vars = array(
"lang_code" => "en",
"requestbrochure" => "Request a Brochure",
"othernews" => "Other News",
"archive" => "View our Archives"
); //

This means that anywhere in your EE instance, you can now refer to {lang_code} or {requestbrochure} to get the value.

If you now imagine that I have an /en/path.php and an /fr/path.php file (for my English and French Language Multi-Site) – I would simply have two path.php files:

/en/path.php

$global_vars = array(
"lang_code" => "en",
"requestbrochure" => "Request a Brochure",
"othernews" => "Other News",
"archive" => "View our Archives"
); //

/fr/path.php

$global_vars = array(
"lang_code" => "fr",
"requestbrochure" => "Demandez une brochure",
"othernews" => "D'autres nouvelles",
"archive" => "Consultez nos archives"
); //

You now understand the power and potential that your global variables allow you to have. Whilst EE does allow for Global Variables – it doesn’t give the flexibility to be able to store values in depending on language.

N.B: For the French speakers, I’m sure you’ll see the French is probably not correct – I’m not a French speaker, so have taken ‘babelfish’ at its word for demonstration purposes.

Use EE’s ‘global variables’

Ok – this is a slight contradiction to the previous point, but it was a tip that I learned from the EECI2009 conference. Everytime you run an ‘embed’ to a template as part of an include, the load on your Expression Engine increases exponentially. This is because every time a template is called, it starts all the database requests again. So it’s a good idea to use ‘Global Variables’ in EE for content that doesn’t change on the site – things such as your Javascript script includes, maybe your footer or even your ‘signup form’ could be put into the EE global variables and when called, wont put undue load on your servers (especially if building for high traffic sites).

To create EE Global Variables, simply Log in to your control panel and select Templates > Global Variables. You can simply create as many global variables as you want here and the big win over using the path.php variables is that you can put HTML into these ones (ok, you could in theory do that with the path.php but not without a ‘lot’ of escaping characters!)

Create ‘File Templates’

In terms of rapid development, using your favourite text editor to work on your EE/HTML coding is much much easier than using a web browser in the control panel. To enable File Templates, simply log in to your control panel and go to ‘Templates > Global Template Preferences’ and enable the ‘Allow templates to be saved as files’. Make sure you have a correct path set up for them – I recommend putting it in your /system/templates folder, but the choice is up to you.

Two things to bear in mind when editing files are that

a) You still have to ‘create’ the template first in the control panel, then open the new template and select ‘Save Template as File’ option at the bottom before saving

b) ‘Template Revisions’ doesn’t work when editing the file outside of the control panel

Setting database variables in your config.php

I’m pretty sure there’s an easier way of doing this – however, one of our problems is that we have two levels of site structure when developing in the office. We have ‘staging’ and ‘live’. Each of these have different databases. Aside from the issue of ‘synchronising’ databases between two hosts, we use a simple if clause in our /system/config.php file to allow us to switch hosts easily. An example of this is as follows :

$sitedb = 'dev';

if ($sitedb =='live'){
$conf['db_hostname'] = "liveserverhost.com";
$conf['db_username'] = "dbuser";
$conf['db_password'] = "dbpass";
$conf['db_name'] = "dbname";
}
else
{
$conf['db_hostname'] = "devserverhost.com";
$conf['db_username'] = "different_dbuser";
$conf['db_password'] = "different_dbpass";
$conf['db_name'] = "different_dbname";
};

Now all we need to do is simply open the file up and change the $sitedb variable from ‘dev’ to ‘live’ when we want the site to use the live database details. Much easier than trying to remember the host details every time we deploy.

Setting naming conventions

This is a fairly new addition to our structure in EE. As sites get larger and larger, it’s sometimes difficult to follow data fields, so when you see an expression tag for {summary} or {image1} – it’s difficult, without a lot of backtracing to see where its come from – so I’ve adopted my old MS-SQL naming convention to structuring custom fields in weblogs:

{type_or_relationship}_{weblogname}_{parameter}

For example, a simple news collection would be as follows:

{news_summary}
{news_body}
{news_lang}
{authors_news_author}

Working on this principle now allows us at a glance to understand what we’re looking at. The last custom field listed above is in fact a relationship to the ‘Authors’ Weblog entries.

In addition to this, when using Brandon Kellys Awesome Field Frame Matrix we employ the following structure:

{ffm_news_images}

this tells me that it’s a FF Matrix Collection of News Images – and then within each column of that – we then break it down further:

{ffm_news_images_file}
{ffm_news_images_caption}
{ffm_news_images_credit}

and so on so forth.

I’m sure there are some of you reading it thinking that it’s way over the top for what you do – however, in an environment where there is more than one developer – it’s *essential* to have a naming convention for your data.

Use version control

This has probably been done to death – however, it’s something that I can’t rave enough about. We implemented a Subversion system in the office through a web-based service called ‘Beanstalk App‘. A great system which allows you to create SVN repositories in an easy to use web-app. It also even supports deployment etc – although, we’ve had varying results from that so far.

The benefit of using Version control is that you can have a ‘clean EE’ install set up and ready in a repository which you simply ‘export’ it when you want to create a new site.

What we’ve done is basically set up an ‘empty’ EE site with all the plugins and addons that we use on our sites, tweaked the control panel, created a ‘CMS users member group with appropriate permissions, created our ‘standard’ channels/sections with custom fields and everything that we would normally do when starting a new site and then using SVN, Command Line and a Mac – we simply ‘import’ the whole lot into Expression Engine. (I simply go into the root folder of the site in command line and type

svn import http://urltobeanstalksvn.com/repo_name -m "Initial Import"

This then imports everything for me.

Now whenever we need to create a new site in EE – we simply do an ‘export’ (rather than checking out, because we don’t want to check-in to this repository) – in the same respect as previously, command line to the root site folder of a new site and run

svn export http://urltobeanstalksvn.com/repo_name

This will then export everything for you (without the SVN association) and you can then import this to a new repository for your new site and start developing with full version control.

N.B When doing your import to SVN, I would also recommend at this point doing a ‘backup’ of your EE Database and including the resulting .sql file into the root of your site – this means that you can simply ‘restore’ this backup to a different database when creating your new site.

Creating a ‘deployment checklist’

Ok – so you’ve created the site and now you need to launch the site. First Upload all your development files to your live server and then simply follow these basic instructions:

Export/Import your Database

Using whatever your host provider gives you (normally  phpmyadmin), ‘backup’ the development database to a .sql file and then open it into your favorite text editor:

  • Ensure you remove the line ‘Create Database…..’ – since this should have been created by your host
  • Rename the database on the line ‘use {dbname}’ and change it to the name of your database on the live server
  • Now do a find/replace of `dbname` and replace it with `new_dbname` (include the ‘backticks’ in your find/replace – not apostrophes)

Save the file and run it against your live database server to create the database.

Set Database Values

Assuming you’ve followed the advice above, open your /system/config.php and change the $sitedb value to ‘live’. Now upload this to your live server.

Update Paths in Control Panel

Now, log into your Control Panel and you need to update a series of paths :

  • Go to Admin > Utilities > PHP Info and search for ‘document_root’. Note this value.
  • Go to Admin > System Preference > General Configuration. Update all the appropriate values in here and Save.
  • Go to Admin >Weblog Administration > File Upload Preferences. Edit all your path locations and URL’s in here and Save.
  • Go to Templates > Global Template Preferences > Update the location to your ‘Template Files’

Empty the Cache

Although this is a new site, likelihood is that you’ve uploaded all the cache data from your development site – so make sure you delete it and start from fresh

Finally, check the site!

It may seem like a silly thing to say, but make sure that you can post into forms that you should be posting and that you can see the articles that you are expecting. Check that Images are appearing as they should (make sure you view source of the site as well to make sure there’s nothing still referring to the dev site url)

This is not exhaustive!

I’m pretty confident that there are more ways out there to further speed up and maximise throughput on your EE sites – I’d be interested to hear other developers suggestions for what they recommend to speed like up! Feel free to comment below.

  • Share/Bookmark

12 Tweets

17 Responses to “11 EE-Tastic ways to speed up your development”

  1. cwcrawley says:

    New Blog Post : ‘11 EE-Tastic Ways to speed up your development’ http://is.gd/4MXZL #expressionengine #ee (pls RT – kthxbye!)

    This comment was originally posted on Twitter

  2. ee_hub says:

    11 EE-Tastic Ways to speed up your development http://bit.ly/1nlScY via @cwcrawley #ee

    This comment was originally posted on Twitter

  3. wez says:

    Love #EE?

    How could you not help but

    This comment was originally posted on Twitter

  4. Luc says:

    I wasn’t aware that global variables were less of an overhead than embeds – I’ll definitely be using that tip on my next site…

  5. James says:

    Under Creating a ‘deployment checklist’ -> Update Paths in Control Panel we have found using the Deeploy Helper add-on from Hopstudios ( http://www.hopstudios.com/software/deeploy_helper/ ) has been a HUGE timesaver. It simply lets you adjust all your paths from one page.

    Your points on language just saved me a million headaches, being in Montreal and all.

    Thanks for the excellent post.

  6. cwcrawley says:

    @blivengood yes – couldn’t develop without them…. http://bit.ly/3Zv7k6

    This comment was originally posted on Twitter

  7. cwcrawley says:

    @magzalez we don’t – we remove them http://bit.ly/3Zv7k6 :) #ee

    This comment was originally posted on Twitter

  8. Jefj says:

    Great write-up! I’ve been working on making my own checklist and this is a great supplement so thanks!

  9. janq says:

    Reading “11 EE-Tastic ways to speed up your development” – http://tinyurl.com/yj3utcm #EE

    This comment was originally posted on Twitter

  10. Carl Crawley says:

    @James => Thanks for the pointer, I’ll defo take a look at that plugin on our next deployment!

    @Jefj => No problems at all, feel free to hit me up on skype or email if you want to collaborate on a post at all… I’ve already got other hints and tips that I’ve thought about since!

  11. Prairie142 says:

    11 EE-Tastic ways to speed up your development « Digital Meanderings: This is because every time a template is .. http://bit.ly/3TlVgN

    This comment was originally posted on Twitter

  12. John Faulds says:

    You can save yourself having to update a lot of system paths if you add them to a default config file. Here’s what mine usually looks like:

    $conf['site_url'] = “http://${_SERVER['HTTP_HOST']}/”;
    $conf['tmpl_file_basepath'] = “${_SERVER['DOCUMENT_ROOT']}/templates/”;
    $conf['theme_folder_path'] = “${_SERVER['DOCUMENT_ROOT']}/themes/”;
    $conf['theme_folder_url'] = “http://${_SERVER['HTTP_HOST']}/themes”;

    $conf['captcha_path'] = “${_SERVER['DOCUMENT_ROOT']}/images/captchas”;
    $conf['captcha_url'] = “http://${_SERVER['HTTP_HOST']}/images/captchas”;
    $conf['avatar_path'] = “${_SERVER['DOCUMENT_ROOT']}/images/members/avatars”;
    $conf['avatar_url'] = “http://${_SERVER['HTTP_HOST']}/images/members/avatars”;
    $conf['photo_path'] = “${_SERVER['DOCUMENT_ROOT']}/images/members/photos”;
    $conf['photo_url'] = “http://${_SERVER['HTTP_HOST']}/images/members/photos”;
    $conf['ft_path'] = “${_SERVER['DOCUMENT_ROOT']}/${conf['system_folder']}/extensions/fieldtypes/”;
    $conf['ft_url'] = “http://${_SERVER['HTTP_HOST']}/${conf['system_folder']}/extensions/fieldtypes/”;

    You can also get around having to reset file upload directories by using relative paths, e.g.

    Server Path to Upload Directory = ../images/
    URL of Upload Directory = /images/

    Then, using your default install method, assuming you always keep the folder structure the same, whenever you start a new site, those settings are already correct without having to edit anything.

    You can also get around having to use a particular naming convention for your custom fields if you use Brandon Kelly’s excellent Gypsy extension – create a custom field once and use it wherever you want.

  13. MarmaladeToday says:

    Great article on EE setup. I particularly like that you flag up the per language folders and global arrays. Useful tricks for non-language sites too (e.g. per City).

    I was going to point out the Deploy Helper and the config trick Tyssen flagged up as well.

    You should also take a look at the addons by Experience Internet and Purple Dogfish for easy settings finding during build.

    Also you can use {site_url} or {homepage} in the admin settings for URLs in weblog preferences etc too.

    And, on a pedantic note, it’s ExpressionEngine (all one word). Sorry, but it just jars now when I see it spaced.

  14. Emmanuel says:

    Thanks for this bunch of nice and truly efficient (life-saving?) tips and good-practices. I just hope I’ll be using them very soon.

    And by the way….”View our Archives” => “Consultez nos Archives” ;-)

  15. Carl Crawley says:

    @John => Many Thanks – I hadn’t been able to find any documentation on whether I could use global config variables, but it’s good to know!

    @MarmaladeToday => Thanks for the pointers and the addons – I’ll defo check them out as part of my default EE build – I’ve also change the references to ‘Expression Engine’ – hope that keeps you happy :-)

    @Emmanuel => ‘Merci Beacoup’ for the post, French duly changed!

    All Comments are great – good to see that I can be of help to some people.

  16. Jerry Gennaria says:

    Would love to see a more indepth article on your technique for multi-language development.

  17. Stephen Pratley says:

    Great article, now I understand some of how the default template in EE2.0 was put together using global variable for various embeds.

    John Faulds: I didn;t realise how much you could move into the default config file, that should save us a few headaches!

Leave a Reply

Additional comments powered by BackType

Links of Interest!

Here are some links of sites/people that I find interesting...

Compliances

This page and most pages on this site should comply with w3c validation where appropriate. If you find it doesn't, please notify me