[Forum] After upgraded to PHP 5.4.3 the Textarea is empty if I want to edit posts or threads!

[amin]

Hi,

four days a go I upgraded my server to PHP 5.4.3 after I check that vbulletin can works with it!.
I got some problem, like VBSEO not working very will with PHP5.

Anyway I found out that textarea show nothing when I want to edit a post or thread.

I sent ticket to vbulletin support they said I have to downgrade the PHP to old version!!!

tomorrow I'll downgrade the PHP but before that I would to ask it is possible to upgrade the CKEditor Textarea to its last version? it might good solution!

I have more than 7 Gigabit database. please before I do that step, if you have any solution to fix this bug and other bugs I did not find about them yet.

Best regards.

Amin

[Wayne Luke]

I am not sure what the size of your database has to do with changing from PHP 5.4.3 to PHP 5.3.13. The two aren't really related.

vBulletin hasn't been certified to work on PHP 5.4.0 or higher. Some people say it works and others say it doesn't. If the only thing that changed was the PHP upgrade before this problem started then you should downgrade your PHP. This should have zero effect on your database as you don't have to change anything in MySQL itself.

I don't know what the effects of upgrading CKEditor will have or if it will even solve your problem. Any such change wouldn't be supported until implemented by our developers.

[amin]

I am not sure what the size of your database has to do with changing from PHP 5.4.3 to PHP 5.3.13. The two aren't really related.

Hello Wayne,
Thank you for your reply...
By knowing size of database you will have an Idea that the forum I'm working on is very huge and busy. So, I need solution with lowest cost.

I need to know what, is the best version of PHP supported by vb 4.2?

Thank you

Amin

[Wayne Luke]

Hello Wayne,
Thank you for your reply...
By knowing size of database you will have an Idea that the forum I'm working on is very huge and busy. So, I need solution with lowest cost.

I need to know what, is the best version of PHP supported by vb 4.2?

Thank you

Amin

5.3.13

[colimensenetwork]

I have the same problem, upgrade my php version and all php modules and the problem start.
My versios:
httpd -v
Server version: Apache/2.2.22 (FreeBSD)
Server built: Jun 2 2012 19:15:57
Compiled in modules:
core.c
mod_authz_host.c
mod_filter.c
mod_charset_lite.c
mod_deflate.c
mod_log_config.c
mod_logio.c
mod_env.c
mod_mime_magic.c
mod_expires.c
mod_headers.c
mod_unique_id.c
mod_setenvif.c
mod_version.c
prefork.c
http_core.c
mod_mime.c
mod_cgi.c
mod_vhost_alias.c
mod_negotiation.c
mod_dir.c
mod_actions.c
mod_alias.c
mod_so.c

php -v
PHP 5.4.3 (cli) (built: Jun 2 2012 19:17:33)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

php -m
[PHP Modules]
apc
bz2
calendar
Core
ctype
curl
date
dba
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
imap
intl
json
libxml
mbstring
mcrypt
mhash
mssql
mysql
mysqli
mysqlnd
odbc
openssl
pcntl
pcre
pdf
PDO
pdo_sqlite
Phar
posix
Reflection
session
SimpleXML
snmp
sockets
SPL
sqlite3
standard
tidy
tokenizer
xml
xmlreader
xmlwriter
zip
zlib

[Zend Modules]

I decide debug with firebug of firefox and when i try to edit a post, firebug send me this:
Dep Ctrl (deps_x) FAIL: deltype_hard http://mydomain/clientscript/vbulletin-editor.js?v=420 (line 11)

Radio deltype_soft (deletepost) http://mydomain/clientscript/vbulletin-editor.js?v=420 (line 11)

Dep Ctrl: deltype_soft http://mydomain/clientscript/vbulletin-editor.js?v=420 (line 11)

Some idea about what php module is giving this problem ?

P.d. This problem only affect new messages after the upgrade of php
Thank u

[Dustin L.]

The lesson to be learned here is in Wayne's post:

vBulletin hasn't been certified to work on PHP 5.4.0 or higher.

Don't update to 5.4.

[BibleWheel]

I had the same problem for about a month since my host upgraded to PHP 5.4.2. It was very frustrating. Couldn't edit and the "Reply With Quote" was broken. Thunderbird explained a simple fix in this thread. It worked for me:

Looking at the CKEditor site, it appears that a change in the default encoding of htmlspecialchars() (from ISO-8859-1 to UTF-8) causes the editor to throw a blank box in some instances. Peachy.

I fixed it on my board by the following change to /vb/ckeditor.php

Line 507:
htmlspecialchars($value)

Changed to

htmlspecialchars($value, ENT_COMPAT | ENT_HTML401, "ISO-8859-1")

[xgamingstudio]

This worked perfectly. Thanks for this fix. It was driving me nuts when I kept thinking that it was my server configuration issue.

[colimensenetwork]

The lesson to be learned here is in Wayne's post:



Don't update to 5.4.

I think this isn´t a solution.

[Dustin L.]

I think this isn´t a solution.

vBulletin has not been tested, at least to my knowledge, for PHP 5.4, so why would you update to PHP 5.4?

vBulletin staff have told the OP to downgrade his copy of PHP, that should apply to you as well.

[KciNicK]

the problem is with certain characters, like "ñ", if there is one of those the textarea get blank, otherwise it work as intended, is not the editor, as sniffing the packets the message never arrives to the browser, maybe something has change in the encoding, please, someone fix this, thanks...

[Thunderbird]

Upgrading CKEditor to its latest version won't do anything, as the bug still exists within the current version. I found this over at the CKEditor site, which is what gave me the clue to do what I did in my post that is quoted earlier in this thread.

The issue in this thread occurs because htmlspecialchars is used to fill in the contents of the editor box, but the call doesn't specify an encoding. In PHP 5.3 and earlier, htmlspecialchars used an encoding of ISO-8859-1 when one wasn't specified, but in PHP 5.4, that was changed to UTF-8. If htmlspecialchars is given something that isn't in the correct encoding, it'll simply toss an empty string back, which is why the problem only occurs with certain characters. I had this same issue for awhile until doing the change that I specified in that quoted post, then the problem instantly went away.

Downgrading to PHP 5.3 isn't an option for everyone.

[Wayne Luke]

If you are using PHP 5.4.0+ then you need to make sure all errors, notices, warnings and every other PHP message is turned off and never sent to the web browser under any circumstances. Having these messages displayed can and will interrupt the AJAX communications and cause your systems to fail including the editor. In the future when we have actual support for PHP 5.4.0+, this should be less of a problem.

If you are using a non-latin or the English language or rely on accents that do not occur in the first 256 characters of a font, then you need to adjust your encoding appropriately.

[KciNicK]

Upgrading CKEditor to its latest version won't do anything, as the bug still exists within the current version. I found this over at the CKEditor site, which is what gave me the clue to do what I did in my post that is quoted earlier in this thread.

The issue in this thread occurs because htmlspecialchars is used to fill in the contents of the editor box, but the call doesn't specify an encoding. In PHP 5.3 and earlier, htmlspecialchars used an encoding of ISO-8859-1 when one wasn't specified, but in PHP 5.4, that was changed to UTF-8. If htmlspecialchars is given something that isn't in the correct encoding, it'll simply toss an empty string back, which is why the problem only occurs with certain characters. I had this same issue for awhile until doing the change that I specified in that quoted post, then the problem instantly went away.

Downgrading to PHP 5.3 isn't an option for everyone.

so putting

default_charset = "ISO-8859-1"

on php.ini should fix the problem? the default is UTF-8

can comebody try this? im already downgraded to 5.3

[wolfey]

I have same issue and yes also narrowed it down to PHP handling special characters, I was trying to edit a post where I copied text from another place that had a small "TM" displayed

What can we do to fix this?

[Wayne Luke]

It has to do with double-byte characters and the lack of complete UTF-8 in vBulletin at this time. It isn't specifically a PHP 5.4.3 problem. That simply exacerbates the issue.

You can try forcing PHP to use ISO-8859-1 or CP-1252 to help control the issue. Making sure IconV is installed helps as well as it will convert characters not supported to their HTML Entities. Unfortunately, that can muck up a database long term.

If you have MySQLi installed in PHP, you can convert to it in your config.php by changing the Database Class and then tell vBulletin to talk to MySQL using UTF-8 in the same file. Unfortunately, this isn't a 100% fix either.