php_mbstring extension

Hi there.

I have just updated my AjaxSearch to version 1.8.1, and now in place of my search form I get:

AjaxSearch error: php_mbstring extension required

... which is true. I don’t have the php_mbstring extension installed. Installing it would require me to recompile php on this system which I can’t do (at least not easily and not without risking loads of work trying to fix a broken system).

My database character set is UTF-8, and my config.inc.php file states this (utf8). The content encoding is UTF-8 and the manager is set to use UTF-8. I have read on a thread discussing a previous version of AjaxSearch that in that situation the php_mbstring extension is not required.

Is that still true? Please could you tell me if the php_mbstring extension a pre-requisite now?

Thank you.

Since the version 1.8 and the improvement of the getExtract function of the file class/search.class.inc.php, the php_mbstring extension is required.
This is due to the use of the following functions:

Thanks for letting me know. I’ll have to find a way of installing it then. It’s an important extension to have anyway.

I wonder if I can compile php_mbstring it as a separate php module that I can just stick in the modules directory and load rather than having to recompile the whole of php... This system is running Fedora Core 5, which is no longer supported, so I can’t just upgrade things using, for example, yum. I’ll do some investigating.

Cheers.

A very quick google shows that there is an RPM for it, named http://rpmfind.net//linux/RPM/fedora/8/i386/php-mbstring-5.2.4-3.i386.html but its for Fedora 8, if you download the source rpm try a rebuild on FC5, you mat be lucky if you can tweak the spec file a bit. I cant find any earlier ones.

shamblett, thank a lot. It’s definitely worth a try. I’ll have a bit more of a search and give it a go if I don’t find a closer package.

Paul

Hmm ... we may have to revert to a previous version for the distribution, as a requirement for now is to be compatible with PHP 4 servers. Is there a workaround for mb_string functions or can it be an optional parameter with a less optimal fallback?

I don’t understand this remark. Mbstring functions as mb_strpos, mb_strlen, mb_strtolower, mb_substr, mb_strrpos are available with Php >4.0.6

If I provide a a degraded version of AS (with use of classical string functions) when the mbstring extension is not loaded, I will get post about weird characters, without understanding the reasons.

Quote from: coroico at Dec 18, 2008, 12:38 PM

I don’t understand this remark. Mbstring functions as mb_strpos, mb_strlen, mb_strtolower, mb_substr, mb_strrpos are available with Php >4.0.6

He meant to say that mb_string functions are not always available on MODx supported servers and we like our reference add-ons to be as compatible with all environments as possible. IOW, it’s ok to add mb_string support to add-ons as an optional feature, but out of the box, the add-on should work even if that extension is not available. If this has to carry caveats regarding a specific feature, then so be it.

Quote from: coroico at Dec 18, 2008, 12:38 PM

If I provide a a degraded version of AS (with use of classical string functions) when the mbstring extension is not loaded, I will get post about weird characters, without understanding the reasons.

Unfortunately, ignoring the causes of character encoding issues is going to compound our problems. We need to get to the bottom of these issues and provide education as well as solutions that will work in as many environments as possible, even if with limited functionality.

My understanding is that many of php’s basic string functions are not safe to use with multibyte encodings - ie; anything other than ascii. Since most people use utf-8 these days, for which each character is represented by between 1 and 3 bytes, loads of people are at risk. However, alphanumeric/basic latin characters are all encoded using a single byte, so people with content in English will rarely encounter problems. That’s not the same for people writing in foreign languages however.

Here is an example that I have encountered where modx fails because it thinks in bytes not characters: I was encountering occasional blank pages and couldn’t figure out why. It turns out that I had written a long description in Japanese in the description field - so long that it was longer than the limit set by modx. Modx uses standard string functions to truncate the field (I guess), which truncate it at a certain number of bytes. This happened to be in the middle of a unicode character, leaving behind and invalid unicode byte sequence. This was being picked up the xml parsers in the browser which were refusing to display the page. If the multibyte version of the php string functions were used to truncate the string, this wouldn’t have happened.

So if using the basic string functions, everyone needs to be careful when performing operations that make assumptions about the number of bytes rather than characters in a string. Actually however, everyone should be coding with the mbstring extension all the time. The mbstring extension is designed to fix something that wont work - so saying that an modx should work without it doesn’t make sense - unless you want to rewrite the whole mbstring extension to php in modx. It’s great that AjaxSearch has been upgraded to use it and I would encourage all modx developers and users to do the same.

As for my particular case I am stuck using an old, no longer supported operating system, an old version of php and I don’t have full control over the system set-up so that installing the mbstring extension is going to be difficult. I am developing a site in English - so it would be nice to be able to turn off the mbstring usage in this case. However I would much rather not have to use such a system in the first place.

Cheers.

I just added a new snippet to the modx repository and there is not a single mbstring function in sight... How embarrassing is that after my last post!