Thread

I’m converting a site that currently lives in a homemade CMS into EE.  A question that’s come up several times is, “Why use templates for outputting content, rather than modified versions of the PHP functions we already have?”

The idea is to include PHP in one or more EE templates, use the templates to get data, and then call PHP functions with data as parameters, which would then output HTML/Javascript/whatever.

The benefits cited in this approach are…
- the PHP already outputs exactly what we want to output
- we already know how to do PHP, while EE templates are new
- if we ever want to move away from EE, all the output logic can come with us

I know some of the straighforward benefits of EE templates.  They’re a lot easier to maintain than PHP.  They’re versioned.  They’re backed up with the database.  Etc.

But I haven’t been able to put into words the core reason to use EE templates for output.  I think it probably has something to do with the fact that templates are where a lot of a CMSs benefits actually manifest.  They’re the clearest window into the data relationships the CMS maintains.  Or something like that.

I bet someone here can say it better than I can.  What’s so cool about templates?

—Justin

If anything the beauty is that you don’t have to…you can alway have a hybrid of pages where you paste your php page/code containing the custom sql statements,echo etc and all…

One other nice thing about not having pages in db vs. ‘traditional files’ is that you can service you client from any machine (such as a coffee shop) and do quick edits through web without needing an ftp program to reflect the change.

Portability and re-usability(sure php includes does it) would be one reason but above all you can benefit from native EE modules and tags to really become your own framework within the EE.
In my mind I would rather use the query module with straight up sql statement in it vs. ...creating a connection file to db, writing and troubleshooting php syntax , echo-ing the output…in my own words it is much like what css provides to design and content separation -that is what EE templates do as well..giving you another level of separation of content,design and dynamic language of php.

These are just some of my personal joys with EE but I am sure staff here can give you better worded statement. 😉
All the best!

I guess my first thought is/was, since you’re taking the custom php approach (heavily), why even use EE at all?

I guess my first thought is/was, taking the custom php approach, why even use EE at all?

::touches nose::

Hey PXLated, that’s definitely the question that came to my mind first, too.  But the counterpoint is that EE has robust user management, authN, authZ, relational data structure management, data input interfaces, and plenty of other valuable content management features that, on their surface, don’t seem to depend on whether or not you template the output.

It’s no surprise that folks who’ve worked with EE, as I have, are baffled by a proposal to perfectly bake the back end and then skimp on the front-end frosting.  But I’m looking for a convincing way to explain why, something better than, “That’s just plain silly.”  I was hoping someone would drop in with a killer argument that very clearly articulates the central role that templates play in EE.

Justin

I was hoping someone would drop in with a killer argument that very clearly articulates the central role that templates play in EE.

Well if you need it enumerated…  Templates are a core portion of the application.  It’s not a module to be cast aside or determined whether or not it’s best to implement for a given site.  Templates are your site in ExpressionEngine.  Any effort expended away from this approach is energy spent working against the application, and that wastes your time as as developer, makes your site less portable, and increases the difficulty for the client to takeover, get support, hire another EE developer, etc.  So part of the answer is that there’s not a sales pitch necessary to determine whether or not to use EE’s template system.  If for a given project there is some need to not use EE’s template system, you probably shouldn’t be using EE at all for the project.

The template parser gives you ready access to your information, in dozens of different ways, with human-readable syntax and flexibility.  This dependable syntax is what allows you to use modules, plugins, and extensions to extend ExpressionEngine’s abilities that are not part of a standard installation in a consistent and predictable manner.  Also if you are not using tags, in addition to re-inventing the wheel with whatever PHP you use to fetch and output your data, you are most likely bypassing some very important security and authorization checks and filtering.

From an additional technical standpoint, PHP executed in templates is still run through the template parser.  You aren’t doing much in your favor as far as lightening the load of the application, and in fact would probably make it worse.  Not only do you have to enable PHP parsing (which in some organizations would present security risks or at least be a likely source of introduction for unintentional errors) but you will be selecting output or input parsing, each taking place at different times in different contexts within the template parser.  If you’re using a fully PHP-based output solution, this may force you to code in ways that are unconventional or undesirable to work within the confines of PHP parsed in templates at that stage.  Lastly, PHP in templates must be executed with eval() and PHP unfortunately handles variable scoping quite a bit differently within eval() than it does when executed by the parser from a file, which could further complicate your code.

Shall I go on?

For me, it’s also easier to maintain the “look” of the site separately from the functionality. In the short run, it’s better for my sanity, but in the long run, it’s easier for my company to hire someone who is proficient in design to deal with the front end of the site and someone who is proficient in PHP to deal with the back end without worrying about whether they will step on each others’ toes.

But then, I’ve gotten to the point where I try to have PHP parsing turned off in the templates as much as I can, and move any programmatic behavior back into a module, extension, or plug-in rather than have it cluttering up a bunch of different pages that all need to be maintained separately.

Hey PXLated, that’s definitely the question that came to my mind first, too.  But the counterpoint is that EE has robust user management, authN, authZ, relational data structure management, data input interfaces, and plenty of other valuable content management features that, on their surface, don’t seem to depend on whether or not you template the output.

Honestly, I wouldn’t consider EE’s current structure management or data input interfaces very useful if you aren’t going to be using the template module. Semantically, they aren’t very helpful if you’re writing your own SQL queries instead of using the template system’s exp:weblog:entries structure.

The answer is here. 😉

Wow—you all nailed it!  Thanks, everyone, for the quick and thoroughly convincing replies! 😊

Justin

We do what we can. :-D