A Complete List of PHP Template Engines?

Anode - Yes, I’ve read Harry’s article :slight_smile: I know Sablotron is redundant in PHP5 and since this new PHP version will have for the most part all the required XML (and related technology) built in this is all great etc.

I was though referering to PHP4.2.x and above ? Should have made that more clearly now, so sorry about that :wink:

But could a templating engine be done though that will actually work okay on a production site… ?

Can’t help it (it’s addictive once you get started)

  1. FastTemplate Clone - drop in replacement for FastTemplate.
  2. PHP-Service
  3. PHPTempt
  4. Quick Template
  5. Sledgehammer
  6. Server Side Template Parser
  7. Vanilla Object Oriented Templates
  8. vBulletin - has it’s own template langauge

There’s at least another ten over at phpclasses not in the list yet…

Makes you wonder what would happen if they were all integrated into one. :slight_smile: Maybe someday life will be that simple!

I don’t think that’s the key. I think the key is having a template engine that does what a specific proect requires it to.

I have my own web template phpObjects.WebTemplate though haven’t created a dedicated page though …

What about your simple one Harry? :wink:

I found an interesting one the other day… I can’t remember the damn name of it or URL of the site though. >_<

I use smarty, it’s basic like what phpBB uses.

Here’s another higher-end template forum:
63. Invisionboard

What about your simple one Harry?

The latest incarnation is listed up there - http://simplet.sf.net

  1. ATemplate
  2. ctlTpl
  3. hierarchy template
  4. InTemplate
  5. lorenphplib_patternizer
  6. MyTemplate
  7. Path Wrapper
  8. phpoot
  9. Smart Template
  10. Templato

There’s a bunch I’ve skipped which are all called just Template or similar which are too much effort to distinguish.

I have my own web template phpObjects.WebTemplate though haven’t created a dedicated page though …

Think I need to specify that it has to be available online either as a demo or available for other people to download.

Well this list is touching 75 almost … wowhuu …

Well, you can see, it in action at various sites like digitalAmit, [url=http://www.sbpagra.com/]Sbpagra, etc …
but there is no download page as such … might be in a week ot two :slight_smile:

for PHP version 4.3.x, The short answer is an emphatic NO!

I can’t remember the exact problems I had but there were some really basic things that it could not do. At worst, this just lead to some strange behaviours which would really mess with your mind if you were an XSLT newbie. XSLT is hard enough for programmers used to imperative programming (ie. PHP) even when you do have a solid XSLT processor such as Sablotron.

Don’t use DOM XML’s XSLT on a production site.

You can stop waiting around already. “Life is already that simple”. A single industry standard has already been established for some time now. It’s called XSL-Transformations here is the W3C site.

version 2.0 of the standard has already reached “Working Draft” status.

If you commit to learning this one single templating system, not only will you find more support for it in PHP, but you can use it in ANY other modern middleware platform - be it Java, .NET, or ASP(v3).

Furthermore, you can could use it on the client-side in situations such as intranet apps where the user-agent is monatomic. Both IE and Mozilla-based browsers (Nav7) support it.

What are you waiting for?

It ain’t an web industry standard until you can edit it in Dreamweaver. :slight_smile:

I don’t consider XSLT to be a template language.

I interpret this definition to mean that a template for an html document has to itself be an html document (mostly). XSLT fails this test.

XSLT can be used to implement the Transform View pattern this is not the same thing as a [URL=wact.sourceforge.net/index.php/TemplateView]Template View.

Oh, BTW. The unabridged American Heritage Dictionary rocks! Get one.

It just so happens that the HTML template you are talking of is not held in the outermost container (as your definition seems to require). XSLT is more sophisticated than that. Typical XSLT templates for HTML templates define the general HTML packet in the “root” template. And since all XSLT templates exist inside a <stylsheet/> container, the HTML is not outermost.

This for me does not detract from it’s status as a templating system. In other words (to use an American term) - “ain’t no thang”. [ed. not taking the micky. I like Amarican slang]

Also, I do no subscribe exclusively to the MVC pattern for contemporary client/server applications development. So the concise definition of the “template view” (in the context of MVC) is somewhat less important to me.

I think definitions of “what a template is” are subjective. However, I have much stronger opinions on using templates for applications in today’s environement. Issues like re-use(in the context of code normalisation) and interoperability are at the fore for me personally as a developer.

On the DW issue, I’m not interested in one particular product’s support (ie. dreamweaver - even though I think dreamweaver is itself an excellent product for what it does). If someone brings out a new XML technology that is useful, I’m not going to wait for Altova (of XML Spy fame - including XSLT [WYSIWYG] designer) to implement it before I use it.

btw. I thought your article at http://wact.sourceforge.net/index.php/TemplateView on the topic was most educational despite not agreeing with it 100%

There seems to be a great deal of misinformation and mostly lack of appreciation for XSLT. The was some guy on comp.lang.php who was crying about it because “you need to prepend everything with xsl: and that’s just a pain” (I didn’t even justify it with a response). There were other people making equally inaccurate assertions about using XSLT. This demonstrates a fundamental lack of understanding amoungst web developers in general. It seems that too many web developers are too tired to keep up with standards. Yet they spend precious energy learning a new templating system which may only be transient at best.

I chose XSLT as my templating solution because I am fundamentally lazy. I only want to learn one type of templatig system where I can build up a library of templates and use them accross a broad range of projects - including ones that aren’t done in PHP.

I remember developing websites in the mid to late 90s and experiencing first hand the problems that modern standards have worked to overcome. WHY GO BACK?
At the time, myself and many other web designers/developers struggled with different user-agents causing us more work (having to maintain different versions of highly functional sites for different browsers). It was a standards implementation problem. Since then, standards have evolved and adapted to become immune non-standards based clients (in our client/server environment)(1). “All template developers are doing now is moving the problem onto the backend.”

I USED to use PHP for it’s templating capabiity (ie. I could mix literal HTML markup with <?php … ?> functional bits. Other technologies sprang up using the same principle to gain success - most noteably Cold Fuison, ASP, and more recently, JSP. However, as my PHP skills have improved, my appreciation for PHP as a purly useful scripting language has deepend. It’s ability to parse templates is much less important to me. Now I use it for it’s “out-of-the-box” high degree of functionality. I can even organise my code in an object oriented manner without the overhead of dealing with a [so called] fully-blown object oriented technology such as Java or C++. I’m going to conclude this paragraph by stating catagorically that templating methodologies that formed the basis of PHP, JSP, ASP are obsolete - they are now the “wrong” way to go.(2)

I must stress though that his is a recent phenomina that is due entirely to the maturity of XML and surrounding standards. No matter how good your proprietary template system is, it’s not much use to me as a developer. As a developer, I only want to learn one templating system and I want to learn is well! I also want this templating system to have enough depth so that given enough knowledge, I can achieve almost anything with it. And since the XSLT specification is driven by a signifigant standards body, it will constantly be improved for the forseeable future.

Getting down to the individual aspects. First let me say that the article at http://wact.sourceforge.net/index.php/TemplateView very well worth the read. The author has obviously done a bit of research and it shows. Eventually he goes on to explain why his particularly templating solution is so good (using markers). This markers approach as briefly touched on by Harry in http://www.phppatterns.com/index.php/article/articleview/8/1/2/ . But by Harry’s own acknowledgement, this method is tightly coupled(3) between the domain of display and the domain of content aggregation due to the fact that it’s the backend programmer who has to provide all the new widgets. I don’t care how good the rest of it is, this alone as a fatal flaw. By contrast, XSLT fully (and I do mean 100%) separates the job of producing the content from the job of arranging the output (in our case, usually HTML markup). XSLT Designers can easily create their own widgets using templates (named or otherwise). Furthermore, they can continue to use those widgets on their .NET or their JSF (Java Server Faces) applications. I’m not even gonna get into the benefits of hiving off the transform work onto the client (I avoid this due to the old “standard implementation” problem).

Then there is the issue of pumping mental energy into learning XSLT. Make no mistake, XSLT can be difficult. Sure, it’s easy to do your basic hello world stuff but once you start dealing with real-world problems, you have to stoke the fires for your brain to keep up sometimes. But as I have experienced, with practice, life becomes very easy for XSLT design. I think one of the reasons it was difficult for me personally was because as a PHP programmer, I’m too used to imerative programming. Learning to write templates declaratively was half the battle. It’s just different. I had to get over this different way of thinking which was tough for me. Part of the problem with attacking XSLT design with an imperative approach is that you try to use XSLT’s imperative “bits”, like the built in functions, too much. After some practice, you will get better at separating the display logic out from the content logic and you rely less on things like XSLT’s inbuilt functions. It’s the same story with the other imperative bits of the XSLT language such as <if/>, and <choose/>. At first these are awkward but you learn to use them less - not because they are a pain, but because functionally, your problem is solved better taking advantage of the declarative nature of the language. Another problem I had trouble getting my head around was variable (or parameter) scope, again, I was approaching the output declaration wrongly. Getting this right takes time and is hard for me to explain. Obviously for me, the investment of my energy into learning XSLT has been well worth the effort.

What about graphic designers? If it’s hard for seasoned programmers, what hope do they have?
Firstly, graphic designers don’t have the problem of having to force themselves to stop thinking imeratively. So the declarative nature of XSLT is actually more natural for them to pick up. You’d be surprised how quickly some graphic designers can learn XSLT.
Secondly, because XSLT is a standard, there will be more and more software like Altova’s XSLT designer wich will allow WYSIWYG template development.

My real life experience with PHP, XML and XSLT?
It’s been less than ideal(4). I had to create my own PHP library to make the experience less painful (5). Right now I have a perminenet job which involves mostly PHP application development. For the last nine months I’ve had a production application running on PHP which is a pure XML/XSLT application(6). Not only is it running on the windows version of apache 1.3.x, it’s also relying on PHPs DOM XML extension. The site has been quite busy and we’ve never had a crash. I haven’t even had a chance to implement any form of caching yet! Anyway, the point is that the technology is here and it is useable today.

I can speculate on a number of reasons why good PHP developers are still ignoring the XML/XSLT combination dispite it’s maturity.

  1. It’s different. XSLT is different, it uses declarative thinking, not imparative thinking.
  2. FUD - there is a lot of misinformation being peddled by people who have only meddled.
  3. There are more non-standards template solutions for PHP then there are standards (XML/XSLT) based solutions. I think this is more for reasons of legacy since PHP has been around since before XML. I haven’t used it yet, but I think Krysalis offers a standards based solution ( http://www.interakt.ro/products/Krysalis/ ).

My recomendation for developing modern websites:

  1. Come up with a vocabulary that encapsulates what you are trying to say - an XML schema. This can be can be informal, you don’t have to learn schema definitions, just decide what tags/attributes (and their general relationships) you will use as a minimum. This can be an on-going thing, don’t worry if you’ve left something out for later. I’m no XML schema expert [yet] and I can successfully build functional applications in XML.
  2. Work out which objects (roles and responsibilities) you will need (DON’T use functional decomposition). Then build XML accessor methods on the appropriate classes so they can provide their content using your XML vocabulary.
  3. build some XSLT templates which will provide suitable output for your needs. Better still, get your interface designer to build them, notifying them of your XML vocabulary/structure.
  4. find a framework (like Krysalis) or work out some other convenient way to perform the transformation on demand. (this is the hard part at the moment but I hope my XAO library will ease that process).

This is only the begining, but it’s enough for most basic applications. Solutions can really scale from here.

I hope to release my “XML Application Objects” library soon and then I hope to get more PHP programmers to use OO and XML/XSLT. XAO is not a framework - you can use it as one if you like (You can implement a controller). It was designed not to “intrude” on your OO design. It’s just a library to help make the mundane work of managing transformations (and hopefully graceful exceptions) easier.

While this is turning out to be a very large post, I may as well recommended books:

  1. “XSLT 2nd Edition: programmers reference” (Michal Kay). Don’t try to read this, just use it as a reference - trust me.
  2. “XSLT and XPath: On the edge” (Jeni Tennison). This is more like a cookbook, but more than a cookbook.
    If you join the XSL mailing list at http://www.mulberrytech.com/xsl/xsl-list you will find that both of these authors are fairly active on there. The sort of support provided there would be worth heaps commercially - couldn’t ask for better!
    If you’re a newbie and want to learn XSLT, I recomend using the web. Sites like http://www.zvon.org/ and http://www.w3schools.com/ are good places to start.

FOOTNOTES:
(1) I am NOT talking about HTML or even XHTML!

(2) Clearly, I am refering to their usage as TEMPLATES, not to their usage in general. I plan on porting a library from PHP to Java using JSP as entry points to the application the same way .php pages provide entry points to most PHP apps.

(3) Tight coupling is bad™. Tight cohesion is good. Loose coupling is good. So from a design pattern point of view, proprietary marker based templating solutions (while better than most) are still bad. See the Addison and Wesley “Design Patterns Explained: A New Perspective on Object Oriented Design” book by Alan Shalloway and James R. Trott on page 8 (yup, right at the beginning of the book).

(4) Mostly PHP’s terrible error handling was to blame here. This aspect alone makes it difficult to handle exceptions in an XML context.

(5) The library that I am developing is not yet fit for release (aside from the fact that PHP might/will change the behavious of the DOM XML extension). I need to re-factor the design and do some more testing. I’ve developed the library in my own spare time on a test project (pure XML photo album software with no need for an RDBMS). It is not a framework because it does not call the developer’s scripts. Using a controller(MVC) is up to the developer - centralisation is achieved through inheritance. I think I’ll ask around here for opinions on whether or not I should submit it for inclusion in PEAR. I actually came up with a light-weight MVC controller which I used in the application successfully but it was entirely procedural so the design was limited. It was always my intention to move to a 100% OO solution.

(6) No, it’s not using the XSLT functionality from the DOM XML extension. As I mentioned in a previous post, this would be a really bad idea.

I’m going to slightly contradict what I said in the last post about avoiding client-side transformations. Parity between Mozillas and IEs XSL processor is very good. As yet, I have never come accross any stylesheet which does not transform identically by the two. This is due to the fact that the underlying XSLT processor’s support for the standard is pretty much spot on in both cases. Learning lessons from the past, the XSLT standard allows propper extension points for vendors to supply proprietary (value added) functionality. That means people like you and me can develop stylsheets which use only standard features to produce whatever the hell markup we like (such as XUL, IE-specific DHTML, WAP decks, or PDA optimised XHTML).

So am I right in saying you like XSLT? :wink: Great rant which deserves an extended answer unfortunately time is short.

There’s things I like about XSLT but in the name of debate, will concentrate on what I don’t like.

  • Not sure I’d call XSLT entirely declarative. XPath has a very imperative feel to it but seems to stop short of actually giving a programmer what they need. Of course that could be me as you say - I haven’t developed my skills to fluency.

  • XSLT adds extra complexity - that’s a big one. With PHP and XSLT in Krysalis (or Apache Cocoon which Krysalis is based on) you might have;

DB > PHP [Data Access] > XML > PHP [Business Logic] > XSLT > PHP [Presentation Logic] > XSLT > XHTML

Ignoring potential performance issues, dealing with XML and XSLT gives me more work to do. A well constructed framework, like Krysalis, can protect me from it but I’d rather have;

DB > PHP [Data Access] > PHP [Business Logic] > PHP [Presentation Logic] > XHTML

The XML / XSLT aspect seems to introduce more areas that can go wrong. My guess is it also reduces flexibility; certain tasks become extremely difficult but perhaps that’s the hacker speaking.

Bottom line, by way of analogy; ideally I’d like to avoid even having to deal with SQL in PHP - rather have a library I trust that gives me an API for generating SQL.

  • In theory it should be possible to rendering XHTML, WML, SOAP or any other XML-like format by simply adding new stylesheets on top of your business logic.

In practice none of these formats are “symmetric”.

A WML based UI will be so different from from an XHTML based UI that you’re probably end up needing to define different “controllers” to deal with it plus probably needing to “shape” the underlying business logic to what you need.

SOAP will definately require new business logic; SOAP API’s need to be coarsely grained and and make as much data as possible available per request because each SOAP call comes at the cost of the underlying network.

  • Does it improve the speed at which applications are developed? My own experiences say no but then perhaps a decent framework (Krysalis) or API such as you’ve developed change than picture.

One more for the list of templates;

  1. [http://extemplates.narod.ru/]ExTemplates

Well there are some things that I like about using the technology, but given enough time, I could do a rant just as long about things I find irritating using XSLT. What I like is the fact that it is only ONE templating system that has to give me irritation. Once I learn to deal with that, I can use it everywhere standards are used! I have to say, I really didn’t like XSLT for a long time (due to my lack of understanding of it).

Let me be quick to point out that if XSLT 1.0 was perfect, there would be no need for XSLT 2.0. As it happens, XSLT is a standard so there is a good chance that it will continue to be improved on it’s shortcommings.

Glad to here it. Gives me the opportunity to explain some common grieviences raised with XSLT.

Too right. Like most useful technologies (ie. PHP), it’s a little bit of a mongrel breed. While it is fundamentally declarative, it incorporates XPath which as you point out, it more “functional” than declarative. The <if/>, <choose/> and <for-each/> directives are most definately imperative. XSLT is certainly not a “pure” declarative language. These are almost supplementary features which can be best described as “weak”.

XSLT does indeed add another layer of complexity as indeed does any other templating option. Basically if you have chosen to use a templating system, you have already chosen to add another layer of complexity - so now you need to learn all about your chosen templating system. It really is only a matter of choosing between making that effort count in the long run, or frittering it away on some proprietarily restricted system.

I really should get around to evaluating Krysalis so I can make intelligent discussion about it. If indeed it implements the pipeline you’ve outlined above, then I have to agree that this is a level of complexity your application doesn’t need.

Here’s how I do XSLT in an RDBMS driven scenario.

DB > PHP [Data-Access / Business-Logic] > XML[DOM] > XSLT [presenation logic] > XHTML

Now considder that XML provides the opportunity (in limited circamstances) to provide mass storage for your data which is superior to an RDBMS (depending on the structure of your data). For instance, a pure XML database like Xindice ( http://xml.apache.org/xindice/ ) or a flat file (under even more limited circumstances).

XMLDB > PHP [Data-Access / Business-Logic] > XSLT [presenation logic] > XHTML

You’ll notice that each of the layers here are not repeated and each provides abstraction. So youre abstraction to layer ration is at it’s highest.

Applications really should not be more complicated than this.

Given my last two pipeline examples, there is no more work to do than what you are proposing here. In your example, you still have to go to the effort of learning the workings and syntax of the proprietary system (denoted here as “PHP [presentation logic]”)
There’s no difference in the amount of layers in your application and the amount of technologies. The fact that “PHP [presentation logic]” is using PHP as it’s underlying technology doesn’t reduce the workload, the syntax introduced by the proprietary template schema is a technology in it’s own right - which may or may not be simpler.

Again, no more points of failure exist than with any other proprietary templating system. If I decide to use smarty, I’m still introducing another place where something can go wrong. I don’t understand this pervasive perception that other proprietary systems are somehow immune from being regarded as extra work and extra complexity yet somehow XSLT is. It’s one of the reasons I feel I need to adopt a soap-box mentality with discussing these issues in order to “fight the FUD”.

As for flexibility, XSLT offers just as much added flexibility as you’re average proprietary system. Maybe sometimes more, maybe sometimes less, the fundamental issue is really no different. In my understsanding, extra layers of abstraction always add flexibility (otherwise, why would you introduce them?) and on the flip side, they always add another point of failure (the down side).

Getting back to the basic reason for adding abstraction; “Requirements always change”. In other words “Requirements always change”. Or let me put it another way, “Requirements always change”. So better to have layers of separation so that implementating change doesn’t have a domino effect of your modules. Introducing change into your code is the most common source of bugs, and they are the bugs of the worst kind - the hard-to-detect ones. Abstraction layers provide bondaries that stop these domino effects from propagating if implemented properly (using a black-box approach). ie. bugs in the business logic don’t propagate to the display logic and vice versa. “loose coupling” and all that…

That’s doable but you’d end up replacing one layer with yet another. Just because it happens to be coded in PHP doesn’t mean it’s not a new technology that brings with it a new set of responsibilities (effort).

Boooh!
You’re mixing buisness logic with formatting :slight_smile:

I’m not sure what you mean. Do you mean in the context of “bi-directional”?

Glad you brought this up :slight_smile:
This is a question of design. Your XML packet (or any outgoing payload for that matter) should only take into account the data that a request should recive. If you’re taking into account things like the interface, then your display logic is not 100% abstracted as it should be. IT SHOULD MAKE ABSOLUTELY NO DIFFERENCE WHETHER OR NOT MY REQUESTED PAYLOAD IS DESTINED FOR A DECK OF CARDS (WML) OR A SINGLE WEB BROWSER PAGE (XHTML). If the display logic needs to do things such as slicing up content into ergonomicly appropriate chunks (cards), then the XSLT display logic can handle that. As for proprietary templating systems? well, that probably depends on which one you use as to whether this sort of capability is even supported.

Another example of this is a user having to page through result-sets, say, from a web search engine. While the result list is constant, you could use XSLT to display multiple pages limited to $n results at a time. This could be highly effecient, especially if your user-agent is detected to be XSLT capable. In terms of efficiency, you can abstract the task of improving that to the server side. So if you have a billion results, you could use a cursor to retrieve 1000 at a time and get the UA to make a new request every finishes paginating through it’s last requested block of results. The number of pages per repsonse packet block may vary according to anything from UA capaciy (ie. a 5 line phone display) to user preferences. In this case you are making decisions about the optimal granularity totally independantly of the user interface.
Even when the transformation is totally (or partially (conditional upon the UA)) server-side, there are performance enhancing opportunities just like with any other templating system. You can cache at two levels, you can cache XML payloads, and you can cache transformations. There is easily just as much flexibility for performance increases as there are for proprietary systems such as smarty.

Don’t even start me on the advantages of using C based processors for your XSLT transformations as opposed to interpreted PHP code (without the availabilty and disadvantages of pre-compilers).

Ah yes, SOAP is high-latency due to trully massive protocol overhead - not helped by the rather inefficient encapsulation inherent in XML encoding.

See, not even an evangelist like me thinks that XML is perfect.
:wink:

I live in hope.

I know that you are not alone in finding XML/XSLT applications development in PHP to be combersome. Until I developed my skinny controller (now deemed by me to be obsolete), debugging XML/XSLT from PHP was a complete and utter nightmare. However, including a debugging subsystem in “skinny” actually made it EASIER to debug than in non-XML/XSLT apps because I could debug my business content and my display logic separately.

From now on, I’ll make a commitment to spend less time talking about it on a forum, and more time developing a decent XML/XSLT library for PHP so that I can prove that “the standard way is the better way”.

I’ll be calling on the expertise in this forum for help on the OO design.

<sighs>

Oh crap. midnight again :frowning:
I’ll come back and edit this post for typos tomm.
I’ll also post an example of how I’m doing things for the moment.

[size=2]I have to disagree with this testament, whole heartedly.

XML, XSL(T), HTML, XHTML…

Each markup language mentioned are as a whole a template or have a defined schema, whether the output of the templates state changes after being processed is of no relevance. As mentioned a ‘[/size]A document or file having a preset format, used as a starting point[size=2]’, is exactly what occurs, when you use XSL(T); 1. you have a preset format 2. you have a starting point… [/size]So essentially with that statement, your contesting against all these so called templating systems(TS).

[size=2][size=2]Secondly, anyone in their righteous mind would employ, some form of lucrative caching mechanism, in order to save resources. Dutifully there are an abundance of problems, that do occur with this, however this is entirely dependant on your methods of caching and whether it is best adopted to your audience.

[size=2]I have to agree with Tezza on numerous matters brought to light, which have plagued the web (and numerous corporations). With XML you at least have a conform~ative way of abstracting data, instead of spending rediculous amounts of money on getting people to input data, from legacy systems.

[/size][edit][/size][/size]
more to say, rebooting.
[/edit]

Just on tip off - there’s a good Krysalis tutorial here [PDF] which explains the architecture then goes into detail on using it as a SOAP server. Was a chapter Wrox’s (RIP) PHP Web Services book.

Crudely worded “on top” - I meant apply a new stylesheet at the presentation logic layer “on top of” existing business logic.

The notion or “symmetry” is the idea that all content types rendered by the presentation logic are essentially equal. In practice though, I don’t think that’s true. Sure they’ll all have elements in common but my opinion is the only two content types that are really symmetric are HTML and XHTML.

To deal with WML, for example, the “controller” MVC will likely need to perform quite different operations. First you’ve got session which will need to be passed via the URL rather than as cookies. Then in designing your UI, there’s a good chance you’ll need a very different user navigation system than with the (X)HTML equivalent. That’s just for starters.

The point is I don’t think all this can be handled simply by using a different stylesheet applied to the same XML document.

for PHP version 4.3.x, The short answer is an emphatic NO!

For < PHP5 I’m not even going to comtemplate this idea myself now that I’ve had more time to look into it and think about it :smiley:

Like you say Tezza, it’s just a multiple version nightmare just waiting to happen :lol:

Thus I’ve downloaded PHP5, latest build and as soon as I can get this up and running I’ll be using PHP5 solely for this idea I put on this post - a lot more stable and robust.

That and a point I made in a PM to another member I think PHP4.x.x will quickly drop off once a stable realease of PHP5 is available and I can seriously see that the web hosts will grab every chance they have to move over to PHP5 very quickly - there is going to be an incredable demand for it I believe ?