The trick is the following block:

url.rewrite-once = (
"^/.*\.(css|html|htm|pdf|js|png|gif|jpe?g)$" => "$0",
"^/.*?(\?.*)?$" => "/index.php$1"
)

For more about lighttpd and php4/php5 config instructions, please consult this thread.

It seems it is now the time for a new release of SJSD which supports the latest FCKeditor: The svn trunk of SJSD supports 2.3 already, but no public release yet. I will try to make a release if I can find some time to sort it out.

In addition, a new patched EditMonkey would be nice as well, but as I haven’t ported the FCKeditor plugin for wordpress to FCKeditor 2.3 yet, it requires much more time, which I probably won’t do until some time later when I am not so occupied.

Go to admin interface -> User accounts -> Roles and policies, click into Role Anonymous. Everything seems fine, except this line:

SiteAccess is empty! Uhm, after adding the default siteaccess home to it, anonymous users can access public areas normally.

The empty SiteAccess is caused by the different default siteaccess name in the two installation: in the SCIM server, the default one is home, while in my locale copy it is eng.

I must say this is a bit counter-intuitive: as anonymous already has this rule:

It should have enough privilege to at least read the files in these sections. It turned out that granting of user/login is necessary for content/read!

Although, in this particular case, I want anonymous users to have the grant of user/login function, I don’t think content/read should depend on user/login!

Is this a bug? Is it worth to report to eZ?

This is the .htaccess (I have eZ installed in /ez38, so this .htaccess is under /ez38) required to have eZ work with apache rewrite properly in a subdir:

RewriteEngine On
RewriteRule !\.(gif|jpe?g|png|css|js|html|xml|ico)|var(.+)storage.pdf(.+)\.pdf$ index.php

DirectoryIndex index.php

In order for apache to read .htaccess in each dir, something like this has to be set in the httpd.conf file for apache:

<Directory />
    Options FollowSymLinks
    AllowOverride All
</Directory>

UPDATE (29/May/2006): *.ico should not be rewriten to index.php

The key point is that rewrite rules in lighttpd does not work under $HTTP["url"], so this is what I got working finally:

url.rewrite-once = (
"^/ez38/.*\.(css|html|htm|pdf|js|png|gif|jpe?g|ico)(\?.*)?" => "$0",
"^/ez38/.*" => "/ez38/index.php"
)

Note: the ez publish is installed under /ez38/ of the document root, and you may want to change it. If you install ez under your root, just replace "/ez38/" with "/".

if you want to use SJSD with lighttpd, then you should have something like this:

url.rewrite-once = (
"^/ez38/.*\.(css|html|htm|pdf|js|png|gif|jpe?g|ico|xml)(\?.*)?" => "$0",
"^/ez38/.*" => "/ez38/index.php"
)

UPDATE (29/May/2006): *.ico should not be rewriten to index.php

As a result, the trunk of SJSD svn now only works with FCKeditor 2.3 beta or its svn, and a branch was created to host the old FCKeditor 2.2 version on which future SJSD 0.3.x releases will be based. SJSD trunk will be released as 0.4.0.

If you want to stick with FCKeditor 2.2 and currently you are using SJSD svn, then you should issue this command under your checked out copy:

svn switch https://svn.sourceforge.net/svnroot/sjsd/sjsd/branches/fckeditor_2_2

after this, svn up will not update your copy to trunk.

On the other hand if you want to adventure, you may want to give SJSD trunk and FCKeditor 2.3 beta (its SVN is highly recommanded) a try.

The porting did take some time, due to the new framework of toolbar and context menu, and some other API modification. However with the help of Firebug and Web Developer, I can pin down the problem really quickly.

The current status about the SJSD trunk is that it is working reasonably well (at least in Firefox) now with FCKeditor svn, except some known minor issues.

One of the issues I’d like to mention is this reported bug. If you use the default eZ admin css style sheets, you have to modify one line in design/admin/stylesheets/site.css:

div.content-edit div.box-content {
   position: relative; 
}

Remove the line begining with position or comment this line out. Otherwise the FitWindow new feature introduced in FCKeditor 2.3 will not function properly.

Another update about SJSD is that I finally decided to rewrite the XML input handler based on the new simplified xml input handler in eZ 3.8. However, as keeping in mind of EditMonkey, I will ensure that the DOM processor is extensible and as standalone as possible so that it can be incorporated in other project easily, such as future release of EditMonkey.

Before anything else, first make your eZ offline in case users want to access it. You can achieve this easily by just replace the eZ index.php with a file stating that “the site is undergoing an upgrade and will back online soon” or similar.

First, update the database. The sql update files I applied include:

update/database/mysql/3.6/dbupdate-3.5.2-to-3.6.0.sql    
update/database/mysql/3.8/dbupdate-3.6.0-to-3.8.0.sql    
update/database/mysql/3.8/dbupdate-3.8.0-to-3.8.1.sql

Second, run the provided update scripts under update/common/scripts/. I figured these are required for my particular needs:

update/common/scripts/convertxmllinks.php    
update/common/scripts/updateattributefilter.php      
update/common/scripts/updatemultilingual.php    
update/common/scripts/updatesearchindex.php    
update/common/scripts/updatesession.php    
update/common/scripts/updatetoplevel.php    
update/common/scripts/updatetranslations.php    
update/common/scripts/updatexmltext.php    
update/common/scripts/updatecontentobjectname.php    
update/common/scripts/updatetranslations.php

You may need to run other scripts if you use the online shop support in eZ. Some of these script may require siteaccess to be specified explicitly, please see the help (-h option, as usual) for details. If you have several siteaccess using one database, just run a script using one of the them is enough.

Then I went though/review the custom template files and updated them accordingly.

In eZ 3.5, I used to have a modified version of object.tpl which renders an object inline if its view attribute equals text_linked. As in eZ 3.8, a new tag embed-inline is introduced, I have to update all the xml attribute. Luckily, it is trivial to modify one of the update script to achieve this. Here is the patch:

Index: update/common/scripts/updatexmltext.php
===================================================================
--- update/common/scripts/updatexmltext.php     (revision 16004)
+++ update/common/scripts/updatexmltext.php     (working copy)
@@ -198,8 +198,24 @@
                     $foundLinks = true;
                 }
             }
-        }
-        if ( findAndReplaceLinks( $doc, $child ) )
+        } else if ( $child->name() == 'embed' || $child->name() == 'object')
+        {
+            echo $child->toString()." Original\n";
+            $objectid = $child->attributeValue('id');
+            unset($mchild);
+            $mchild =& $child;
+            $mchild->removeNamedAttribute( 'id' );
+            if($mchild->attributeValue('view') == 'text_linked')
+                $mchild->setName('embed-inline');
+            else
+                $mchild->setName('embed');
+
+            if(is_numeric($objectid))
+                $mchild->set_attribute('object_id',$objectid);
+            echo $mchild->toString()." Converted\n";
+            //$child->removeAttribute();
+       }
+        else if ( findAndReplaceLinks( $doc, $child ) )
             $foundLinks = true;
         unset( $child );
     }

I have to re-emerge php with added cgi use flag to get cgi binary. The configuration necessary for apache to use PHP as CGI is stated in gentoo documentation:

<IfDefine PHP4CGI>
    ScriptAlias /php4-cgi /usr/lib/php4/bin/php-cgi
    Action php4-cgi /php4-cgi
    AddHandler php4-cgi .php4 .php3 .php .phtml
</IfDefine>

I save that as file /etc/apache/modules.d/71_cgi_php.conf and I have to change one option in file /etc/conf.d/apache from: APACHE_OPTS="-D PHP4" to APACHE_OPTS="-D PHP4CGI"

One option in php.ini is also required to be set: cgi.fix_pathinfo=1. Without this option enabled, you will receive an error message telling you that " 'unexpected T_STRING' in the php binary" (it may appear in log instead/as well).

On the other hand, lighttpd does not require this option to be enabled.

First, I have to decid which of the two minority web server I’d like to try. Although personally I prefer the cool name of nignx (pronounced as engine X), it does not support php directly: instead it depends on lighttpd to handle php request. It is obvious I have to go with lighttpd to run eZ.

After some painful googling about howto make lighttpd work with fastcgi/php etc, I finnally managed to work out a way to get through the mess, and make eZ Publish work with CGI as smoothly as in php apache mod.

Install Lighttpd

First, install lighttpd. As a gentooer, this is pretty straightforward:

emerge lighttpd

Of course, in order to install the latest version available in portage, I use ~x86 keyword for the package  www-servers/lighttpd (In fact, latest version for lighttpd is 1.4.11, while the newest one in portage is 1.4.10, but I think 1.4.10 is reasonable new and stick with it). And do remember to enable the php use.

The configure for PHP is in /etc/lighttpd/mod_fastcgi.conf, and it should be ok out of the box, . However for those not in the hand of gentoo, you can find the config file in the attachment.

In /etc/lighttpd/lighttpd.conf, the main config file for lighttpd, I enabed these modules: mod_rewrite, mod_redirect, mod_alias, mod_access and mod_accesslog.

That’s pretty all of configuration it requires, now we can stop apache (I use 1.3.34 now) and start our brand new lighttpd.

Work with eZ publish

The setup of the eZ I test is not a virtual host one: it is a url based. I can access the homepage of it with lighttpd successfully, but all the urls are something like index.php?/siteaccess/bla/bla, which is not nice and it does not compatible with eZ working in none CGI mode.

I tried to access index.php/siteaccess/bla/bla directly (without a question mark after index.php), and it did not complain about no input file or similar, instead eZ loaded but eZ complained that ez38 is not a recongized module (the eZ is installed in /ez38 subdir).

After checking the phpinfo() output, I figured that even in CGI mode, it is possible to obtain the path info (the string appending after index.php) without using query string. In fact, just modifying one file in eZ core is enough to make it work with CGI: lib/ezutils/classes/ezsys.php.

I will definitely release the patch after I tidy it up and make sure it can still work in none CGI mode.

Ah, in case you wonder, yes, it is possible to use eaccelerator or similar with lighttpd/fastcgi/php. I am using it in my test server without any problems.

In case you do not know what SJSD is, here is a short description copied from its website in SF: SJSD provides a fully integrated, feature complete and extensible WYSIWYG open source online editor for eZ publish. It is implemented in the form of a FCKeditor plugin and an eZ publish extension and requires no modification to FCKeditor/eZ publish core.

This is mainly a bug fix release, changeLog since 0.3.0:

• Inline tag support in header tag
• added support for embed-inline (fixed bug #1480810)
• fixed issues to support other languages (such as CJK)
• do not transfer unnecessary characters to xhtml entities
• fixed the custom attribute dialog compatibility issue with IE
• various other bug fixes

Grab it from Sourceforge.