vBulletin 4.2.5 is end of life and will not be receiving any future development. Warning: vBulletin 4.2.5 is not compatible with PHP 7.2.0 or higher.
Welcome to the vBulletin support forums! In our community forums you can receive professional support and assistance with any issues you might have with your vBulletin Products.
If you are having problems posting in the relevant areas for your software, please see this topic.
Upgrade to vBulletin 5
We're pleased to announce a special promotion for upgrading your vBulletin 3/4 sites to vBulletin 5. From now until December 31st, we are offering vBulletin 5 license upgrades at $169 each. This promotion is available to all vBulletin 3 (owned) and vBulletin 4 license holders, entitling you to the latest version of vBulletin 5.
If you would like to purchase this upgrade, please log into the vBulletin Members Area and use Promo Code: vB5UPGRADE during checkout to apply the discount.
Announcement
Collapse
No announcement yet.
After upgraded to PHP 5.4.3 the Textarea is empty if I want to edit posts or threads!
[Forum]
After upgraded to PHP 5.4.3 the Textarea is empty if I want to edit posts or threads!
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.
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.
Translations provided by Google. Wayne Luke The Rabid Badger - a vBulletin Cloud demonstration site.
vBulletin 5 API - Full / Mobile
Vote for your favorite feature requests and the bugs you want to see fixed.
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?
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
Translations provided by Google. Wayne Luke The Rabid Badger - a vBulletin Cloud demonstration site.
vBulletin 5 API - Full / Mobile
Vote for your favorite feature requests and the bugs you want to see fixed.
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
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:
Originally posted by Thunderbird
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
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...
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.
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.
Translations provided by Google. Wayne Luke The Rabid Badger - a vBulletin Cloud demonstration site.
vBulletin 5 API - Full / Mobile
Vote for your favorite feature requests and the bugs you want to see fixed.
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
Code:
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
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
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.
Translations provided by Google. Wayne Luke The Rabid Badger - a vBulletin Cloud demonstration site.
vBulletin 5 API - Full / Mobile
Vote for your favorite feature requests and the bugs you want to see fixed.
Hello Guys,
I have a weird situation happened couple of times now when upgrading my demo forum.
To run the upgrade I need to change to PHP 7.1, my current PHP is 7.0
The installation...
Tue 19th Mar '19, 8:03pm
Working...
X
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We may share certain information about our users with our advertising and analytics partners. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also consent to the transfer of your data to our servers in the United States, where data protection laws may be different from those in your country.
Comment