« Homepage

Create an alternative version of your ExpressionEngine website

17/06/09
Jamie Pittock

We announced the launch of the iPhone version of the Erskine Design website on Tuesday.  This alternative version of the site is located in a subdomain of the main erskinedesign.com domain, but both versions run on the same ExpressionEngine install.  I thought there’d be a number of people out there who might be interested how I did it.  So here you go…

In our case we created an alternative version of our site specially optimised for the iPhone but there are multiple use-cases for the technique I’m about to describe.  For instance, perhaps you want to offer a ‘lite’ version of your site for people on slow web connections, or maybe multiple versions of the same site using different languages, or even geographic-specific versions of the same site.  Think about an international news website with alternative versions where the content becomes country specific by using subdomains. 

I’ve heard a few people say they’d use the Multiple Site Manager for this kind of thing.  I think this is over kill at best, and just plain wrong at worst.  In my eyes we’re not dealing with multiple websites here;  instead we have two versions of the same website.  This is an important difference. 

To create an alternative version we’ll have to assume that you have an existing ExpressionEngine website installed on a web server somewhere.  The first thing we’ll do is open that installation’s path.php file in a text-editor.  Within that file you’ll see the following line:

$global_vars = array();

Global path.php variables are described in the EE docs so I won’t go into them here.  Anyone who came to my FOWD workshop will know how useful I find them, and if you weren’t at the workshop, don’t worry I plan to talk about them more in the near future.

Underneath that line you want to add the following:

$global_vars['pv_site_version'] = 'full';

What we’ve done is create new global path.php variable called ‘pv_site_version’ with the value of ‘full’.  At Erskine we prefix the various different types of variables available in EE so that they are easily identifiable in our templates.  In the case of path variables we prefix them ‘pv_’.  This variable will be available in your templates by using {pv_site_version}.

Our next job is to create the subdomain where our alternative version will live.  How you do this depends on your server setup so go off and do that, and in the meantime we’ll have an intermission.

Everyone created their subdomain?  OK let’s carry on.

What you need to do next is copy the index.php and path.php files from your existing EE install to your new subdomain.  Once you’ve done that open the subdomain’s new path.php in your text-editor, and change the ‘pv_site_version’ variable value from ‘full’ to ‘iphone’.

$global_vars['pv_site_version'] = 'iphone';

At the top of your copied path.php you also need to alter the $system_path variable value to point to your existing EE installation’s system folder.  Currently it will say something like this:

$system_path = "./system/";

You’ll need to alter that value so it still points to the same system folder.  It might be something like this:

$system_path = "/var/www/html/system/";

We now have two versions of the same website!

If you load your subdomain in your web browser now you’ll see your existing website (how perfectly images and CSS display may depend on whether you’re using absolute or relative paths on your templates).  If you add the {pv_site_version} variable into one of your templates and view the output in your browser you’ll see that we do actually have two versions of the same website.  One version outputs the word ‘full’ and the other version outputs the word ‘iphone’.

So how do we use this to serve different templates?

Lets say for example we have a template group called ‘home’ and this group’s index template is used for our website’s homepage.  We want to create two different versions of this index template, one for our full version and another for our iphone version.  Once you’ve done this you may have 3 templates that look like this:

  • home/index
  • home/_full_index
  • home/_iphone_index

In the _full_index template add the HTML needed for the full version homepage, and in the _iphone_index template add the HTML needed for the iphone version.  Then open the home/index template and add the following:

{embed="home/_{pv_site_version}_index"}

As we know, our {pv_site_version} variable will output a different value depending on which version of the site you’re browsing and therefore, using the code above, the template that we embed will depend on that value.

And that’s pretty much the long and short of it.  Depending on your requirements you may need to vary the method you use to choose which template is displayed.  For example, sometimes you may have pages that exist on the full version of the site but not on the alternative.  For those cases you might do something like this:

{if pv_site_version == "iphone"}
{redirect="404"}
{/if}

{if pv_site_version == "full"}
{embed="casestudies/_full_index"}
{/if}

The above assumes you have a template called ‘casestudies/index’ which should appear on the full site but not on the iphone version.  If you don’t want to use embeds you could just put the actual template code between the conditionals I suppose.

And that’s that.  If you’re interested in some of the actual design decisions that were made in the process of creating our iPhone site stay tuned as Greg will be including the details as part of his “behind the scenes” series.

I hope I’ve sparked some ideas in you for how path variables can be used to create multiple versions of the same ExpressionEngine website. 

32 Comments

  1. Allan White
    17/06/09 at 20:58

    Excellent! This is much more elegant than what I came up with (I just used /m instead of a subdomain).

    How about user-agent detection? What are best-practices on automatically routing users to the mobile version?

  2. Mitchell Kimbrough
    17/06/09 at 21:32

    We go crazy with the path.php file here at Solspace. We added mobile device detection to the path.php file for a big client. People on a mobile get redirected to the mobile site right away, and then have an option to opt out and see the full site. We’ve found this to be pretty user friendly.

    mk

  3. Jamie Pittock
    17/06/09 at 22:02

    Jamie Pittock

    Mitchell - in this instance we went with the opposite…if you visit the Erskine Design site on an iPhone you see a prominent link explaining there is an iPhone version which you can manually choose to go to.

    We weren’t comfortable automatically redirecting people until we’ve looked into how it effects the user experience some more.

    I guess we’re all learning here.

    Allan - we don’t know what the best practices are.  I think a lot of it depends on context - if you’re offering a slimmed-down mobile version then I’m not so sure you should be automatically redirected, especially on the iPhone.  You’re making the decision for the user that they want the slimmed-down version rather than the full-fat.  Which doesn’t sound right to me.

  4. fitzage
    17/06/09 at 22:21

    With fitzage.com, I made all links between the desktop site and the mobile site completely compatible with a little rewrite action. Each site has its own templates and users are directed to the iPhone version if they are using an iPhone, but the links cane be shared easily between iPhone and Desktop users because they’re exactly the same.

    Obviously this wouldn’t work for every site, but all content on fitzage.com is present in both, so there is no reason why one would need to go to the full site instead of the mobile site.

  5. fitzage
    17/06/09 at 22:23

    Oh, and to clarify…what you’ve done here looks really good, and it should make things easier for sites that don’t follow the pattern of my main site. Thanks!

  6. Marcus Neto
    17/06/09 at 22:42

    Was just talking to someone at our church about how to handle the Spanish Campus and the Mobile viewers. Thanks for this article it will definitely come in handy on that project.

  7. Hambo
    18/06/09 at 00:35

    Hi Jamie,

    I’d like to know more about your talk on Global path.php variables. I probably criminally under use them!

    PS. Is the Erskine blog the new Jambor-ee?

  8. Jamie Pittock
    18/06/09 at 07:54

    Jamie Pittock

    Fitzage - Good stuff, there are always multiple ways of doing stuff.  I’m not getting redirected on your site by the way on my iPhone.

    Steve - you’ll love path.php global variables once you start using them.

    My focus at the moment is establishing ErskineLabs.  Jambor-ee is still there, staring at me longingly!  I want to kick-start it (again!) but I need to make sure there’s a need for it first.  Jambor-ee was the original fansite but there’s plenty of others which have filled the gap in it’s absence.

    Basically, I think Jambor-ee will be back, but only when I can fully commit to it.

  9. Andy Harris
    18/06/09 at 13:58

    Brilliantly simple! Didn’t even consider this, despite toying with MSM quite a lot recently. We’re currently looking at mobile sites and considering best ways to do it, but as far as structuring EE to handle it goes this is ace.

  10. Jerrod
    18/06/09 at 14:05

    Indeed - the ability to simply create multiple (completely different) versions of a site is a great advantage to EE. We love doing this at iLounge:

    http://www.ilounge.com/
    http://www.ilounge.com/mobile/

  11. fitzage
    18/06/09 at 15:53

    Uh…oops. I recently had to switch servers because I broke something on the other one, and my htaccess file didn’t make it over. fitzage.com does what it should now. :-)

  12. Jason
    18/06/09 at 16:00

    Thanks for posting this. I recently set up a mobile version of a site using MSM, but as you said, it did seem like overkill at times. I’m really looking forward to trying this approach on some future projects of mine.

  13. Hambo
    18/06/09 at 16:06

    I assume this is only useful if the administrator or Editor has control of all sites?

    I have been creating franchise based sites which do share the same templates but require member (admin/editor) segregation.

  14. Mark @ Alchemy United
    25/06/09 at 02:47

    Nice trick. I’ll have to give it some serious consideration for a project we have coming up.

    If I had one question, it’s this - what is the advantage of subdomain over domain/mobile?

    If I had a second question, it would be - are there any Google issues? Be it crawling / indexing, using Analytics, or anything else for that matter?

    Thx

  15. Marty
    03/07/09 at 06:06

    Just got around to reading this. Thanks so much for sharing. It’s going to be very useful.

  16. Jamie Pittock
    03/07/09 at 08:22

    Jamie Pittock

    @Mark As discussed via email, the advantage of using a subdomain is just convention and good practice.

    @Hambo I don’t know mate.  You might still be able to use this method but you’ve got specific requirements there that only you can answer.

    @Jason @Marty No problem at all.

  17. Dave
    08/07/09 at 07:51

    I have been using user-agent detection but I think this might be a better option as it gives the user a way to get to the full site. Well done and thanks!

  18. GDmac
    16/07/09 at 21:10

    path.php does have some extra tricks up it’s sleeve. Next to the $system_path variable you can also set some other variables in path.php, like $template_group to use a different ‘default’ template group, instead of pv_site_version juggling. However, both solutions have their advantages. (EE wiki, running multiple subsites)

  19. Benjamin David
    26/08/09 at 14:18

    Thanks a lot for this tip ! It helped me set up the structure of the iphone and english version of a project I’m working on.

    I also read some SEO blogs, and it looks like I’m gonna have to work on Two December’s website to make it use subdomains instead of folders for foreign version of the site. Looks like the best thing to do for alternate version (mobile, translated, etc…) of a website.

    And I’ll use your method this time, which is much cleaner than the one I had set up when I was beginning with ExpressionEngine :)

  20. Mark @ Alchemy United
    26/08/09 at 15:09

    @ Ben - Interesting? Might you be able to share that link(s) on SEO and / (slash) vs subdomain? If you’re country specific (and not so much language), might you be better off from an SEO perspective with .ca, .uk, etc.?

    That said, as they say “Never design for search engines. Design for your users.” And as I believe Jamie mentioned above, in some places the users’ expectation is for subdomain, and others it’s / or maybe even .mobi.

    Just curious… So are you going to do your subdomains by language (e.g., spanish.mysite.com) or some other naming convention? Do you think that has any SEO effect? As minor as it might be?

    Great thread. It’s great to wake up everyday and realize I will never know it all :)

    p.s. Anyone heard any good rumours on the official release of EE 2.0? Maybe they should just jump the release name to 3.0 and not get stuck smelling like a cheap web 2.0 whore in 12 months :)

  21. Benjamin David
    29/08/09 at 01:00

    The best article I found was one from Seomoz. It describes the pros and cons of each method : Root Domains, Subdomains vs. Subfolders :

    http://www.seomoz.org/blog/understanding-root-domains-subdomains-vs-subfolders-microsites

    For Two December, I have a french version, an english version and a mobile version. Today, I’m using subfolders and the problem with french/english versions is that I oftenly have mixed results on Google of what I’m looking for. Sometimes english pages have a better rank in Google France than french pages… weird.

    The country specific solution seems great (.fr, .es, etc…) and more intuitive for the user, but the downside is that you have to make powerful two different domains (looks easier to make 2 subdomains powerful).

    That’s why I think that the next version of Two December will use subdomains, it should keep the pages as powerful as they are today (hope more of course, but you never know :)), and solve my problem of mixed english/french results.

    And I can still use country specific domains to redirect to the subdomains :
    twodecember,fr -> fr,twodecember,com

    It’s not gonna help me at all with Google but it should help the users. Another thing that can be made to help them is create a “www,fr,twodecember,com” redirection. Too many people think this segment is required to get to a domain.

  22. Brian Coult
    16/11/09 at 16:30

    Great post and very intuitive what you mention… im however a little complexed at how this would work well for a multilanguage site.. but i might be missing something too… this way would create non-language specific URL titles if im not mistaken? and you would still have to either implement some langauge translation file or still have multiple custom fields for language specific content when entering a new weblog entry?

    Like i say i might be missing something, and i know that its hard one when we are talking about multi langauge.. think it looks great for things such as mobile version and so on though.. .very nice indeed.

  23. Jamie Pittock
    16/11/09 at 17:11

    Jamie Pittock

    Brian, if you want language specific url_titles then this technique isn’t for you.

    you would still have to either implement some langauge translation file or still have multiple custom fields for language specific content when entering a new weblog entry

    Yes.  I don’t know a way of doing multi-language sites without doing that.

    I think you’re missing something ;)

  24. Brian Coult
    16/11/09 at 17:34

    Thanks Jamie.. didnt think it would, but looks great for the mobile part… using on my own new site design.

    Thanks for sharing!

  25. Mark @ Alchemy United
    16/11/09 at 17:34

    Truth be told, I have zero experience with a multi-language site.

    That being said, from a strict UI / UX perspective, I would suspect that language might be fairly synonymous with culture, and that in turn factors into UX. 

    In other words, just taking a site and changing the language might not yield the best results.

    Finally, the latest issue of (US based) Internet Retailer mag - Ok, I agree, it’s not exactly top shelf reading material but none the less - has a list of companies with mobile sites. Might be a way to study up on possibilities, eh?

  26. Jamie Pittock
    16/11/09 at 18:38

    Jamie Pittock

    Out of interest Brian, how else do you see a multi-language site working without a language translation file or multiple custom fields for language specific content?  You’d have to have multiple entries, one for each language, or as Mark hinted at different sites per language.

  27. Brian Coult
    16/11/09 at 20:05

    Yeah i thought it would need the multiple custom fields, as the language translation file i dont think would really cope with a full weblog entry for say a news item. I cant see it translating that correctly. Ive been looking into it as i was quoting for a multi language site today for a client and couldnt decide which way to do it.. each way seems to have its drawbacks, advantages and disadvantages.

    With custom fields you could have fields for all languages in one entry, which would mean it would be well organised and easy to find, however i dont like the idea of lots of custom fields and i guess would also prefer language specific url titles etc… the other option although i think overkill but allows for more flexibility is seperated into MSM meaning that you could have unique content areas for each language, better url’s but the disadvantage of this would be that it would be much more work to add a new language as you would have to clone the site, edit the templates and any other language specific settings..

    Have heard it might be possible to clone the entries using MSM but leave the actual templates on the original (default language) site so there is only one set of templates to control the layout etc.. but not tried this as yet. Maybe a mix of this and the multi language site alternative http://expressionengine.com/wiki/Multi_language_site_alternative/ would work well…

    Like i said cant see any 1 way that works best…

  28. Mark @ Alchemy United
    16/11/09 at 20:27

    I wish I would have posted tihs sooner but I wanted to ask… How do intended on being multi-language without having multiple languages :)

    Another option might be to figure out some sort of crowd sourcing type idea such that a given article would be translated by the crowd and not the client. .Of course that open a can of auditing worms but maybe if the brunt of the work can be done by the crowd, the client can free up resources. But what was the client expecting? More content and no work to get there? Ok, don’t answer that :)

    Moi? I’d be looking at MSM. Only because in my UX heart of hearts. Multi-lang != OSFA (one size fits all). It also implies a geographic and cultural component such that at some point a certain core of content might be shared but then there’s probably just as much content unique to a given language/culture/geo-location.

    IMHO, of course ;)

  29. Mark @ AlchemyUnited.com
    16/11/09 at 23:39

    Pardon me for jumpin’ right back in but now that I’ve thought about this a bit more…

    I would think that groups/members/security might be an issue, no? In other words, EE’s permissions are defined at the weblog level. So if, for example, there was a single news weblog and a custom field for each language, that would mean each person entering and/or translating would have to have access to that weblog, as well as each other’s copy.

    It depends on the organization but that typically might not be so wise, eh? I’d have to give some thought to a work around - there always is one - but my gut feeling is it might not be as pretty as one would hope.

    Bottom line… take this to the EE forums. You’re likely to get some good input over there :)

  30. Canvas Prints
    16/02/10 at 10:58

    Thanks for this post, on the off chance does anyone know how to do this without using the expression engine, i.e just make my website work on another domain or sub folder

  31. Phil Norton
    26/02/10 at 15:58

    Just wondering how this setup affects pagination, and certain links etc? For instance, the {auto_path} in pagination seems to insert the Site’s URL into the mix, negating the m. subdomain. Similarly, the {page_url} tag also seems to reference the full URL.

    Of course, I’m possibly missing something very, very obvious… Anyone know how to get over these?

  32. GDmac
    28/02/10 at 07:19

    Already mentioned before, Path.php has some extra tricks up its sleeve. You can set some basic variables like site_url in there and the default template_group. Thus per directory.

    EE Wiki, running multiple domains or subdomains or subsites

Submit your comment

* denotes required fields

Allowed HTML

  • <a href=""></a>
  • <em></em>
  • <strong></strong>
  • <blockquote></blockquote>
  • <pre></pre>
  • <code></code>

Back to top