Search options (Page 2 of 2)

Got the same issue with this different server/configuration.

Another pbm (not related to the previous one) :
in stage "conv_users", u start at id=2. Ok.
But in good localizations, the word 'Guest' had been translated (username, password and email).
So the guest user needs to be converted.
I added the following code (beginning of stage "conv_users") :

        // Convert 'Guest' user
        echo 'Converting guest user …<br />'."\n";
        $result = $db->query('SELECT username, password, email FROM '.$db->prefix.'users WHERE id=1') or error(__FILE__, __LINE__);
        $cur_item = $db->fetch_assoc($result);
        if (convert_to_utf8($cur_item['username'], $old_charset) | convert_to_utf8($cur_item['password'], $old_charset) | convert_to_utf8($cur_item['email'], $old_charset))
            $db->query('UPDATE '.$db->prefix.'users SET username=\''.$db->escape($cur_item['username']).'\', password=\''.$db->escape($cur_item['password']).'\', email=\''.$db->escape($cur_item['email']).'\' WHERE id=1') or error(__FILE__, __LINE__);

Yep, i know, that's why i said "it's not a big deal", but for consistency only, i think it can be done anyway...

Yes (what else ?)
I will try to redo the update in a few days (putting some 'echo' in db_update to really see what occurs).
For now, in order to continue the 1.3 beta test, i had to completly reconstruct my datas (based on a plain text save) and to do the encoding myself : i used the utf8_encode() function and it worked, so i clearly have no idea of what was going wrong with db_update (the difference is that db_update take the data from the old tables and my 'reconstruction' script take the data from a plain text file).

Reporting first test : updated a little French database (so with accentuated caracters in it)

- no errors, no warnings..
- the tables have been updated (latin1_general_ci -> utf8_general_ci), except 2 : forums_perms and subscriptions (not a big deal, but why ?).
- the new fields (like first_post_id in topics) and/or new indexes have been created.
- BUT the data HAVE NOT been converted to utf8... (accents remain in latin1 format)

Looked at db_update.php to find an 'obvious' reason... not found anything  : i couldn't say why the utf8_encode() didn't work.

Concerning speed :
As elbekko and Paul mentioned it, it's not a big issue (as far as the extension itself is well done), and i didn't mean to say that...
And i'm not saying i'm against the 'extension system', on the contrary i'm thinking it's the best improvement of the 1.3.
BUT i reaffirm it WILL be slower (than mods), it's automatic, you can't get rid of that.

Well, it's rather easy to test : write just a couple lines in php (try i.e an array declaration and fill it with some random data), measure execution time, then embed the previous lines in an eval() and compare..