eZ override - which settings?

Siteaccess and overrides are almost too much to comprehend on top of all the other "stuff" when getting educated about eZ. Reportedly, learning eZ is much simpler today than in the past, but learning is still more of a cliff than a curve. Hopefully this site goes some distance toward changing that. At least in terms of being immediately productive with eZ.

Ini files set up the basic parameters for most open source softwares. Ini files in the standard sense of the term are in the /settings folder, a more or less standard location for ini files.

Ini settings are applied in this order:

• /settings/ *.ini When applying settings, this is the first place searched, about 50 files, covering about 50 things that eZ Publish does. Specific sitewide settings like where to store files, permissions settings on files, image handlers,so on. If there are no additions or corrections in the next levels, these become the final settings. Setup.ini typically begins and ends here. Site.ini typically begins here and is altered at each new step. Systematically reviewing [SiteAccessSettings] in each site.ini file at each level is educational.
• /settings/siteaccess/<named siteaccess>/ These settings will add to or override the above files, to set more specific site parameters. Usually a site.ini.append.php, and usually a few alterations to the [SiteAccessSettings] configuration.
• /settings/override/ - a final place to potentially make changes sitewide again. Why again, if already set in step one? Applying a universal setting to all the siteaccess settings from step two is one reason. The ability to turn on and off a complete siteaccess is another. Reviewing the [SiteAccessSettings] in the site.ini.append.php file at this level gives some idea of the possibilities.

The way eZ does it, switching the entire site, or one specific siteaccess to a different database require a few lines in an ini file. Do that with any other CMS!

Switching the entire appearance of the site, based upon the user agent string sent by the device requires only ini files and CSS that apply to that specific way of accessing the site content.

The eZ developers have applied the popular DRY (Don't Repeat Yourself) coding principle to CMS software.

Building out similar customizations with just about any other CMS software is a lot of copy and paste, and a lot of places to make changes every time the site needs to be changed.

The eZ way makes perfect sense, once you understand it, but it is so different from existing paradigms that understanding the concept can be challenging for first timers accustomed to copy and paste.

An iPhone user logically will need some different style sheets and such than a computer monitor.

The old way:

• set up a new site (copy and paste files)
• change the files that need to be different, the CSS and such
• watch for a user agent string of iPhone
• redirect iPhone users to that site

Using eZ Publish and siteaccess:

• create a siteaccess containing the CSS and such for the iPhone
• watch for the user agent string telling you an iPhone is browsing your content
• override ini files to make the site appear the way it will look best on the iPhone

Not much difference between the two, a little higher storage requirement and potentially two places to make changes every time the site needs to be updated. A 1X2 system.

Where eZ and the override system really starts to shine, is when tailoring yet one more way to access the site. An admin interface, a partner interface, a browser specific interface, each of these requires only the customizations, nothing else. A 1X6 system only requires the files and settings for each of the 6 customizations and is little more difficult to administer than a 1X2 system, because nothing is repeated.

The eZ override system makes tailoring, changing, and administering site tweaks or even adding whole new sites simple.

Admin interface to help in understanding the effects of ini settings, Admin->Setup->Ini settings..

Just the applicable docs. http://ez.no/doc/ez_publish/technical_manual/3_6/concepts_and_basics/configuration/site_management

An example, albeit in old documentation.

http://ez.no/ezpublish/documentation/building_an_ez_publish_site/creating_the_tscm_site

"eZ publish reads the configuration files in the following order:

1. Default configuration files(/settings/*)

2. Site specific override files(/settings/siteaccess/[sitename]/*

3. Global override files(/settings/override/*)

Configuration settings in (1) will be overridden by settings in (2), which again will be overridden by settings in (3)."