Ok now, our task of preparing the eZ Publish system ready for our newproject is pretty much finished; before we really start the developmentbusiness, there is one more step: put everything in to a versioncontrol system because in reality, an eZ Publish project probably is anenterprise portal site or some like that, we probably have a team ofdevelopers work on each project ( even thought you are the only one, westill want everything nice and clean right? ). In our project, we willuse the SVN version control system.
There is already countless discuss on how to set up and use a SVNrepository; on the eZ Publish front, there is an excellent article, Using Subversion with eZ PublishIf you read the article, basically, there seem no good ways to managethe environment related settings file, particularly, thesite.ini.append.php files. So, my suggestion is to ignore these filesin SVN.
This is article, I will not waste time on introduce the basic conceptof SVN. I assume that we will only concern the trunk of the repository,our proejct located at /var/www/multiline/, and the url to the projecttrunk is, https://www.yousvnserver.com/ezpublish/multiline/trunk/.
Import to the SVN trunk
We first import eZ Publish files into our SVN trunk:
cd /var/www/multiline
svn import . https://www.yousvnserver.com/ezpublish/multiline/trunk/ -m "initial import eZ Publish project files"
Make a working copy
After importing, remove all the stuff in /var/www/mutliline/ directory:
rm * -rf
Then check out the files back from the SVN:
svn co https://www.yousvnserver.com/ezpublish/multiline/trunk/
After check out, you can open the browser to load the web site again – just to make sure everything is going alright (*4).
Ignore cache and log files
Before we ignore these files, make sure these diretories are empty:
var/log
var/cache
var/multiline/log
var/multiline/cache
Then, issue this command:
svn propset svn:ignore "*" var/cache
svn propset svn:ignore "*" var/log
svn propset svn:ignore "*" var/multiline/cache
svn propset svn:ignore "*" var/multiline/log
svn commit -m "ignore cache and log files."
Ignore the site.ini.append.php files
There is probably another better way to handle this problem, but I think ignore the site.ini files is more simple.
svn propset svn:ignore "*site.ini*" settings/override/
svn propset svn:ignore "*site.ini*" settings/siteaccess/eng/
svn propset svn:ignore "*site.ini*" settings/siteaccess/fre/
svn propset svn:ignore "*site.ini*" settings/siteaccess/myindependent/
svn propset svn:ignore ""*site.ini*" settings/siteaccess/multiline_site_admin/
svn commit -m "ignore site.ini.* files."
Now we have successfully set up the SVN. As usual, I want to post some additional considerations:
About Database backup strategy.
Onespecial note I want to make is that the database is not under theversion control. But, it doesn’t mean we shouldn’t make the backup ofthe database often. I think, there are two possible ways to do:
1.Use the traditional, or normal, or existing backup strategy to takecare of the database. For example, on the database server, there arebackups for everyday.
The pros for this are that, we don’t need to think about if the task on the hand will be impact on the database.
The cons for this arethat it doesn’t have the version control advantage. The backup of thedatabase depend on the time at which the backup made, not depend on atwhich task changes made to the database.
2. Also use the version control to manage the backups of the database.
The pros for this are: everything, including the database, is in the repository.
The cons are:
A. There is actually no simple way to do it. One possible way is that every time we export the database out, and thenstore it under some folder (maybe the doc folder under the eZ Publishroot). Afterward, you should remember to commit in the database backupfile into the repository.
B.The developer should have knowledge to decide when is appropriate toexport the database, which is different from person to person.
But, database backup is very important. Here is what I think when you should backup the database:
1.Before doing class definition changes in the backend -- for somecritical class, and the template for this class is already exists.
2. Before importing something use the package file through the backend.
Thereis a standard way for importing and exporting data from the eZ Publish:use the packages. You can actually create & export a package forclass definitions, content objects, and extensions.
3. Before run the php scripts under the bin/php.
For example, before run the updateniceurls.php script.
4.When install some third-party extensions. Read the install or readmefile, if it needs backup the database, backup the database.
About the “var” Folder
Now,we are normally put the "var" folder, under version control. Whether ornot this folder should put in version control can be discussed in thefuture: for example, for my point view, I would strongly recommendtoday not storing the var directory in Subversion at all; but if youhave a separated web test team and they need input test content to testthe implemented template file with the same database, it means theywill need always create/edit all the content they test.
There is also a good extension called ezsvncan be used for SVN management. It will always update the eZ Publishsystem to the latest/HEAD version of the official trunk. This means itis ensured that the currently system is up-to-date, but not theofficial release stable version. And, also, the extension will requirespecial server configuration and server arrangement. Takeconsiderations for yourself to see if this is suit for your project(s).
Inthis article, we have walked through the initialization of a new eZPublish project. We are looked mainly how to configure thesite.ini.append.php file to make a mutli language, multi sub sites workunder single eZ Publish installtion; we learned how to create designextensions and initialize the SVN version control system.Alone the way,I have also posted some questions and considerations for othersituations which may arise in different projects. After read thisarticle, new users come to eZ Publish should have a fairly firm groundon get start an new eZ Publish project.
(*1) Yes, there are a tutorial on "How to Skin an eZ Publish web site based on the Web Interface".Of course it is a usable approach, if your organization has a fullydedicated team including members of designer, web designer/html/cssintegrator and developer. Building everything from Web Interface willrequire much more deeper knowledge on the output information, such as:html div tags, css classes and ids, of the template system, maybe someconversions made by the Web Interface, excellent css skills and veryefficient communication between designers and developers. And still,all this requires time. But, I think starting from the "Plain Site"suit for most organizations, even if you have everybody in place; andthis approach should be more flexible and cost effective.
(*2) I have made the assumption that you have already set the web server and DNS up. For example, both domains, www.mybilingual.com and www.myindependent.com should be point to the same eZ Publish system root, for the virtual host www.myindependent.com configuration, you can consult the manual on "Set up virtual host". This should be already the case if you already fired up the set up wizard.
(*3) Why not the "LanguageSwitcher"? If you even wonder why I didn'tmention any of the settings related to "LanguageSwitcher" settings, itis because according to the commentating documentation: "# NOTE: TheLanguageSwitcher settings are not frozen, meaning they might stillchange." So, it means it is not stable yet, I think it is better toavoid it for now.
(*4) On *nix server, if any abnormal things happens, trying to checkthe files permission on the file system, especially check if the webserver has the read permission on the settings file and has the writepermission to the var folder files.