Cannot load /.../libphp5.so into server: /.../libphp5.so: undefined symbol: _efree

Google suggested that, lots of people have the exact error, but not a single page contains what caused this error or how to solve it. In addition, this error also happens with php 4 and apache 1.

After some hard time Trial and error, I found the issue: due to some reasons, the make install to install php 5 does not actually copy over the libphp5.la files to the right place. After manually copying the la file, apache 2 can be started happily with php 5 enabled.

Edit: Ivan reported that instead of the above,

make clean

will make it work for his case. Thanks. – Dec 21 2008

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.

However, as the proper way is to set the encodings in mysql 4.1 correctly, I decided to do it sooner rather than later.

According to the document, if UTF-8 was saved in the mysql 4.0 db although the default encoding is not UTF-8, then:

However, you should avoid trying to convert directly from latin1 to the "real" character set. This may result in data loss. Instead, convert the column to a binary data type, and then from the binary type to a non-binary type with the desired character set. Conversion to and from binary involves no attempt at character value conversion and preserves your data intact.

As it turns out, wordpress 2.1-alpha actually just save the text as latin1 strings, so no need to convert the fields to BINARY first, setting charset to UTF-8 on those fields is sufficient.

An sql file is prepared for doing this. (Proceed at your own risk and always backup first)

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

As this is a 2.1-alpha (svn) of wordpress, it refused to store the WordPress.com API key. However, after a svn up of wordpress, it got fixed.

I deactivated plugin CaptCha! and went and saw how well Akismet could do its job. So far, Akismet caught 8 spams perfectly without missing a single one. I guess I will stick with Akismet then.

I just did not come up how can the spammer bot work around the Captcha challenge…

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.