Get Start a new eZ Publish project
.What is the project about? What we want.
In this article, we are going to set up a starting point of eZ Publishproject, named "Multiline". This project will contain two independentweb sites under the same installation. The two web sites, one of whichwill be accessed via a single domain with language switch betweenFrench and English, and another will accessed by a different domainwith only the French language available. At the end of this article,you will learn how to get eZ Publish ready for different projectsrequirements, include: multi-sites, multi-language, different accessmethod and SVN integration.
The set up
Plain site
For me, it seems there is a misunderstanding among novices ( and maybe also veterans alike? ) that the eZ Publish is the "eZ Web Interface"(or "eZ Flow", sometimes). I once got answer the question like:"Hey, yousaid you used the default templates for the this page, but why thispage doesn't look like the default page at all?" ( Then, the personwill show you a page on eZ Web Interface page side by side with thepage of your project ) The reason being is that eZ System uses "eZ WebInterface" in various articles and tutorials, plus, in the set upwizard of eZ Publish, it says "eZ Web Interface" provides most commonCMS website needs. But, the "eZ Web Interface" is really just a DEMO.For my opinion, for every new project, it is better to start from anempty site, thus the "Plain Site". Actually, if you read the manual,you will know, these things are called "site package"; "eZ WebInterface", "eZ Flow" and "Plain Site" are just different sitepackages. So, "why Plain Site" you may ask; Ithink the single reason that "Because in eZ Publish, template files andcontent types are tired together" is sufficient enough to make thisdecision. eZ Publish template file contains eZ Publish template codewhich will indicate attributes or properties of the defined contenttypes for each particular project ---- just think about how many timesyou will use content class identifier and content object attributeidentifier in you template code ---- eZ Web Interface comes with a setof predefined content classes, but I don't think it will really suitfor every project as the wizard page indicates; after all, if it does,what is the point of the powerful eZ Publish content engine (*1).?
So, when you are walking through the set up wizard, at the following screen, choose "Plain Site" And continue.
Multi-language
The project we are demonstrating, called "multiline", which will havetwo languages and two separated web sites. One called "mybilingual"accessed by www.mybilingual.com/index.php/fre for French version and www.mybilingual.com/index.php/eng for Englsih version; another one called "myindependent", accessed by www.myindependent.com. Set the multi-languages up can be done through either the set up wizard or in the Administration Interface later on:
Here we choose French and English, and set the French is the default/Main language.
Just click [Add language] button to add new languages.
Multi-site
Since we will have two separated web sites on the same installation,which means, we will have two sets of the content for each web site butunder the same content node tree so we can manage the two separated websites' content in a single back end. We will have two nodes directlyunder the "content root node" to serve as the root node for each of thewebsite.
In order to set this up for the Frontend Publicsites work correctly, we will have to make some changes on the specificsite.ini.append.php files. But we need set up our "site-access-es"first, because after run the wizard, we will only have one public siteaccess available, that is the "multiline" ( of course, plus theadministration site access, multiline_site_admin, we are already in ).
Site.ini.append.php
Create siteaccess manually
So, here are the site-access-es we need to add: fre, eng and myindependent.
Copy the configuration file over
Create these three sub directories under /settings/siteaccess: fre, engand myindependent. Then copy the site.ini.append.php file from themultiline access over to each of the directories.
SiteSettings
First, we need add some site access into the [SiteSettings] section:
In the global site access override, /settings/override/site.ini.append.php, get following settings ready:
[SiteSettings]
DefaultAccess=fre
SiteList[]=fre
SiteList[]=eng
SiteList[]=myindependent
SiteList[]=multiline_site_admin
The "multiline_site_admin" entry should already in place, and you probably need to remove the multiline and other entries then add the new site access names in.
SiteAccessSettings
Then, these are some configurations should be satisfied in the global site access override:
[SiteAccessSettings]
CheckValidity=false
AvailableSiteAccessList[]=fre
AvailableSiteAccessList[]=eng
AvailableSiteAccessList[]=myindependent
AvailableSiteAccessList[]=multiline_site_admin
MatchOrder=uri;host
HostMatchType=map
HostMatchMapItems[]=www.myindependent.com;myindependent
In order to make the multi-sites work, we will need set the match orderand access rules in the global override site.ini.append.php file. Theorder of the value for MatchOrder is important, the "uri" must be thefirst, the followed by the "host"; this way, the system will try tomatch or load site access configurations according to the uri firstthen according the domain name (*2).
root node, path prefix
In order to set up two different root nodes for each public web sites,we need change the configuration in the site.ini.append.php file foreach of the site access. Write down the node ID of the root node foreach of the web site. Then, if you have following settings in the [SiteSettings] of the file /settings/override/site.ini.append.php, remove it first:
[SiteSettings]
RootNodeDepth=1
then, for each siteaccess, except the multiline_site_admin, site.ini.append.php file, set these value in the [SiteSettings] section ( take siteaccess fre for example, /settings/siteaccess/fre/site.ini.append.php):
[SiteSettings]
IndexPage=/content/view/full/[Root Node Id of the mybilingual]/
RootNodeDepth=2
DefaultPage=/content/view/full/[Root Node Id of the mybilingual]/
set this value in the [SiteAccessSettings] section ( again, take siteaccess fre for example, /settings/siteaccess/fre/site.ini.append.php ):
[SiteAccessSettings]
PathPrefix=mybilingual
The RootNodeDepth
Set the RootNodeDepth to 2 instead the default value 1, will take care the problem related in the $module_result.path array. Thus, you can write the breadcrumb navigation links in your template code as normal.
The PathPrefix
This is the value of siteaccess fre or siteaccess engroot node url alias. This setting will take care the problem of thesearch engine return the content nodes above the root level in thesearch result list.
Add RootNodeDepth=1 back into the /settings/multiline_site_admin/site.ini.append.php file under the [SiteSettings] section.
Database settings
Normally,one project will only has single database; if you have a team ofdevelopers, it is also more convenient for all the eZ Publish instanceon their developer machine share the same database. By default, eZPublish put the database settings in each of the siteaccess'site.ini.append.php file. This is ok, but if you use the same databasefor all your site access, you could move the settings to the globaloverride for easier maintenance. Just remove following settings in eachof the site.ini.append.php file and put them into the/settings/override/site.ini.append.php file:
[DatabaseSettings]
DatabaseImplementation=ezmysqli
Server=[Database Server domain or ip address]
Port=
User=[Database User Name]
Password=
Database=[Database Name used by this eZ Publish system]
Charset=
Socket=disabled
SQLOutput=disabled
These settings should already available if you run through the set upwizard; just delete, cut and paste them into the correct location.
SiteAccessSettings
Above, we have already set one value in the [SiteAccessSettings] section. Since we are manually created the siteaccess from scratch, there are few more values need modified or added.
for siteaccess fre and eng:
[SiteAccessSettings]
PathPrefix=mybilingual
RequireUserLogin=false
RelatedSiteAccessList[]=fre
RelatedSiteAccessList[]=eng
RelatedSiteAccessList[]=multiline_site_admin
ShowHiddenNodes=false
for siteaccess myindependent:
[SiteAccessSettings]
PathPrefix=myindependent
RequireUserLogin=false
RelatedSiteAccessList[]=myindependent
RelatedSiteAccessList[]=multiline_site_admin
ShowHiddenNodes=false
for siteaccess multiline_site_admin ( modify the administration site access settings):
[SiteAccessSettings]
RequireUserLogin=true
RelatedSiteAccessList[]=fre
RelatedSiteAccessList[]=eng
RelatedSiteAccessList[]=myindependent
RelatedSiteAccessList[]=multiline_site_admin
ShowHiddenNodes=true
Please note the "RelatedSiteAccessList" settings. The point here is that site access fre and eng are belonging to the same domain site and site access myindependet belong to another, so they are not related to each other.
The session handler
For our multi-domain sites to work on the single eZ Publishinstallation, there are still one important setting needs to satisfy.It is the "SessionNameHandler" under the [Session] section in the site.ini.append.php. This time, we just put it in the global override:
In /settings/override/site.ini.append.php, put:
[Session]
SessionNameHandler=custom
The site design
We need set the configuration value of the SiteDesign under the [DesignSettings]which will indicate which site design the corresponding site accesswill use. Since there are probably two of site designs for thisproject, one for each of the web site, so again the site.ini.append.phpfile for myindependent has different setting values.
for site access fre and eng
[DesignSettings]
SiteDesign=mybilingual
AdditionalSiteDesignList[]=base
for site access myindependent
[DesignSettings]
SiteDesign=myindependent
AdditionalSiteDesignList[]=base
The two site designs, mybilingual and myindependent, will be set up inan extension. It is sometimes surprise that most users don't know howto create a "Design Extension", or don't know what is a "DesignExtension", if you fall into this category, don't worry, I will getinto it in just a minute.
RegionalSettings
The regional settings are important in order to make the multi-languagework correctly. Here we have each site access with different language,my preferable way to set the language up is for each site access has asingle language and for the administration site access has all theavailable languages. So, for example, for the site access fre, put following settings under the [RegionalSettings]:
[RegionalSettings]
Locale=fre-FR
ContentObjectLocale=fre-FR
SiteLanguageList[]=fre-FR
TextTranslation=enabled
ShowUntranslatedObjects=disabled
It is the same for the site access myindependent,because it also has only the French language. For the site access ofadministration, multiline_site_admin, site access, there are slightlydifferent:
[RegionalSettings]
Locale=eng-GB
ContentObjectLocale=fre-FR
ShowUntranslatedObjects=enabled
SiteLanguageList[]=eng-GB
SiteLanguageList[]=fre-FR
TextTranslation=enabled
A word on the "ShowUntranslatedObjects": If this setting is "enabled",the "Unstranslated Objects" means those content objects have thelanguage not in the "SiteLanguageList" array, so it is not just for the"Main Language". And another important point is that this will needwork in tandem with the settings set on the content object in theAdministration Interface, if the "Use the main language if there is noprioritized translation." check box is checked in the "Translations"block of a content object, then as long as there is a language versionof the object available, the object will not be recognized as"Unstranslated Objects".
The Local value will determine the locale system to use, such as thecurrency and date format, and the static text loaded through thelanguage file. The ContentObjectLocale indicates the default languagefor content objects. Since we are sure the main language for the systemis the French, and we want to ensure that when a content object createdor edited, it better has the French version as soon as possible, so Iset the ContentObjectLocale in Administration Interface to French eventhough the interface itself will be in English ---- cause honestly, Iam really not good at French at all.
Enable Regional Settings development mode. Itis a best practice to enable the "DevelopmentMode" in the[RegionalSettings] section. According to the comment information in thedefault site.ini file, this will result "all untranslated textstranslated using the bork rules"; it just means if the system can'tfind a translated text, the text will shown in brackets, [], with somefunny text. By enable this, it is easier to find those static text hasnot been translated yet ( *3 ).
In global override, /setings/override/site.ini.append.php:
[RegionalSettings]
DevelopmentMode=enabled
The VarDir
Since in eZ Publish, all the content related binary files ( images,docs, PDFs and so on ), cache files and log files are stored under thevar sub directory of the eZ Publish system root, it is better toindicate the name of the VarDir folder on per project basis. Right now,the system automatically set the VarDir to "var/plain_site", we canchange it to better maintenance.
Put this settings in the global override /settings/override/site.ini.append.php:
[FileSettings]
VarDir=var/multiline
Disable "ShowXHTMLCode" in [TemplateSettings].Some browsers made by Microsoft seem always have problems to displayweb page correctly. For example, when you enable the debug output inthe browser for eZ Publish, in Internet Explorer, some design of theweb sites will suddenly become a mess. This is because by default, eZPublish will display a comment in the rendered output of the browserfor each time a new template is loaded; and these added html commentcause problems with Internet Explorer, so it is best to disable this ifyou test your web page in various browers.
[TemplateSettings]
ShowXHTMLCode=disabled