ansaurus

Question

Answer 1

+1 A:

I thought, if you only want to be able to change images, colours, fonts, div placement etc, you could let your customers edit the css files, also solving your problems with security.

Samuel 2010-05-24 11:27:22

Answer 2

+2 A:

You really need to prevent your customers from incorporating any php or javascript into their website. Any image uploads should be format converted to something else then back again on upload.

Problem is that most editors will not allow you to build up fragments of a page. As Samuel suggests you could restrict them to only editing the CSS (and publishing their own graphic content) - but this can be rather restrictive. One approach to solving this problem is ESI - but that requires a high level of skill with the technology for anyone involved - and try to restrict peolpe from doing stuff they shouldn't is rather difficult.

Another approach is for you to provide a set of html fragments (which should contain matched tags and no positional / font info other than classes) and have the customer provide an HTML page with a set of placeholders where you insert your content, e.g. customer provides:

<html>
<title>{%PAGE_TITLE%}</title>
<link rel="stylesheet" href="{%STANDARD_CSS%}">
<link rel="stylesheet" href="{%CUSTOMER_CSS%}">
<script src="{%STANDARD_JS%}"></script>
....

Another approach would be to provide the customer with an online thru-the-web editor. You might want to have a look at some of the mash-up tools available, e.g. Radria.

HTH

C.

symcbean 2010-05-24 11:42:13

Answer 3

+1 A:

You may find it helpful to take a look at the TinyButStrong templating engine. TBS differs from most other templating engines in that it doesn't try to implement an additional scripting language inside the template, but uses a system of place-holders plus attributes which are cleanly separated from the HTML code between square brackets, such as

[blk.myfieldname;block=tr]

This makes the system extremely straightforward to use with WYSIWYG tools such as Dreamweaver, as it's very easy for the designer to see where the PHP dependent code is in the template - basically 'don't touch anything inside the square brackets'

Although not quite in the same situation as yourself I've work on several projects where I've completed pages to be fully functional with a basic layout, then handed the HTML templates (+css) over to the designer who's subsequently modified them for the final site. Because of the clear separation of code and place-holder variables that TBS offers there's little to go astray with the approach. The lack of any template scripting language also means your security concerns are much more controlled.

Cruachan 2010-05-24 12:18:32

Hi! That looks supersweet! Definitely will check that out. It will certainly save time! Seems like it's quite lightweight as well!

Industrial 2010-05-24 12:26:38

@Industrial - TBS is absolute magic, in fact it's possibly the main reason why I still create small sites in PHP. I've picked up and modified other sites for clients using Smarty, vLib and other template engines and none of them come anywhere close in terms of elegance and clean, maintainable code. As you observe it is indeed extremely lightweight, but at the same time I've never found something it can't do that I've needed in hundreds of pages created with it. Most of the time you need very little of the codebase - but there's significant depth there to back it up when required.

Cruachan 2010-05-24 12:52:56

Great stuff, this far it really looks as magical as you say! Is this the proper way for loading sub-templates? "[onload;file='menu.htm']" ?

Industrial 2010-05-24 20:39:21

ansaurus

tags:

views:

answers:

Template approach for a PHP application

related questions