mbstring in php

[zellamsee]

Hello,

We've run into a bit of a problem upgrading to 3.11.01. We are seeing problems symptomatic with not having mbstring compiled into php, E.g.

- experience problems with the mail parser
- blank pages

However, we DO have mbstring compiled into our PHP binary (see below - I've removed path information for security reasons):

./configure
--prefix=path_to_php
--with-mysql=path_to_mysql
--with-apxs2=path_to_apxs
--enable-track-vars
--with-gd
--with-jpeg-dir=path_to_jpeg
--with-config-file-path=path_to_php.ini
--with-zlib-dir=path_to_zlib
--with-libxml-dir=path_to_libxml
--with-xml
--with-zlib
--with-png-dir=path_to_png
--enable-cli
--enable-sockets
--enable-bcmath
--enable-calendar
--with-freetype-dir=path_to_freetype
--enable-mbstring

Before you ask, yes we have restarted our httpd server after making these changes.

Should we be using one of the following during php build time ina ddition to the --enable-mbstring?

--disable-mbregex
--with-libmbfl[=DIR]

Also, is there anything we should edit in the php.ini file? Here are the related values in our php.ini file:

[mbstring]
; language for internal character representation.
;mbstring.language = Japanese

; internal/script encoding.
; Some encoding cannot work as internal encoding.
; (e.g. SJIS, BIG5, ISO-2022-*)
;mbstring.internal_encoding = EUC-JP

; http input encoding.
;mbstring.http_input = auto

; http output encoding. mb_output_handler must be
; registered as output buffer to function
;mbstring.http_output = SJIS

; enable automatic encoding translation according to
; mbstring.internal_encoding setting. Input chars are
; converted to internal encoding by setting this to On.
; Note: Do _not_ use automatic encoding translation for
; portable libs/applications.
;mbstring.encoding_translation = Off

; automatic encoding detection order.
; auto means
;mbstring.detect_order = auto

; substitute_character used when character cannot be converted
; one from another
;mbstring.substitute_character = none;

; overload(replace) single byte functions by mbstring functions.
; mail(), ereg(), etc are overloaded by mb_send_mail(), mb_ereg(),
; etc. Possible values are 0,1,2,4 or combination of them.
; For example, 7 for overload everything.
; 0: No overload
; 1: Overload mail() function
; 2: Overload str*() functions
; 4: Overload ereg*() functions
;mbstring.func_overload = 0

.
.
.

; Exif UNICODE user comments are handled as UCS-2BE/UCS-2LE and JIS as JIS.
; With mbstring support this will automatically be converted into the encoding
; given by corresponding encode setting. When empty mbstring.internal_encoding
; is used. For the decode settings you can distinguish between motorola and
; intel byte order. A decode setting cannot be empty.
;exif.encode_unicode = ISO-8859-15
;exif.decode_unicode_motorola = UCS-2BE
;exif.decode_unicode_intel = UCS-2LE
;exif.encode_jis =
;exif.decode_jis_motorola = JIS
;exif.decode_jis_intel = JIS

Any pointers would be greatly appreciated!

Thanks in advance for your time.

Cheers,
jen

[craigbrass]

Can you create a PHP Info file and link to it in a reply so we can take a look please?

[Jamie Edwards]

Hi Jen,

It certainly sounds strange. Can you also take a look in your PHP error log (there will be one) for any error reports related to SupportSuite?

[tommy]

Hi Jamie,

Originally Posted by Jamie Edwards

It certainly sounds strange. Can you also take a look in your PHP error log (there will be one) for any error reports related to SupportSuite?

We are getting messages like the following in our error logs:

[Fri Aug 31 14:18:17 2007] [error] [client xxx.xxx.xxx.xxx] File does not exist: /xxx/files/cf7124e3a5ca99ca0002bcc22587c19c.js, referer: https://webhost/xxx/staff/index.php?...kets&_a=manage

We are not seeing any PHP errors in the logs (e.g., no 'unable to stat', etc.).

Comments:

- the log messages like the one above started appearing _after_ upgrading from v3.10.02 STABLE to v3.11.01STABLE

- we see these messages with PHP 4.4.7, PHP 5.2.3, and PHP 5.2.4;
all built with 'mbstring' support (see original post for the configure flags we used)

- the strange thing about the messages is the reference to not being able to find javascript in the 'files' directory!? Also, the hash portion of the names looks like the names of cached php routines located in the 'cache' directory.

We're not sure if this has any bearing on the problem we reported in our original post or not, but we figured it would be interesting...

We tried turning on SQL error debugging in config/config.php:

/**
* LOGS ANY SQL ERRORS UNDER ./files/sqllog.txt - ENABLE ONLY TO DEBUG!
*/
define("DEBUGSQL", true);

but we are not finding any file that looks like "./files/sqllog.txt".

What are your recommendations for turning on additional debugging for troubleshooting purposes?

Cheers,

Jen & Tom

PS: Our platform is Sun Solaris 5.9 SPARC, not Windows

[Jamie Edwards]

Hi Tommy,

Please follow these steps;

1) Make sure the cache and files folder inside the SupportSuite install directory is fully writeable for the script/user.
2) Clear all the existing contents except for index.htm

Give it another go after that.

[tommy]

Hi Jamie,

re:

Originally Posted by Jamie Edwards

Please follow these steps;

1) Make sure the cache and files folder inside the SupportSuite install directory is fully writeable for the script/user.
2) Clear all the existing contents except for index.htm

Give it another go after that.

read/write/execute permissions are set on the 'files' and 'cache' directories, and I deleted all of the contents of 'cache' except index.htm.

I then sent a test message to a department which is configured to send an autoresponse and for which I have an alert set. The results remain unchanged:

1) I receive an alert about the existence of a new ticket. The alert correctly has the contents of the test inquiry I sent in.

2) I do _not_ receive an autoresponse as the user that sent in the ticket

3) the mail parser log does _not_ have any record of processing the test inquiry

4) the ticket is shown in the target department, but the count of the number of open tickets does not get incremented

5) the 'time since receipt' of the ticket indicates that the ticket is over 6 hours old (i.e., 6 hours + number of seconds since the ticket was received)

6) when I open up the view of the ticket, I get a page that does not have any information about the ticket (the page is not totally blank, but it has no information about ticket except for the summary line that shows the ticket ID at the very top)

The non-existence of a parser log entry and a semi-blank screen in the ticket list/response view sound like the original comments about what one might see if 'mbstring' compatibility was not built into PHP. Jen's original post, however, shows that PHP was built with 'mbstring' compatibility.

It is interesting that PHP 4.4.7 built with 'mbstring' compatibility does work, but PHP 5.2.[34] do not.

[craigbrass]

In which case, I think it would be a good idea to submit a ticket to support (http://members.kayako.net -> "Get Support") so they can investigate the issue and have the developers fix the problem in the software if that is what it is found to be.

[zeki]

has this issue been resolved? i have the same error

[Thu Oct 18 14:48:47 2007] [error] [client 192.168.9.30] File does not exist: /home/chat/www/files/93d9393288589afdf7611553e74dfc68.js, referer: https://xxx/staff/index.php?_m=tickets&_a=manage