Blog Documentation Book a Demo
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

124

Comments

  • MarkMark Vanilla Staff
    I added it up there :)
  • bugsmi0bugsmi0
    thanks Mark excellent, and to think I inspired that (tears) makes me feel so gosh darn special lol
  • MarkMark Vanilla Staff
    :D
  • pbearpbear New
    the bearly visible link...

    I'm the bearly visible one around here, what with this white background... ;)
  • Max_BMax_B New
    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.
  • Arturo G.Arturo G.
    @Max: I have tried your script and I get exactly the opposite result. See this

    image.

    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.
  • Max_BMax_B New
    @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.
  • Arturo G.Arturo G.
    @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!
  • alnoktaalnokta
    edited August 2006
    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)...
  • tthmaztthmaz
    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?
  • SlashedZeroSlashedZero
    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.
  • Max_BMax_B New
    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.
  • alnoktaalnokta
    @Max_B : I didn't fully understand what you said ... I think this is the installer's problem .. not me...
  • Max_BMax_B New
    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.
  • SlashedZeroSlashedZero
    edited September 2006
    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!
  • Max_BMax_B New
    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.
  • Max_BMax_B New
    @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.
  • tthmaztthmaz
    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?
  • alnoktaalnokta
    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?
  • Max_BMax_B New
    @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.
This discussion has been closed.