Faster Converter to phpbb3

[q250]

Such boards should convert in a matter of minutes; there is one exception however: remotely linked avatars. Each remote avatar will be visited during the conversion which can take some time (we abort after a second, but that's still a lot).
~H

BINGO my board dont accept local avatars so about 60.000 from 91.000 users have remote avatar. 60.000 x 1 second is 16 hours -_- .... well... heh... um...

i will try remove them completly or comment/change this code as u say and posts result. Tommorow after Electric Exam :/.

ps
btw i dont really see point in checking them... why do that, conversion point is to make phpbb2 to phpbb3... so why not just copy link to this remote avatar without check? Board will be converted and purpose of conversion is just to convert.

[Kellanved]

phpBB3 requires the avatar's dimensions to render cleanly, thus people complained about distorted avatars post-conversion.

[Ash Hi Fi Zone]

In your case I think the best option may be to ignore the avatars completely and do not convert them at all... Then after conversion display an announcement saying all avatars were lost during the conversion and ask them to re-configure their avatars from UCP.... This loss wont be much.....

[code reader]

phpBB3 requires the avatar's dimensions to render cleanly, thus people complained about distorted avatars post-conversion.

here's an idea:
while converting, leave dimension -1/-1.
in functions_convert.php, change remote_avatar_dims() to work on one user only, and in addition to database updating, also return list($width, height), such:

Code: Select all

function remote_avatar_dims($user_id, $avatar)
{
    global $db;

        $width = (int) get_remote_avatar_dim($avatar, 0);
        $height = (int) get_remote_avatar_dim($avatar, 1);

        $sql = 'UPDATE ' . USERS_TABLE . '
            SET user_avatar_width = ' . (int) $width . ', user_avatar_height = ' . (int) $height . '
            WHERE user_id = ' . $user_id;
        $db->sql_query($sql);
        return array($width, $height);
    }
}

  

then, in functions_display.php, change get_user_avatar() so:

Code: Select all

/**
* Get user avatar
*
* @param string $avatar Users assigned avatar name
* @param int $avatar_type Type of avatar
* @param string $avatar_width Width of users avatar
* @param string $avatar_height Height of users avatar
* @param string $alt Optional language string for alt tag within image, can be a language key or text
*
* @return string Avatar image
*/
function get_user_avatar($avatar, $avatar_type, $avatar_width, $avatar_height, $user_id, $alt = 'USER_AVATAR')
{
    global $user, $config, $phpbb_root_path, $phpEx;

    if (empty($avatar) || !$avatar_type)
    {
        return '';
    }

    $avatar_img = '';

    switch ($avatar_type)
    {
        case AVATAR_UPLOAD:
            $avatar_img = $phpbb_root_path . "download.$phpEx?avatar=";
        break;

        case AVATAR_GALLERY:
            $avatar_img = $phpbb_root_path . $config['avatar_gallery_path'] . '/';
        break;
        case AVATAR_REMOTE:
            if ($avatr_width == -1 || $avatar_height == -1)
            {
                if (!function_exists('remote_avatar_dims'))
                {
                    // the details are left as an exercise to the reader
                }
                list($avatar_width, $avatar_height) = remote_avatar_dims($user_id, $avatar);
                // this call has a side-effect of updating user_avatar_width and user_avatar_height in the db.
            }
        break;
    }

    $avatar_img .= $avatar;
    return '<img src="' . $avatar_img . '" width="' . $avatar_width . '" height="' . $avatar_height . '" alt="' . ((!empty($user->lang[$alt])) ? $user->lang[$alt] : $alt) . '" />';
}  

this is just an illustration. you would also have to modify all the places where get_user_avatar() is called to add the $user_id parameter.
the nice thing is that you move the dimension-finding stage from the conversion to the point where each avatar is first used.

[Nicholas the Italian]

Alternatively, you could move the retrieve_dimensions stage before conversion.
E.g., you make a program that uses the convertor function to find all avatars dimensions, build an array like [avatar_url,width,height], and modify the converter to try to get dimensions from such array; now you can run the "retrieval program", taking X hours, before converting, and use the outcome during conversion.
Just an idea, not sure it would work...

[Kellanved]

@code_reader - we considered such things, but we don't want that much "conversion code" in the fixed codebase. Not too far in the future, converted boards will be the exception and not the rule. We know that the user table is painful to convert, but we trust big board admins to be able to adjust the code to their needs, especially so the converter.

Most boards we examined had a relatively small share of remote avatars; gallery and no avatar being the most common cases. With most servers reacting in less than a second and a strict one-second timeout, we have a pretty good - albeit not perfect - compromise.

[wintermute]

Kellanved, speaking of remote avatar checking, is there any work done for the users who entered some local file address for their avatar URL? You may remember I dropped you a hint about addresses like "C:\DOCUMENTS\MY_AVATAR.JPG" breaking the converter layout with ugly error messages at the top.

Many thanks,

[EXreaction]

Install a temp phpBB3 forum on your server if you don't already have one, then test to see if MYSQL fulltext searches work on your server or not.

If your server supports MySQL fulltext searches then you can skip the search tables (which usually make up the far majority of the database size) when you backup and upgrade. Then after your done upgrading just make sure your search backend in phpBB3 is MySQL (and have it run the index option for it in the ACP).

Just a way you can probably cut down 1/3-1/2 the size of the database without loosing anything important (unless your server doesn't support MySQL Fulltext).

[code reader]

If your server supports MySQL fulltext searches then you can skip the search tables (which usually make up the far majority of the database size) when you backup and upgrade. Then after your done upgrading just make sure your search backend in phpBB3 is MySQL (and have it run the index option for it in the ACP).

actually, there is no way to tell phpbb2 to skip any specific table on backup, and the upgrade 2 => 3 does not use or touch these tables anyway.
once you're done upgrading, you need to either build those tables (ACP => Maintenance => Search Index) or build the mysql fulltext search index (same place).

as to using the fulltext mysql rather than the "fulltext native": the jury is still out regarding which of these options is worse. for small (< ~20K posts) forums it doesn't make much of a difference anyway, and for large forums neither is good enough (eg., phpbb.com uses neither, and instead uses a system called "sphinx").
both of them are pretty bad. in addition, fulltext-mysql implementation is about twice as bad as it really need to be, because olympus maintains three indexes (post-subject, post-contents, and post subject+content), where it should have maintained only two (topic title and post subject+content). this causes the index to be twice as large as it should have been, and posting and editing to be twice as slow as they should have been.
with the double-indexing, the db size using fulltext mysql is not much better than it is when using fulltext native.

[EXreaction]

actually, there is no way to tell phpbb2 to skip any specific table on backup

phpMyAdmin