Not signed in (Sign In)
Categories
Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.
Help keep Vanilla free:Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.
-
Great!
I've updated getvanilla.com with the updated zip. For anyone else that comes in here with the same problem, get the latest version and you should be good to go. -
Working like a charm! Thanks a lot.
-
Mark,
What was the problem in the previous vanilla 1.0.1 zip package?
I downloaded the zip fle last night once I got the notification email from you and installed it on my server. Are there any new changes in the upadated zip 1.0.1 package? -
There were a couple of changes, but the only one that was consequential was the removal of two lines of code from library/Framework/Framework.Class.MySQL.php. It shouldn't affect installations that are english-character driven.
-
- CommentAuthorThomas Heath
- CommentTimeAug 22nd 2006
@Wanderer: Welcome back to Vanilla ;-) -
Thanks Thomas, I never really left, I've been lurking...
-
-
CommentAuthorDraganBabic
- CommentTimeAug 22nd 2006
Mark, this fix works like a charm, I have upgraded and it works flawlessly.
Thanks for all the good work and effort you put into this project! -
-
I have updated my test installation to 1.0.1. I'm using latin1-spanish, and it works perfectly. I will test extensions and upgrade my real installation soon.
Thanks to all of you for your support to Vanilla. -
it wouldn't be a bad idea if the getvanilla link was added to the top of the page with the other links for easy access
-
Vanilla 1.0.1 <—(this is a link) is a product of Lussumo.
More Information: Documentation, Community Support. -
oh you mean the bearly visible link that nobody can see ? lol
I was refering to the links at top of the page in the banner area that seems to make good sense to put it there, -
I added it up there :)
-
thanks Mark excellent, and to think I inspired that (tears) makes me feel so gosh darn special lol
-
:D
-
the bearly visible link...
I'm the bearly visible one around here, what with this white background... ;) -
For any folk here using non ascii strings (non english), and savy ehough with PHP and MySQL, I posted a small test script to illustrate the utf8 problem ang suggesting a way to clean those unsafe database strings.
-
@Max: I have tried your script and I get exactly the opposite result. See this
.
I'm using latin1-spanish all across my system and I have configured phpMyAdmin to work with both utf8 and latin1 obtaining the same results. -
@Arturo: Yes, I should have precised that this script is useful for an uff8 configured system. Your base is latin1. The standard client charset is then OK for you.
I understand that Mark has plan to configure this client_charset variable, then you can stay latin1.
Anyway my recommendation is to switch toward utf8 allover, as soon as possible, because you have then a system able to cope with ANY language or character, even a spanish board may need to display French or Russian chars.
This script was posted to illustrate charset on-fly connersion. Once you understand the concept, you can use it (the concept, not the script) to convert you base content.
The MySQL manual chapter about charsets and collations is the ultimate reference. -
@Max: Clear! I understand the problem. It is better to resintall the system as utf-8 before more information is stored in the database, because I don't know when it would be necessary to move to utf-8 anyway.
Thanks! -
Well I have a new issue ... I installed another copy of vanilla 1.0.1 ... during the insallation I gave the board an Arabic name(I haven't done that before with vanilla 1) so it may be an issue for 1 and 1.0.1 as well ... the problem was that after completing the installation and logged in .. I found that board name isn't showing correctly and showing strange characters .. so I tried to change the encoding from Unicode to Arabic (Windows-1256) .. it worked but it is so annoying that I have to change the encoding for every page I view ... So after a while I thought about re-entering the title of the board and the banner title in the Application Settings and I was lucky .. it is now working ...... so the question is .. why the installer couldn't enter the titles correctly? if you could take a look at it I would appreciate it much ...
EDIT: by the way .. my MySQL's charset is UTF-8 Unicode (utf8)... -
Hi,
When I delete a discussion (using one of the addons) or sink a disucssion, an error appears at the top of the page:Warning: mysql_data_seek(): Offset 0 is invalid for MySQL result index 136 (or the query data is unbuffered) in /home/console/public_html/engineersvoice/library/Framework/Framework.Class.MySQL.php on line 114
What went wrong and how can it be fixed? Thanks? -
I ran into exactly the same problem than alnokta. I used Steve's SMF to Vanilla migrator, which worked perfectly except for the french characters. All of them were replaced by a "�". I guess it's also the same issue I had earlier on the community forum. I was unable to login because my "Ø" had changed to something else due to an update. And now, I can't log in my fresh forum without switching to ISO-8859-1 in my browser. However, any new comment or change is correctly displayed.
-
Please, all of you guys, we are always on the same recurrent point on this charset problem.
Searching for utf8/utf-8 on this board and the dev one will give several discussions explaining the problem and solution:
forum charset | connection charset | database charset
latin1 | latin1 | latin1 = OK
latin1 | latin1 | utf8 = OK
utf8 | utf8 | utf8 = OK
utf8 | utf8 | latin1 = OK
utf8 | latin1 | latin1 = WEIRD!
utf8 | latin1 | utf8 = WORST!
The connection (made by PHP) default to latin1 so many Vanilla installations are running on the last setting scheme because the forum was set up as utf8 ignoring the connection stage. The connexion MUST reflect the charset of the board.
There is no miraculous solution beside translating any unsafe database content.
About migrator scripts, I did'nt check any, but they must also take care of this charset issue OR they deliver bad coded strings. -
@Max_B : I didn't fully understand what you said ... I think this is the installer's problem .. not me...
-
Yes, there is definitely an installer/Vanilla problem, because it does not reflect the charset used for the forum to the connection.
It's on Mark's todo list, but as time pass, more and more data get into base with incorrect encoding. -
Sorry to bring back this discussion again, but I've just found another encoding problem which was not reported yet, as far as I know. The terms of service don't display international characters correctly in latin-1. However this time they aren't replaced by a "?", but by other characters combinations. For example, "é" are replaced by "é".
I'm not sure if reporting this is useful or not, but I was just wondering why this replacement is different than on other parts of the forum. According to Max_B, my case should match with this:utf8 | latin1 | latin1 = WEIRD! -
This is another issue, the term of service link open a new window to display termofservices.php. This file does not include header.php nor any meta element so the encoding is left to the browser, wich default most often to latin1, while the text is utf8 encoded.
Simple issue but good catch anyway, maybe should you (Ø) report it in a separate discussion, I'm not sure Mark is still watching this one. -
@alnokta: BTW, if your base is still brand new or you want to start a new one, the solution (patch) is decribed here.
Mark included it in 1.0.1 but many Vanilla users in "WEIRD" or "WORST" situation got scrambled content and he dropped it.
While a more robust migrator is not available, this is the current state. I'm using the patch above to keep my base content clean but this is only ok if you do it from the start. -
This line below shows up when I search for a user by their username
Notice: Undefined variable: Switch in /home/console/public_html/engineersvoice/themes/search_results_users.php on line 5
How do I fix this? -
Thanks Max_B .. I will try this soon... but you said:
"I'm using the patch above to keep my base content clean but this is only ok if you do it from the start."
Does this issue affect any other thing beside what I've mentioned? -
@alnokta: I didn't check it, but after the issue reported above by Ø, there is a chance that your specific problem is of the same kind (installer lacking utf8 encoding) and not from forum/connection/base disperancy.
But yes the point I was talking about do affect the whole base content and you are probably in the "WORST" case I listed if your base is utf-8. So if you are in early stage, have a look at the patch to avoid filling your base with incorectly encoded strings. -
I'm not sure about forcing the users to signup again and losing the few discussions created so far ...
Can you look at the Arabic text in the database(http://img164.imageshack.us/img164/1055/viewtxtig2.png)? it shows this strange characters but when viewed in the browser(alnokta.ignorelist.com/translato) it shows just fine ...... -
YAY! I managed to fix this damn encoding problem with the patch above :D
Thanks a lot to Max_B and 130 for this solution. I needed to make a fresh install as suggested, but now everthing works fine except, for some strange reason, the board's title which still displayed some "?" where special characters were supposed to be. Not a big problem since changing and saving the title fixed it. I used Steve's SMF to Vanilla migrator after the fresh install and all of the imported posts were correctly displayed, which means this issue had nothing to do with the migrator. -
Uh oh, looks like I spoke too fast...
My local install of Vanilla works perfectly, but I've a problem with my host. Looks like they're running an older version of MySQL which doesn't support this part of the patch:CREATE TABLE LUM_bla_bla (
...
) DEFAULT CHARACTER SET utf8;
My MySQL version is 4.1.14 on local and 4.0.25 on my host. I get the following error when I try to install vanilla or import my local vanilla database:-- phpMyAdmin SQL Dump
-- version 2.8.2.4
-- http://www.phpmyadmin.net
--
-- Serveur: localhost
-- Généré le : Mercredi 13 Septembre 2006 à 20:05
-- Version du serveur: 4.1.14
-- Version de PHP: 4.4.4
--
-- Base de données: `uberclub`
--
-- --------------------------------------------------------
--
-- Structure de la table `lum_category`
--
CREATE TABLE `lum_category` (
`CategoryID` int( 2 ) NOT NULL AUTO_INCREMENT ,
`Name` varchar( 100 ) NOT NULL default '',
`Description` text,
`Priority` int( 11 ) NOT NULL default '0',
PRIMARY KEY ( `CategoryID` )
) ENGINE = MYISAM DEFAULT CHARSET = utf8 AUTO_INCREMENT =16;
MySQL a répondu:Documentation
#1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT CHARSET=utf8 AUTO_INCREMENT=16' at line 7
It appears to have something to do with rewriting subqueries but my very limited MySQL understanding stops here... Is there someone kind enough to tell me what syntax I should use to make the bastard swallow my mysql.sql file? -
@Ø: No future. Your problem is Mark's one: to be compatible with several Mysql versions. There is a HUGE difference between 4.0 and 4.1 regarding charset encoding. You can't define utf8 as a charset in pre 4.1.
My suggestion, until your provider switch to 4.1 or you switch your provider, set-up you base, locally, as latin1, keep the patch active. Then you will be in this state :forum charset | connection charset | database charset
utf8 | utf8 | latin1 = OK
This is correct and fully fonctionnal (all version)... If you don't need to use non-latin character. When exporting your local base to clone it to your production site, use the option in phpMyAdmin to write 4.0 compatible sql. In the future if you want to switch your base to utf-8, you'll have to apply some migration command, or hope Mark (or me when I have time in 1or 2 month) will offer a migrator to do this task.
Edit: Sorry, this scheme will NOT work if you plan to move data forth and back between both servers, because the 4.1 will store correctly encoded latin1 and the 4.0 raw utf-8. If you want to move data between the two bases you are stuck to stay "WEIRD" and have the two bases in latin1 WITHOUT the patch (that's why Mark pulled it of).
@alnokta: If you phpMyAdmin is using utf8 (check the opening page) you definitely are in the "WORST" state. I'd NOT let a base growing in this state because it'll be much more difficult to clean afterward. Your base content is in a non-encoded state using a non-existent charset!
If you can use > 4.1 MySQL everywhere (developement and production), I advise you to work out and clean this up.
To avoid typing existing comments again, you can do this:
- Set up a second forum somewhere. Make it utf8 clean, using the patch.
- Copy/paste manually between the two forum. This is not a funny task, but if you are not skilled enough to write a PHP/Mysql script to do it, this is the only way I see. -
Please Max_B ... bear with until this issue is sorted out ...
My phpmyadmin is using at the front page "utf-8" and in vanilla's tables(Collation) using this "latin1_swedish_ci"
The host is using 4.1.21-standard ...
"Copy/paste manually between the two forum. This is not a funny task, but if you are not skilled enough to write a PHP/Mysql script to do it, this is the only way I see."
Lets forget about me writing that sort of script .... but what exactly to copy? I figure it is the discussions because the only way to see the arabic text is through vanilla ... but what about the users ? can I just drop the table in the new installation and import(by myadmin) the old table? and how do I assign the users their discussions and comments after that? -
@Ø: No future. Your problem is Mark's one: to be compatible with several Mysql versions.
Okay well, I guess I'll wait for my host to upgrade their MySQL servers... I'll design a style or two to keep me busy until it happens, I'm better with Photoshop than with PHPMyAdmin :) Thanks for your explanations Max_B, now I understand a little better the nature of the problem. -
@alnokta: Well, I'd like to help... But its not easy whithout scripting and testing the process.
Here is a possible path:
• create a new database, with default charset=utf-8, the collation is only for sorting so the general_ci will be ok. Be sure that everything is utf8 in phpMyAdmin also (language, base, connection)
• patch a copy of Vanilla as described in the post referenced above.
• install this patched Vanilla on that empty base to create tables. They will default to utf-8.
• log out from the new vanilla forum
• in phpMyAdmin export from the first base, the DATA ONLY.
• in phpMyAdmin import this data to the new base.
At this step you will be disapointed to see that the content of your new base is still "dirty". This should only concern LUM_Comment and LUM_Discussion tables as I saw that you users, categories etc. all have latin names.
• In a separate browser window log in the original Vanilla forum. Display a dicussion/comment with arabic text.
• in phpMyAdmin window, edit the relevant item in LUM_Comment and LUM_Discussion tables by copying and pasting text between the two windows.
• repeat for each item with "dirty" strings (arabic or anything not ascci).
Now all the base content should be clean when wiewed with phpMyAdmin.
• Log out the original Vanilla
• Log in the new, patched, Vanilla.
Everything should be clean here too. Try adding a new arabic text in comment and check it displays correctly in phpMyAdmin.
All this work to clean a forum wich seems ok may appears unnecessary. I think it's worthwhile.
Notes:
1 - This will not prevent the new patched Vanilla from some glitches here and there as we have seen that there are a few script files lacking encoding information, installer, term of service etc. But the mainly the installation is clean.
2 - Be sure phpMyAdmin and Vanilla uses a font with arabic glyphs. In some place of Vanilla the css specify a font unable to fully display ciryllic text on my Mac, for exemple
Disclaimer: I have not time left to test this whole process, and I outlined it "theoritically". I may have forgotten something and there is no warranty of success. You have your original Vanilla install intact anyway, don't you. -
@Max_B : I don't know what to say ... your instructions is a life saver ... THANKS a lot ...
Everything went fine except I got annoyed by all the copy and the paste stuff ...
Though the 'rules' didn't show in the 'Rules & Permissions' but it isn't a problem ...
Now I just have to add the extensions again ..
But I have a question .. when I did this I installed it in the folder "translatox" while the original is "translato" ... is it possible to rename the folder 'translato' to anything else and rename 'translatox' to 'translato'?
Thanks again ... -
alnokta wrote:
But I have a question .. when I did this I installed it in the folder "translatox" while the original is "translato" ... is it possible to rename the folder 'translato' to anything else and rename 'translatox' to 'translato'?
This should not be a difficult task, look for "translatox" in the conf/settings.php files and replace with "translato". Do the reverse on original setup if you want to be able to use it.
Glad you worked it out and the process was correct.
Maybe it deserve some attention for other folks with non ascii charset especially for non latin.