HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


PHP 5.3.1 - any known issues?

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#59735 (In Topic #13001)
Avatar

Well-settled

Hi there,

my hosting provider has moved to a new server with php 5.3.1, and my ocp installation quit working. It keeps throwing query errors, which I suppose are codepage/encoding related. We compared php mysql and apache parameters of old and new servers and could not spot any difference. Phpmyadmin displays extended characters (like German umlauts) from the database ok, but the website gets them wrong and ocp seems to encode queries in a wrong way. The error in ocp itself looks like that:

... );\n', 'DE')] [Incorrect string value: '\xE4nkung…' for column 'text_original' at row 1] (version: 4.3.2, PHP version: 5.3.1, URL: /site/index.php?page=rules)

The correct word from the rules page, which bails out here, is "Haftungsbeschränkung". Is there any ini, script or similar where the encoding can (has to) be tweaked?

UPDATE: I did a fresh install on the same server and changed a single entry (site name) in the setup section and got the following

Expand: errors and stack trace errors and stack trace


I keep getting php unserialize-errors as well. Are there any known issues with php 5.3.1, it doesn't look too nice so far.

Have a nice one,
Peter


Last edit: by Lowlander
Back to the top
 
Posted
Rating:
#59738
Avatar

Hi,

I think this is almost certainly purely a MySQL issue. There's something in our internationalisation tutorial on "MySQL collations" that might help.

Possibly it could be a case of a mismatch between the MySQL servers default collation settings for communication and the settings it is using on it's tables. Particularly if one is utf and the other is not.

The tutorial shows how you can set an option in info.php to force ocPortal to use a specific collation (you'd set it to whatever your tables are using).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#59745
Avatar

Community saint

I am no expert but I remember when my Host upgraded their PHP I also lost my site. It turned out to be changes in the way that php.ini and .htaccess are handled in the new PHP environment. Again I have no idea if this is your problem but you can check it out by temporarily removing those files from the Root of your site. If that works then that is the problem if not then you will need to look elsewhere. If it is those files then let me know, I can provide you with a copy of the ones that I now use that Chris has helped me with.

Rick Henson

OCP 4.3.2 & 5.0.1
PHP 5.2.5
MySQL 5.0.51a
FireFox 3.6.8
Back to the top
 
Posted
Rating:
#59753
Avatar

Well-settled

Hi Rick, Chris,

thanks for the really quick answers. I already gave the line

$SITE_INFO['database_charset']='utf8';
a try yesterday and noticed that the tutorial mentions (and maybe mixes up) collations and charsets. The parameter itself says charset and sets it to utf8 in the example, but the tutorial mentions collations as well, which would be utf8_unicode_ci in my case, according to phpMyAdmin.

I tried both 'utf8' and 'ISO-8859-1' with the info.php parameter, but that didn't change anything obvious. I removed the php.ini as well, but that didn't change anything either.

Has anybody got a running PHP 5.3.1 installation so far and could try and insert a single umlaut in a comcode page, please? In my vanilla parallel ocp installation (which has no German language pack at all) to edit the start page from 'Welcome' to 'Welcöme' is enough to provoke the error.

Another point I found in the logs is that magic_quotes_gpc has been deprecated as of PHP 5.3.0 and is scheduled for removal in PHP 6. Would that be relevant in any way?

The ocp pages themselves contain <meta content="application/xhtml+xml; charset=ISO-8859-1" http-equiv="Content-Type"> in their header, which isn't utf either. Is that taken from global.ini?


Last edit: by Lowlander
Back to the top
 
Posted
Rating:
#59757
Avatar

Hi,

If you're open to the idea of me having a look in your settings and debugging through it, please open a bug report ticket with the details I'd need to connect.

It's tricky to explain via a topic because probably there's some corrupt cache data in the database at this point that would need clearing at each step in the debug process.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#59762
Avatar

Well-settled

Chris,

I went through the tutorials but couldn't locate any hints how to clear the caches without being able to access the cleanup tools page itself. I guess that's done with some internal tool of yours?

OTOH, I'm wide open to the idea of having you look through my configuration, but I guess my main site is fubar right now and I have to restore the original php and mysql settings first, together with a file system that used to work on the old server and the corresponding database.

I could grant you access to my fresh (and English) parallel installation on the same server as well, for you to debug, so the right settings can be transferred to the main site later on. That may be the easier way, because on that installation there is only a single character edited-in on a single comcode page that provokes the error.
Back to the top
 
Posted
Rating:
#59763
Avatar

Hi,

I went through the tutorials but couldn't locate any hints how to clear the caches without being able to access the cleanup tools page itself. I guess that's done with some internal tool of yours?

Yes, there are ways.

If you want to go ahead with what you propose I'll try and find some time this weekend to take a look :).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#59767
Avatar

Well-settled

Chris,

thanks for your generous offer, I do really appreciate it! The installation is in a bit of a mess at the moment, and as my Filezilla is not able to delete empty directories for reasons I have yet to discover, I can't clean it up. And there's no one at the hoster's on weekends either. They claim to have found something and got it working now, but instead of the garbled startpage that was there yesterday there's just a critical error now.

The guys at the hoster's (who do all this stuff for the company I work at as well and have decades of experience - with other cms'es) said that setting the $SITE_INFO['db_charset'] parameter to 'latin1' (I had only tried 'ISO-8859-1') actually does make a difference. ocp seems to send iso characters to the database anyway, so setting utf here wouldn't make sense, because they suspect the parameter is what tells the database that there's iso coming, no matter if the database itself stores utf or not.

I'd like to get the installation a fresh start with backup data from the old server and vanilla ini files, but I'm not too confident I can do this on my own during the weekend, I'm afraid. I'll be back if there is news.
Back to the top
 
Posted
Rating:
#59775
Avatar

Well-settled

Hi,

We're finally up and running again! :thumbs:

I did the following: Get rid all the testing rubbish, restore files from backup, restore db from backup, edit info.php BEFORE trying to load any pages and add

Code

 $SITE_INFO['database_charset']='latin1';
Load start page without a glitch, login, go to admin zone and clear the caches. No further probs so far.

The php.ini is back to unedited server default (apart from the odd memory/upload size limit), the MySQL server/database/tables are all utf8 as can be, and still, latin1 was required.

Thanks to you guys for your patience and suggestions! The charset finally did it, but in a different way.

Have a nice one,
Peter
Back to the top
 
Posted
Rating:
#59791
Avatar

Hi,

Glad it works now.

It's a bit confusing, but this is the situation with MySQL…

Tables have a certain charset/collation (in MySQL the terms tend to be used interchangeably even though there is a difference), and this is completely separate from the charset that is used for database communication. If they do not match up then what happened to you can happen.
However actually I suspect the charset ocPortal is using is not matching up with what MySQL is using, which is a different problem I hadn't conceived before. Actually that makes a lot of sense- if MySQL is using UTF-8 throughout, and ocPortal is using ISO-8859-1, then it could definitely cause some problems when your extended ASCII umlauts etc are used. Most users being English (with our limited alphabet that is all in lower ASCII and hence interchangeably compatible with both latin1 and UTF-8) and because MySQL is usually left in latin1, it's not something that has come up before.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#59798
Avatar

Well-settled

Chris,

Chris Graham said

if MySQL is using UTF-8 throughout, and ocPortal is using ISO-8859-1, then it could definitely cause some problems when your extended ASCII umlauts etc are used. […] because MySQL is usually left in latin1, it's not something that has come up before.
Unfortunately I haven't got any tool to detect which charset is actually used by php for communication with MySQL. So it's difficult to tell whether the $SITE_INFO['database_charset'] parameter has to be set to the same charset as the database tables (that's how I understand the tutorial, but this is definitely not the case here) or has to bet set to the same charset php uses for database communication (at least all iconv-parameters are set to ISO-8859-1 in my php installation, don't know if that affects communication at all) or has to be set according to whatever ocp tries to send to the database. Which seems to be latin1 all the time.

Not sure if this is going to be more of an internationalisation issue now, but it seems that popup windows are encoded differently from main pages, or at least they are rendered differently, in both Firefox and IE.

When I try to delete a menu branch, a new window pops up (almost fullscreen in IE) asking for confirmation. That window contains what looks like utf8 characters, but the source says it's meant to be latin1. The characters in the URL are displayed correctly, so I think ocp gets them ok from the database. I'd very much like to upload a screenshot, but my files keep being rejected.

The menu branch doesn't get deleted either, btw. If I press any of the buttons, the window just disappears. I have to admit I'm starting to get a bit confused by now. O_o
EDIT: If I change the phrases that appear in the confirmatory window and its buttons back to special character free text, the buttons actually work annd the menu branch gets deleted.


Last edit: by Lowlander
Back to the top
 
Posted
Rating:
#59832
Avatar

Well-settled

Update: I think, I've got it. I took a deep breath and did the following:

  • clear all the caches, close any browser
  • download all custom language files an re-save them in utf-8 format in a local editor
  • change "charset" phrase in global ini from default English ISO-8859-1 to utf-8
  • upload all language .inis to server again
  • change database_charset parameter from latin1 to utf8 in config_editor.php
  • keep fingers crossed and access a page
  • Bob's your uncle.
Problem was now that the website cleanup page itself was apparently cached and bailed out when called. This was corrected by briefly disabling all caches in site setup, changing the database_charset parameter to latin1, calling the cleanup page in a different browser, and, while it was displayed, changing the database_charset parameter back to utf8 and clearing the caches again from the second browser and kicking the caches back in again.

All pages claim to be utf-8 in their source code view now and are properly displayed in FF and IE. The delete menu branch confirmation box displays and works properly as well. Minor glitch is that all comcode pages I created/translated so far bail out and have to be re-saved as utf-8. At least I do not have to edit them to correct the characters, it's just a matter of encoding.

I think the database_charset parameter in info.php has to match the charset-setting in global.ini, not the actual charset of MySQL. If anybody wants to know, really badly, I could do some more tests. What I don't want to know is what happens if you are using two language packs with different charsets (like DE and EN), but have only one database_charset parameter to set.

Have a nice one,
Peter
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: