Smartys wrote:

You are not supposed to be changing that. wink

Well, maybe, but it still COULD HAVE BEEN translated.. and the cost in attempting to convert it is nothing for the update process.

Note for those who want to use the code i provided : it needs to be placed within the "if ($start_at == 0)" block (as we need to do it only once).

Actually, the word 'guest' should be put in the lang pack, rather than hardcoded in install.php...

Mpok wrote:

I will try tomorrow another test on another server (MySql 4.1.22), cause i'm thinking the problem could be related to server configuration (default charset used by the server).

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__);
Rickard wrote:

Mpok: Any information you can provide that would lead us to a fix would be greatly appreciated.

So, i've restored my old 1.2 database and tried the update again (this time, looking carefully what occured).

Note : config = MySql 5.0, converting from ISO-8859-1 on a french server.

-> all seems ok until "stage conv_tables" (so the convert_to_utf8() function works fine).
And then, the conversion of the text columns (the 'CHANGE' ... text -> blob -> text) seems somehow to REVERSE all the work done in previous stages (conv_topics, conv_posts, etc...).
This is why when viewing data in phpMyadmin the conversion seems to not have be done (and obviously the display in the forums isn't ok, accentuated characters appear as '?').

I managed to have a correct display in the forums : replacing the double 'CHANGE...' thing in convert_table_utf8() function by a single 'MODIFY... CHARACTER SET utf8'.
Now, my data are well displayed, but i'm really not sure it is a "fix"...

I will try tomorrow another test on another server (MySql 4.1.22), cause i'm thinking the problem could be related to server configuration (default charset used by the server).

Rickard wrote:

Because those tables don't have any text/varchar fields, only integers.

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...

Rickard wrote:

What was the old encoding, ISO-8859-1?

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).

30

(99 replies, posted in PunBB 1.3 additions)

Meant to ease precisely these "certain cases"... wink
But it's not a big deal anyway.

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.

32

(99 replies, posted in PunBB 1.3 additions)

Smartys wrote:

I hope not, since the English language packs aren't even done.

[Request] : please keep (as much as possible) the organization of the different keys as it was in 1.2, that will ease the translation process, as we can see (with program like 'Winmerge') the keys which are common to the old version (the translation of these is more likely the same it was).

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.

Smartys wrote:

If someone would like to benchmark them for comparison, they're welcome to do so.

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..

34

(99 replies, posted in PunBB 1.3 additions)

Jérémie wrote:

I will very probably do French.

@Jérémie : the official support of PunBB in French (and provider of the french language pack) is Punbb.fr.
Ur welcome to contribute if u wish...
Note: we (the staff at punbb.fr) don't already have planned neither begun anything on 1.3 localization, we're just beginning to test, so if u have parts already done, it will be appreciated.

Smartys wrote:

1. We haven't done benchmarks, so we don't know. But yes, I would presume that any difference in speed isn't drastic.

Well... Adding new features DOES cost time processing. Always. wink
I.e., the simple fact of changing way of construct requests (which permits further modifications with hooks) IS slower than a 'plain text' request, but the difference is indeed negligible.
Another one : use of url_rewriting IS time comsumming (rather an Apache's issue, as the process of a .htaccess is not optimized), but the feature itself is real great..

And last but most important : the entire 'hook system' (which is the major benefit of 1.3) IS slower than the old ugly 'mod system' (since the eval() function is one of the slowest function in PHP, as it is in C or others).

So each 'extension 1.3' will be slower than the corresponding 'mod 1.2' (by construction)...
Hope it "isn't drastic", as u said..