Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

1.0.1 issues

1235»

Comments

  • 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.
  • edited September 2006
    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?
  • Max_BMax_B New
    edited September 2006
    @Ø: 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.
This discussion has been closed.