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 ExpressionEngine 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 ExpressionEngine. (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:

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

<span style="\&quot;text-decoration:" underline;\"="">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.