MySQL 5
Moderator: Extend-A-Story Moderators
-
- Posts: 88
- Joined: Sat Aug 19, 2006 4:34 am
- Location: Evansville, IN
- Contact:
- lordreaibn
- Posts: 313
- Joined: Fri Mar 31, 2006 3:31 pm
- Contact:
I am using the stock version of Extend-A-Story, yes. Sorry for the delay. Do you think I should reinstall 2.1.1? Would that help?Sir Toby wrote:I just restored your database onto a virtual machine and set up Extend-A-Story on that machine. When I try to read episode 3762, the episode you linked me to earlier, I see the full content. I tested with versions 2.1.0 and 2.1.1 of Extend-A-Story, since those are the versions that are compatible with your database backup. There has to be something on your end that is causing the content of some of your episodes to disappear.
Are you running the stock version of Extend-A-Story, or have you made some changes to the code?
- Sir Toby
- Site Admin
- Posts: 413
- Joined: Sat Apr 26, 2003 3:42 pm
- Location: Portland, Oregon, USA
- Contact:
Based on what I've read so far, I'm not sure if reinstalling 2.1.1 would help, but it shouldn't cause any problems and shouldn't take too much effort.. You will just have to make sure you don't overwrite your database settings (db.php) or any images you are using for episode schemes. I'd backup your existing install before making any changes, just to be safe.lordreaibn wrote:Do you think I should reinstall 2.1.1? Would that help?
For now, I will work on the assumption that reinstalling 2.1.1 doesn't fix anything. With that assumption, I am left with believing that there is some different between your server and my server that is interacting poorly with Extend-A-Story in some circumstances.
It would be useful to see additional episodes that are experiencing this problem. Do you have any other problem episodes that you can link me to?
I will probably want to see the output of running the phpinfo() function on your server. Do you know what this is and how to get the output? I can step you through it if you need.
- lordreaibn
- Posts: 313
- Joined: Fri Mar 31, 2006 3:31 pm
- Contact:
http://www.horsehockey.org/read.php?episode=9115
http://www.horsehockey.org/read.php?episode=6923
are both having the problem.
http://horsehockey.org/info.php
There you go. I will remove it when we are done.
I just recently updated PHP on my server from PHP4 to PHP5.4 - this was done via global change from my web providers control panel.
http://www.horsehockey.org/read.php?episode=6923
are both having the problem.
http://horsehockey.org/info.php
There you go. I will remove it when we are done.
I just recently updated PHP on my server from PHP4 to PHP5.4 - this was done via global change from my web providers control panel.
- lordreaibn
- Posts: 313
- Joined: Fri Mar 31, 2006 3:31 pm
- Contact:
- Sir Toby
- Site Admin
- Posts: 413
- Joined: Sat Apr 26, 2003 3:42 pm
- Location: Portland, Oregon, USA
- Contact:
Okay... I've done some digging and I may have found what is causing this problem.
First, I took a look at the four episodes that people have shown to me. One thing that I noticed is that all four contain extended ASCII characters. Examples of these characters include the registered trademark symbol [®] (seen in episode 3762), magic quotes [“ and ”] (seen in episodes 6923 and 9115), and ellipses […] (seen in episode 7623).
Next, I noticed that you are using PHP 5.4.X while I am using PHP 5.3.X. I look a look at the release notes for PHP 5.4.0 and found this:
My best guess for what is going on is that the affected episodes were written before you started using PHP 5.4.X and saved in your database using the ISO-8859-1 encoding, which was the default for PHP until PHP 5.4.X. Now that you are using PHP 5.4.X, PHP doesn't understand those episodes, and is treating them as if they are blank.
Now the question becomes what to do about the situation. It looks like there is an option in php.ini to set the default character encoding for PHP. If you have access to change settings in php.ini, you could just set the default character encoding back to ISO-8859-1. If you can go back to an earlier version of PHP, that might be an option as well. However, any episodes with extended ASCII characters written since you switched to PHP 5.4.X will be stored in your database as UTF-8, and will be broken if you switch the character encoding back. Unfortunately, I can't think of any easy path out of this problem.
Anyways, take a look and let me know if you think this might be the problem. If so, we can consider how to get everything straightened out. As always, I recommend backing everything up before making any changes.
First, I took a look at the four episodes that people have shown to me. One thing that I noticed is that all four contain extended ASCII characters. Examples of these characters include the registered trademark symbol [®] (seen in episode 3762), magic quotes [“ and ”] (seen in episodes 6923 and 9115), and ellipses […] (seen in episode 7623).
Next, I noticed that you are using PHP 5.4.X while I am using PHP 5.3.X. I look a look at the release notes for PHP 5.4.0 and found this:
I am not an expert on character encodings. Extend-A-Story does nothing to handle character encodings in any particular way. Instead, Extend-A-Story relies on the default behavior of PHP. Feature Request 18 is intended to update Extend-A-Story to handle character encodings properly. Unfortunately, that feature request has not been implemented yet.Changed default value of "default_charset" php.ini option from ISO-8859-1 to UTF-8.
My best guess for what is going on is that the affected episodes were written before you started using PHP 5.4.X and saved in your database using the ISO-8859-1 encoding, which was the default for PHP until PHP 5.4.X. Now that you are using PHP 5.4.X, PHP doesn't understand those episodes, and is treating them as if they are blank.
Now the question becomes what to do about the situation. It looks like there is an option in php.ini to set the default character encoding for PHP. If you have access to change settings in php.ini, you could just set the default character encoding back to ISO-8859-1. If you can go back to an earlier version of PHP, that might be an option as well. However, any episodes with extended ASCII characters written since you switched to PHP 5.4.X will be stored in your database as UTF-8, and will be broken if you switch the character encoding back. Unfortunately, I can't think of any easy path out of this problem.
Anyways, take a look and let me know if you think this might be the problem. If so, we can consider how to get everything straightened out. As always, I recommend backing everything up before making any changes.
- lordreaibn
- Posts: 313
- Joined: Fri Mar 31, 2006 3:31 pm
- Contact: