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.

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