What bugs me most in eZ Publish

Next topic

Author	Message
Wei Dai	Wednesday 18 June 2008 5:10:49 am As a relative new user/developer of eZ Publish, I have found eZ has some very unique styles, or approach to implement a CMS. Even though, I think it meat easy for the users and developers alike, hence it is "eZ", after several weeks reading the docs, I have still left a fair amount questions unanswered. Here is just some I think it bugs me most; they are may not critical for me to build a eZ powered site, but I think it seems so important to get every concepts right before starting implement any eZ Publish sites: 1. what is packages folder under the root eZ Publish folder for? Since it seems like all the package are stored under var/storage/packages. 2. There are additional location for the design folder under certain extension (e.g. the web interface)! This I think if not at all, at least not pay much attention in the docs. An extension as complex as the web interface can include packages, design, modules, settings...; but when install extension, the design are not copied into the main design folder, but as a sub folder under the extension. And, the template override system can recognize the design folder under activated extensions. Why not keep all the design in one place, after all we can create sub folder for each design? 3. Another is also regarding the "un-centralized" configuration file. Since extension can have settings folder which also includes ini files. Will be a time that I need to modify multiple files in different places but I forget one. Will this result hard to find configuration "bug"? 4. I think for a normal person, the "var" folder should not effect some "critical" aspect of the site. This means, even I delete all the content under the var file, my site should still running, and if caches are not exists, just automatically rebuild them. However, this is hardly the case. Because the sitestyle package installed by web interface was linked to page layout template which use ini settings to find the site-color.css and class-color.css file! I don't know if this the best practice. I think this is because in the Admin->Setup->Package, we can install, uninstall, remove packages if keep the package under the var/storage folder. 5.You can't manually directly delete cache also. The var folder is too important I think. 6.Too few good docs and books on eZ Publish which can access by public for free. And I think maybe there need a book on "Learn how to programming eZ Publish Templage Language in eZ Publish". Don't get me wrong, the template language itself is not comlex at all! But, you need have a certain under standing of the eZ system and and object model to because fluid. What default/available variables in what template (the doc only mentioned the variables in page layout template) and so on. Certified eZ Publish 4 developer looking for develop information & collaboration.
*- pike	Monday 07 July 2008 8:20:09 am Hi I can't answer to all your annoyances, but i'll reply to a few. After working with ez for nearly two years, I still have a similar list .. some of these are questions in the order of "why did they end up doing it like this" ? I'm afraid some of the answer will be historical - legacy - growing codebase - running apps - etc .. > 2. There are additional location for the design folder under certain extension (e.g. the web > interface)! This I think if not at all, at least not pay much attention in the docs. An extension > as complex as the web interface can include packages, design, modules, settings...; but > when install extension, the design are not copied into the main design folder, but as a sub > folder under the extension. And, the template override system can recognize the design > folder under activated extensions. Why not keep all the design in one place, after all we > can create sub folder for each design? This is actually a feature I like. Even for less experienced users, I would advice to build your whole site in an extension, right from the start. In the long run, this will give you much more rope to play with - you can eventually add php-logic (modules,views,etc) - right next to your templates. And that makes upgrading an extension, like the "webin" one, much easier. Just replace the old folder with a new one. Everything is in there. In which case, you can reverse the question, ofcourse; why are all those subfolders in the central 'design' folder not just nice, clean extensions ? >3. Another is also regarding the "un-centralized" configuration file. Since extension can >have settings folder which also includes ini files. Will be a time that I need to modify >multiple files in different places but I forget one. Will this result hard to find configuration >"bug"? Same response; I like having the configuration of one extension inside the extension itself. But yes, it does result in the 'hard to find configuration bug' :-) However, you should only add settings specific to your extension inside those ini files, ofcourse - so they wouldn't be hard to find. good luck .. *-pike --------------- The class eZContentObjectTreeNode does.
André R.	Monday 07 July 2008 11:58:44 am 1: Haven't used it but I think it is for placing pre downloaded packages in case you for some reason are blocked by firewall or don't have internet yet on the server your installing on. 4 & 5: Under var you'll find cache folders, both install wide (var/cache) and siteaccess specific (several related siteaccess can share, and does so by default) (var/<site_name>/cache). The content in these can be deleted and it won't affect any thing else but your performance. But it won't actually clear cache if you are running cluster mode, that's one of the reasons why you should use the cache clear scripts as described in the doc. Other stuff stored in var is storage (images and files++) and installed packages. 6: There is a pretty good tutorial in the old documentation that creates a "chess club page" and takes you true most of the basic parts you need to get started. There are work in progress to update it and make it part of the new doc at some point. eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom
Gaetano Giunta	Monday 07 July 2008 1:14:12 pm 3 - it can be confusing in the beginning, but is is extremely flexible in allowing many extensions to add each its own small set of configuration directives. You just need to remember the order in which ini files are read, and it will become quite natural to you to find out where a particular ini setting is coming from. After all, you have basically 4 "folders" to look into: override, extension, sietaccess and default. And if you really cannot find it, there is a handy view in the admin interafce that, for any active siteaccess, will give you the complete view of the current ini settings along with the file where they come from. 4 - var is actually named after the unix way of doing things. The idea is that every file that is likely to be changed by the webserver/ezpublish application has to go in there. It makes easy for tightening down security. /var/cache is actually what you are thinking about when you think about cache. Yes, you can delete it by hand and it will be rebuilt automagically. Just remember to also empty var/yousiteaccess/cache, which serves the same purpose. As a side note, there have been historically some small errors in placing files, such as the /autoload dir containing some files that should have gone under var, and the resized/cropped copies of images uploaded as content that are saved under var/storage instead of var/cache/storage... 5 - see above. Unless you run the eZ clsuetr config, you can 6 - unfortunately true. But the more developers we get on board, the bigger the ecosystem, the more books / blogs / tutorials will be produced. It's a self-reinforcing system. And the latest book "advanced content management" from ez is really good! Principal Consultant International Business Member of the Community Project Board
Piotrek Karaś	Monday 07 July 2008 9:49:19 pm Hello Wei, I'm two years with eZ Publish now, including about 8 months of working with it or around it most of my time. The things that bug me are usually things that I discovered months ago, and they haven't changed that much. Maybe I will share that later (and I already have around the forum). But also with time, I learned to appreciate many things that seemed problematic at first glance. So I would say, experience plays a role here. Now to your points: #2 I believe it's quite the opposite, with particular exceptions, the overall idea behind extension system is really working fine. Delivery of design does usually not make sense without delivery of logic behind it. Also, with projects using 20-30 dedicated extensions, it would not be possible either to control the project or the development, if it wasn't organized this way. Think of reusability of extensions, how would you manage resources scattered around? #3 Again, this is actually how projects can be managed in fairly flexible and safe manner. There is a problem: ini system is not complex and consistent enough, here's more: http://ez.no/developer/forum/suggestions/ini_priority_vs_extension_settings With the rest, I usually agree with other people in this topic. -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu