Why to choose eZ Publish CMS as a platform for web projects

Sunday 13 March 2011 8:35:59 am - 5 replies

Introduction

As an eZ Publish developer I am often asked to explain why we as a company work with eZ, why have we chosen eZ in the first place and why will we continue to work with it in the future. So I will try to summarize our reason. Dear reader, feel free to contribute with yours.

» Read full blog post

5 replies

Author	Message
H-Works Agency	Thursday 24 March 2011 12:51:39 am Hello, eZP is great, its true it can solve an impressive diversity of client's requests through its data model and extension features. In the other hand i cannot agree with your next two assertion : - Upgrade process is a nightmare and should be totally automated...i know what i am talking about after a 20 sites migration from 3.x to 4.x. Automation with dependency checking should happen for kernel & extensions (distrib & community). - eZ override system is great and i discover every day the power of this feature. But its not clear : Loading order for design & settings have to appear somewhere in the debug - without loading unmaintainable extensions. When you load a setting extension stack on your website its very time consuming to find out why a certain variable is not correct because your extensions's loading order is wrong. Cheers ! EZP is Great
Nicolas Pastorino	Thursday 24 March 2011 1:41:56 am Quick 2 cents : for upgrades, http://projects.ez.no/ezupgrade is a must-try solution. Very impressive results, event on complex integrations like projects.ez.no. Cheers, -- Nicolas Pastorino Director Community - eZ Member of the Community Project Board eZ Publish Community on twitter: http://twitter.com/ezcommunity t : http://twitter.com/jeanvoye G+ : http://plus.tl/jeanvoye
Ivo Lukac	Monday 28 March 2011 12:41:30 pm " Hello, eZP is great, its true it can solve an impressive diversity of client's requests through its data model and extension features. In the other hand i cannot agree with your next two assertion : - Upgrade process is a nightmare and should be totally automated...i know what i am talking about after a 20 sites migration from 3.x to 4.x. Automation with dependency checking should happen for kernel & extensions (distrib & community). - eZ override system is great and i discover every day the power of this feature. But its not clear : Loading order for design & settings have to appear somewhere in the debug - without loading unmaintainable extensions. When you load a setting extension stack on your website its very time consuming to find out why a certain variable is not correct because your extensions's loading order is wrong. " - yes, we had issues with upgrades too. Mostly crossing from PHP4 to PHP5, but we know a lot of stories from other CMS on how they have upgrade issues, so these kind of issues are minor comparing to those - we had some issues with extension order too :) but generally it works ok (we internally have set up procedures so the issue does not happen) and that is being worked on lately AFAIK. I agree that documentation should be more clearer. http://www.linkedin.com/in/ivolukac http://www.netgen.hr/eng/blog http://twitter.com/ilukac
Gaetano Giunta	Tuesday 29 March 2011 1:22:39 am About extension ordering: since version 4.4 extensions can specify their dependencies, which leads to a correct loading order, automatically calculated by eZ. Little by little, we improve... ;-) Principal Consultant International Business Member of the Community Project Board
Ivo Lukac	Tuesday 29 March 2011 1:27:43 am " About extension ordering: since version 4.4 extensions can specify their dependencies, which leads to a correct loading order, automatically calculated by eZ. Little by little, we improve... ;-) " So didn't get it wrong when I wrote: "and that is being worked on lately AFAIK" :) http://www.linkedin.com/in/ivolukac http://www.netgen.hr/eng/blog http://twitter.com/ilukac

You must be logged in to post messages in this topic!

eZ debug

Timing:	Jan 30 2025 01:02:50
Script start
Timing:	Jan 30 2025 01:02:50
Module start 'layout'
Timing:	Jan 30 2025 01:02:50
Module start 'content'
Timing:	Jan 30 2025 01:02:50
Module end 'content'
Timing:	Jan 30 2025 01:02:50
Script end

Main resources:

Total runtime	0.0119 sec
Peak memory usage	2,048.0000 KB
Database Queries	3

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0041	588.3906	151.2422
Module start 'layout'	0.0041	0.0018	739.6328	36.7188
Module start 'content'	0.0060	0.0046	776.3516	102.6406
Module end 'content'	0.0106	0.0014	878.9922	37.9766
Script end	0.0119		916.9688

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0021	17.3211	14	0.0001
Check MTime	0.0009	7.9226	14	0.0001
Mysql Total
Database connection	0.0006	5.2265	1	0.0006
Mysqli_queries	0.0020	16.3704	3	0.0007
Looping result	0.0000	0.0679	1	0.0000
Template Total	0.0010	8.7	1	0.0010
Template load	0.0008	6.8262	1	0.0008
Template processing	0.0002	1.8014	1	0.0002
Override
Cache load	0.0006	5.0268	1	0.0006
General
dbfile	0.0010	8.3180	8	0.0001
String conversion	0.0000	0.0340	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded	Edit	Override
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 1 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs