FreePBX 13 BETA GUI Updater

A few weeks ago we pushed out the first beta release of FreePBX 13.  This beta was primarily pushed out as a manually install tarball and beta distro release for our advanced users. These community members and our internal testers have been testing and ironing out bugs to allow expansion to a wider audience. Our desire is to be as stable as possible even in beta for our community.

updprog

Two weeks ago we did a soft launch of our GUI Update utility.  This allows anyone running  FreePBX 12 to upgrade to 13 by way of the FreePBX UI. If you are running FreePBX 12 you can go in to Admin -> Module Admin and click check online.

upgrader

Keep in mind that we have done our best to make sure this is safe enough for production use but we cannot account for all use cases. There are likely still bugs unaccounted for and you may be the one to find them. Before updating please make a backup. As a BETA this is not recommended for production use.

We put a heavy focus on the core open source code that is FreePBX. If you use any of our premium add on modules to enhance the FreePBX experience, they may not be fully functional.  If you use commercial modules update with caution.

Please file a ticket for any bugs you find at http://issues.freepbx.org

Please give feedback and feel free to ask questions on our forums at http://community.freepbx.org

Thank you for using FreePBX

 

 

Notable Replies

  1. el_es says:

    Looks nice,
    in case this wasn't covered somewhere: would there be a 'walkthrough' guide for converting from chan_sip in d&e mode to pjsip ?

  2. tm1000 says:

    That has a way of corrupting data. Which is why we don't migrate old databases automatically. You can do it yourself of course and it'll probably be fine.

    Note: ALTER TABLE tablename CHARACTER SET utf8 only sets the default char set on a table which is used for newly created columns. It does not convert existing columns that already have a char set set.

  3. I was able to get it to work to my liking using one of the recipes on the web page I referred to...

    The accents/special characters were already mangled and I was willing to correct the entries which had them so as long as I was not losing anything else I was ok with correcting any mangled entry...

    I also had a very recent backup (yesterday)...

    I did many tries (restoring from my backup after each).

    Essentially what I ran was this:

    DB="asterisk"
    (
        echo 'ALTER DATABASE `'"$DB"'` CHARACTER SET utf8 COLLATE utf8_unicode_ci;'
        mysql "$DB" -e "SHOW TABLES" --batch --skip-column-names \
        | xargs -I{} echo 'ALTER TABLE `'{}'` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;'
    ) \
    | mysql "$DB"

    and

    DB="asteriskcdrdb"
    (
        echo 'ALTER DATABASE `'"$DB"'` CHARACTER SET utf8 COLLATE utf8_unicode_ci;'
        mysql "$DB" -e "SHOW TABLES" --batch --skip-column-names \
        | xargs -I{} echo 'ALTER TABLE `'{}'` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;'
    ) \
    | mysql "$DB"

    I modified the script I had to use the UTF-8 collate sequence documented here: http://issues.freepbx.org/browse/FREEPBX-8057

    The first time I tried this it didn't work, I got the following error message

    ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes

    This was caused by the table asterisk.faxpro_hook_core which is used by the "Fax Configuration Professional" module. Wanting to play it safe I restored from my backup and I then deinstalled it the module (so that it would remove the table cleanly).

    I reran both scripts.

    This time it completed successfully...

    I then reinstalled the "Fax Configuration Professional" module and disabled it (this is what I do with modules I don't currently use but are part of the distro, I don't normally uninstall them.

    It recreated the table but now the page and id fields (which are part of the key) are no longer 255 characters long but 150... I guess with the conversion to UTF-8 the key was now too long (the max is 1000 for the type of index used on this table apparently) and has been shortened... As this table was created before I switched to FreePBX 13 it had the old length...

    I then tried to enter characters which were not supported by Latin1 (ISO-8859-1)...

    I tried characters which needed ISO-8559-16 (or a variant of Unicode) and even Cyrillic and both were correctly handled...

    (I have a very basic understanding of Romanian and Russian...)

    I then fixed all the entries which had their characters mangled because of the initial upgrade to FreePBX 13, there weren't that many...

    The only problem I noticed is that some screens seem not to handle the apostrophe (ie ' ) correctly but I don't think this is related to runing this script, they probably need to escape them. The IVR screen (IIRC) did but you see the backslash it precedes the apostrophe with in some places while the time group screen seems to discard an entry that has it altogether (probably because the SQL fails to execute because of that (most likely unescaped) apostrophe...)...

    Obviously this is not for everyone but as for me I am happy with the results... The accents/special characters were already mangled to begin with so as long as I wasn't losing anything else I was ok with correcting them after...

    Thank you and have a nice day!

    Nick

  4. tm1000 says:

    This is why include_once and require_once are unreliable as they work based on paths.

  5. tm1000 says:

    Clear cache/cookies.....

Continue the discussion community.freepbx.org

44 more replies

Participants