|
Georg Franz
|
Wednesday 04 February 2004 9:42:05 am
Hi, I am currently bring some bigger ez3 sites online and I want to share my experience here. I hope some other admins will follow me. Not all errors happens because ez3 contains bugs ;-) I develop on a windows machine, the online site runs under linux. I've full control over the server, so some tips won't help you. -) If something won't work online and / or if you are getting strange error messages with no further debug info, increase the memory limit of php.
My current setting in php.ini is
memory_limit = 32M Some users have reported that they need even more if you they are using the pdf-feature.
Example:
First I've set the memory limit to 20M. Some times later, I wanted to edit my admin-user at the online admin-site. After clicking on the edit-button, ez gives a "fatal error" without any debug infos. The error only occurs if I want to edit my own account. If I try the same thing with the same db at my local system, everything worked fine. After increasing the memory limit, I was able to edit the admin account online.
-) Be careful with php-accelerators.
On my machine (red hat 7.1), I got troubles with ionCube PHP Accelerator which I used first. I've tried many settings in php.ini and have read many forum posts but at the end I always got "memory troubles" (shm). Now I am using mmcache / turck cache with a special "filter setting". I have excluded the "var"-directory of ez. The cache / memory problems are gone. my php.ini settings of mmcache:
zend_extension="/path/to/your/mmcache.so"
mmcache.shm_size="25"
mmcache.cache_dir="/tmp/mmcache"
mmcache.enable="1"
mmcache.optimizer="1"
mmcache.check_mtime="1"
mmcache.debug="0"
mmcache.filter="!/path/to/your/ez3/var/*"
mmcache.shm_max="0"
mmcache.shm_ttl="3600"
mmcache.shm_prune_period="7200"
mmcache.shm_only="0"
mmcache.compress="1"
But I am sure that some other users may report the opposite (turck don't run stable, try phpa).
So, my tip at the end is: If one accelarator don't work, try the other one ;-)
-) If images won't work online:
Yes, there are some (big) troubles upgrading ez to 3.3 from earlier versions. But not all troubles happens because of the new image system of ez33.
-> check the permissions and owner of the ez var-directory
-> check the permissions given in image.ini(.append)
-> sometimes convert (image magicx) don't work because your server run in a "memory problem".
Kind regards,
Emil.
Best wishes,
Georg.
--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004
|
|
Marco Zinn
|
Wednesday 04 February 2004 11:34:42 am
Nice idea, Emil! Something from me:
LARGE FILES:
When you have problems uploading large file, check the php.ini settings (there are two, that are usually set to 8M or so)
When you have problems indexing large file (binary file indexing), use the current ez 3.3 release, which has some fixes and optimizations for it. Note: as the order of words is stored (for phrase searching, i guess), you will get one DB table entry for every single word (occurance) in a document. That means: if you have a manual with 30.000 words, you will get 30.000 entries in the db table.
IMAGEMAGICK ISSUES:
We found some problems with converting JPGS with imagemagick's convert (an old version, but...). Most jpegs work, some do not work. If you experience this (or other ImageMagick issues, ie. installing it at all), you should go for GD2. My test gave nice results. GD works (using PHP 4.3.3 and GD 2.0.x), converts every JPG, is faster then Convert and knows the basic filters, including grayscale. It does not support "border" (judging from the gallery demo).
Using FTP for changing Templates:
When you use FTP to upload/change templates (ie. Dreamweaver), take care of your FTP server settings (user group, UID mask etc), so the webserver user (www, wwwrun, apache, nobody or so) can read and write the templates. You will need "read", so ez can use the templates and "write" permission, so you can change the templates in the admin web interface. If all goes wrong, use an FTP client to change the file permissions to "777" (read and write access for user, group, world). This MAY be a security issue.
Template caching issues:
When you upload/update template files by FTP, ezPublish is not able to notice this. That means, that the template (compile) cache is not updates and you will not "see" your new templates.
You have two options: clear caches in the admin interface (all or at least the template compile and override caches) OR edit the template, that you just uploaded, in the admin interface: Edit is, save it. ez will the clear all necessary files.
Template caching while developing:
While you are developing, you should disable the different caches (template compiling, content caching, cache-blocks). This usually is a sitewide setting, so do not use this for sites in production, when you develop a new "design" or so!
While you are working on the pagelayout.tpl files, you can edit the file without any cache-block blocks. So, pagelayout blocks will not be cached. When you finished the pagelayout design, you should introduce cache-blocks. READ THE DOCS for this, because it's easy to mess up a lot, when you don't understand about the cache-block-keys. On the other side, you should use the cache-blocks for performance reasons. Hm... Maybe, we should post all this in the docs section...
Marco
http://www.hyperroad-design.com
|
