eZpublish for commercial website deployment. (gripe)

Thursday 15 December 2005 7:25:46 pm

<b>This is not criticism, rather notes regarding my concerns with eZpublish deployment as a stable business solution...</b>

After working with eZpublish for about 5 months now I'm actually very worried about the system's integrity. If there are so many bugs and problems during development how can I trust it for a corporate website or more to the point, many corporate websites?

<b>I honestly have a feeling my indemnity insurance is going to get a workout over the implementation of the eZpublish system for corporate websites.</b>

I feel as though I'm working with a very unstable system and thats not what the advertising on the home page would suggest? I don't think one of my clients in particular (the one who paid for the pro licence) will be too happy to find out the system that "we" recommended (due to clamed stability, features and abilities) is buggy and unstable, hence my indemity fears. I also fear that the reputation of eZpublish is going to crash and burn in a big way if eZsystems continue to release patched but still buggy updates.

I love the power and flexibility of the system but development time is cursed by bugs and overly complex templates, it really shouldn't take 2 months to develop a simple website on a system that calls itself <b>eZ</b>... After 5 months I feel I'm coming to terms with the template code but I can't stop wondering "why do I have to repeat myself (code) so many times?"

Some of the major issues we have faced in the development of our current project (these may be subjective but they have been very annoying issues none the less):

1. Extended development time (over 2 months for a relatively small site).
2. Extremely sluggish performance up to 30 sec page load time (even on a very high end dedicated and customised platform - 2GB RAM, Dual Xeon (dual core) 2.8GHz, 2 x 73GB SCSI RAID 1. plus PHP accelerator configured and optimised solely for 1 eZpublish install).
3. Curious Fatal Errors that seem to have no apparent cause or remedy (there one minute gone the next, etc.).
4. Cron Jobs (need I say more?).
5. Incomplete documentation (documentation lacks good examples and explanations this means more time spent looking for answers elsewhere).
6. Cache system never works as expected (clearing cache from admin still has limitations, not good for the client) (this one has been the bane of my existence).

And many less significant issues...

I don't want to sound like I'm complaining, I use the system because I see its potential, however after developing one site on eZ and 2 more sites to go (planned for eZpublish) I'm starting to see too many flaws in the current system to justify continued use.

This is a shame because we looked long and hard (about 6 months) for a good CMS open source or enterprise, and according to the hype eZ was the CMS that offered everything (and more than) we needed.

Perhaps this is where we made our first mistake, maybe eZ is too powerful for the sites we create, maybe we should have sacrificed some functionality for performance and stability?

As I said this should not be taken as critisism but as feedback from someone who sees a lot of potential in eZpublish but who does not concider it stable enough for commercial deployment, in my opinion eZpublish still needs to come of age! I know I'm not the only one who feels this way but frustration has got the better of me and I had to tell someone;).

I comend the hard work eZsystems have put into this system and I don't want to take anything away from them. I hope they don't take this post the wrong way.

Cheers!

Pardon me while I burst into flames...

Friday 16 December 2005 1:14:29 am

Nathan,

Thanks for your feedback. I'll just comment on some of your comments.

After 5 months I feel I'm coming to terms with the template code but I can't stop wondering "why do I have to repeat myself (code) so many times?"

Could you give an example of what you mean here? It should not be necessary to repeat yourself excessively. The need to repeat code often is caused by a design problem in the site.

Extremely sluggish performance up to 30 sec page load time (even on a very high end dedicated and customised platform - 2GB RAM, Dual Xeon (dual core) 2.8GHz, 2 x 73GB SCSI RAID 1. plus PHP accelerator configured and optimised solely for 1 eZpublish install).

eZ publish could definitely be faster, but this sounds to much. Be aware though that the more complex your templates are the slower the system will be. The best way to solve performance problems is the first check if only some pages are slow or if the site is slow in general.
If single pages are slow, check the debug output to see how many queries etc. are performed. Maybe you can write your code in a smarter way.
If all pages are slow the problem typically lies in the pagelayout. Check how many queries are generated by a standard cached pagelayout. For good performance you should keep it below five queries.

3. Curious Fatal Errors that seem to have no apparent cause or remedy (there one minute gone the next, etc.).

This does not sound good. Are you on eZ publish 3.7? Older versions use PHP 4.3 which has serious problems with references which could manifest themselves as you describe. We did non receive any bug reports about such behavior after the release of 3.7.

4. Cron Jobs (need I say more?).

Yes, please. What problems are you experiencing?

5. Incomplete documentation (documentation lacks good examples and explanations this means more time spent looking for answers elsewhere).

Definitely agree with you here. We have recently hired two new people to work on the documentation. Also, as you can see from the Components documentation is prioritized much higher now than before. Basically we want components level documentation on all of eZ publish when 4.0 is released.

6. Cache system never works as expected (clearing cache from admin still has limitations, not good for the client) (this one has been the bane of my existence).

Could you be a bit more specific? If you find bugs or strange behavior, the best way to get it fixed is to report a bug. This is of course also valid for all your less significant issues.

A bit about the future:
- eZ components (the foundation of eZ publish 4.0) is completely documented and unit tested (take a look at the source code). It is also based on PHP 5 which allows more object oriented and cleaner design.
- eZ publish 4.0 will have all the functionality rewritten to use Components. It will also feature full unit testing of all the library functionality as well as documentation in the same style.
- We will also go through all of the existing functionality and rewrite parts where necessary to a faster and more object oriented design. We will release a detailed document about what we are planning to do soon.

Cheers,
Frederik

Sunday 18 December 2005 5:38:40 pm

Hi guys, thanks for the replies, I should just clear up a few points:

To start I'm running 3.6, I have not used 3.7 yet however I do plan to try an upgrade of the current project before we go live, if that fails I'll use the 3.6 version for the live site (though I don't expect it to fail). The server is Linux Redhat and as I said above its very powerful.

<b>On Speed.</b>

The server in question is provided by The Planet in the US and I'm in Australia, we have used them on a number of occasions and have never had a problem with speed. In all honesty the performance of the site when cached is slow but I'm not the one who needs to be impressed, the client is the one complaining about speed and I have to take any complaint very serious. On this point thankyou for the tips Frederik I'll try to simplify some of my code and I do believe my page layout may be making too many queries so I'll see how I can reduce them.

(I'll just add on the point of template code, the admin area is even slower than the front end; I assume the admin is not relying on the cache system as heavily? And I have not changed the admin templates.)

That said the problem of repeating code might also be a reason for extended load times? However I have found the docs very hard to work with, this is where good examples are needed in the docs, at the moment the docs are great for explaining how to create a fetch function etc., but what is needed is some guidelines of where and how to use them.

The same thing could be said for cache-blocks, I have hardly used cache-blocks in any of my templates because I have not found any good examples of how and where to use them, most of my pages change almost completely from page to page so when I have used cache-blocks I've found some issues with the wrong information in the wrong page etc.

So there are areas in my implementation that could use more work I don't dispute this, but I don't take that responsibility alone, this is still an issue of less than complete documentation as I can only learn from the docs and these forums.

<b>What do I know?</b>

A little about me, and why I chose this system. I specialize in Photoshop, XHTML and CSS, eZ has great support for standards based sites and that was the major drawcard.

I have little to no experience with PHP so I can't build a CMS myself so eZ looked like a great platform to work from. As it turns out not knowing PHP has made the learning curve of eZ a lot harder than I imagined, as some knowledge must be required to understand how the basic PHP factions work through eZ templates.

Also the use or creation of extensions requires a good knowledge of PHP, this makes it personally very difficult to add functionality that my clients request. I never expected eZ to be an out of the box solution, no out of the box CMS can do what I need when it comes to customisation (of design), so the powerful template language is as much a benefit to me as it is a hindrance (due to complexity).

For my first eZ project I did expect extended development time and the burden of lost profits, however it seems I grossly underestimated both of these factors. I expected one month to develop and a loss of approximately 1 - 2 thousand dollars, it turns out the development time will now blow out to over 2 months at a cost to me personally of approximately 4 thousand dollars (I can't blame eZ for this, I made the estimation and I got it very wrong).

This is a major impact on my small business (especially at Christmas time), one I don't want to repeat, but this is what concerns me about using eZ on my next 2 projects (as I said these are already planned for eZ).

<b>On curious fatal errors</b>

This is the issue that prompted my little outburst here (sorry), this post shows two fatal errors that have occurred at close proximity to one another but seem unrelated:
http://ez.no/community/forum/install_configuration/sudden_fatal_error_in_admin_site_unsure_of_reason

The reason this concerns me is that the first error that relates to LDAP happened well into development, I found others who had this problem and discovered I could disable LDAP in the site.ini. The concern here is that LDAP was never enabled on the server, therefore this error should have been present from the very first day of development but it was not? Now I'm concerned about other errors that may be laying dormant in the system waiting for an opportune time to strike.

The second error is current, I cannot access the admin interface at all as of this moment, the concern with this error is that when it occurred I had just logged on to the system, I made one change to the editor user group roles and since then the admin area has been broken and inaccessible. The site was due to go live before the end of this week but now even if this error is fixed I will need to spend more time testing to make sure this won't happen again (unless it is related to 3.6 and an upgrade solves it).

These 2 errors I have posted about but there have been others that have occurred and then disappeared for no apparent reason, therefore there seemed to be no need to post bug reports, as they have not reoccurred.

<b>On cron jobs</b>

No matter what I try there has been no way of running cron jobs via the http methods explained throughout the forums, this is not a major problem with the current project but when I do need to host a client on an Australian server this functionality will be crucial.

The reason for this is that most Australian hosts (or more to the point our hosting partner) don't allow Shell access on virtual accounts. Virtual accounts are the only affordable option for most small to mid sized companies in Australia due to exuberant costs involved with dedicated hosting and even higher bandwidth costs associated with such accounts.

If cron jobs can't be performed in this environment many much needed elements of eZpublish functionality are rendered useless, even reindexing the search engine for example.

<b>On cache management</b>

This was a major issue I had on eZ 3.5 with a purchased professional licence.
http://ez.no/community/forum/general/ez_publish_caching_problems

So much so that I simply could not use 3.5, that project has been put on hold but is due to restart in January, the system was reinstalled with no luck, the cache still did not work. I worked on this issue for over 3 weeks but it was never resolved and has not been to this day, the decision to put the professional licence on the shelf was made as it legally can't be used on any version higher than 3.5.

So now I have a broken version of eZ 3.5 sitting in a box in my top drawer that we were refused a refund for, the possible option of upgrading was expressed by us but as of yet we have never received a reply that would permit this. That version cost us around 6 thousand AUS dollars and is never to be used due to the cache bug in question.

Since then I have had very similar issues with the 3.6 version, I have managed to get it working to some extent however I am still experiencing problems with it such as:
Using the clear all cache button results in content cache cleared but template cache remains.
Clear content cache results in nothing cleared.
Clear template cache sometimes works, usually after three attempts.

Ok so I've complained and moaned enough and I'm sorry if I sound negative about eZ, I don't want to. These issues as you can see have not only cost me time but also a substantial amount of money and to compound my concerns I'm still having a lot of trouble implementing the system beyond 3 deadlines.

The site that we bought the 3.5 pro licence for will be developed on a 3.7 GNU licence now as we have never received permission to develop on an upgraded version. This is a cost it seems we just have to bear, though not a welcome one.

Its good news that the docs are going to get more attention I look forward to seeing some good code examples and explanations. Now if I can just solve these errors I look forward to starting my next eZ project on 3.7, I think there are many mistakes I can bypass in future so I expect my development time to improve.

Cheers!

Pardon me while I burst into flames...

Thursday 02 February 2006 5:04:59 am

We're also struggling with many of the same issues mentioned in the original post. We haven't gone into production with our first ezp project but even at this early stage, we've got serious concerns, including the long page load times. Additionally, ezp seems to be very resource intensive. We're still working on our hardware environment so perhaps we'll get it tuned to an acceptable performance level.

I'll definitely agree with the documentation comment, although the strong user activity on forums can, in some cases, mitigate this issue. I consider the very active and ongoing contributions of eZsystems crew members in the forums to one of ezp's strong points.

I can't say we've found the template coding and extension development to be overly difficult, but we have a bit of php knowledge and I certainly would not say it was 'ez'. That being said, we're still early in the process so I have yet to really do any hardcore template coding or extension development. I do have a question regarding Frederik's suggestion regarding writting efficient template code, he writes

Check how many queries are generated by a standard cached pagelayout. For good performance you should keep it below five queries.

Using a ezp install of a 'plain' site, in both the site and the admin site, I have not found a cached page which is under 5 queries. Most are between 6 and 10. Is it reasonable to set 5 as a goal for newer users of the system when the default templates don't meet this requirement?

We're looking forward to getting these issues worked out and, at this point, have future ezp projects planned. I'll second Nathan's point commending eZsystems on the work thus far. Here's to hoping the goals mentioned in Frederik's post are met and surpassed!