FreePBX 13 BETA GUI Updater

There has been no change to this. Only new installs support utf8. Any upgrade will never correctly support utf8 as the collation settings vary depending on what you’ve previously done.

What I have previously done as in how I installed FreePBX?

I upgraded the (current) FreePBX distro so I didn’t choose the character set/collation sequence used…

What issues will this do if UTF-8 is not properly supported by FreePBX? I have retyped in one of the string that had been mangled and everything seems OK now but is it stored in UTF-8 or ISO-8859-1 in the database now, I am not quite sure (I am no MySQL guru, I am more used to dealing with Oracle servers…).

The characters I typed are supported by ISO-8859-1 though, maybe I should try with something which is not in ISO-8859-1 (which is probably what you used before FreePBX 13…).

edit: I just tried a character that needed ISO-8859-16 (I think) or UTF-8 and it got mangled so I guess my databases are definitely not in UTF-8…

Have a nice day!

Nick

Only new installs of FreePBX 13 support UTF-8. Sorry. Older databases can not be migrated.

UTF-8 was never supported in FreePBX 12 or lower. If it worked then that was a fluke. FreePBX 13+ is the only UTF-8 supported release and it has to be a new install.

You were probably using Latin1 (ISO-8859-1) which is what is needed for my native language so I never noticed anything…

I just noticed the “issue” when I upgraded my install…

Apparently there is a way to change the character set of databases (it probably doesn’t take care of non-ASCII characters though), see http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 .

but this woud probably not be supported…

(I would have been tempted to try though if I knew what the right values are supposed to be for a new install of FreePBX 13…)

What would be a supported way of changing the character set to UTF-8? Would doing a new install and restoring a backup work?

Thank you very much for your help and have a nice day!

Nick

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.

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: [FREEPBX-8057] Wrong charset in CDR records/connection - Sangoma Issue Tracker

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

1 Like

I’ve also logged this at: http://issues.freepbx.org/browse/FREEPBX-10031

The upgrade sems to have stopped with an error. The log on the screen says:

Submitting data to servers…Done
Running checks…Passed
Stage 1
Bumping FreePBX to version 13…Done
Checking online servers…Done
Downloading 13 Framework…Done
Installing 13 Framework…Done
Stage 2
ERROR: See Console

Not sure where to look for ‘console’, can’t see anything obvious in /var/log/syslog or /var/log/messages.

I have left my system exactly in this position so if there are specific diagnostic things that are useful at this point I can run them.

You need to look at the javascript console. Please provide us a way to access this machine. I have closed your ticket as I can’t do much from there. You are the first person to report this.

Which bits do you want opened up for more detail?

What happens when you run:

/var/lib/asterisk/bin/fwconsole

I get the FW console for version 13.0.1beta3.54

That is all you get??? Please paste a screenshot or the full output

Sorry, I get more than that, here you go:

You can proceed manually if you wish. Otherwise I would need to look at the system myself.

Happy to do that, but what do you mean by, “proceed manually”? I’m probably sounding dim here …

fwconsole moduleadmin upgrade core
fwconsole moduleadmin upgrade backup
fwconsole moduleadmin upgradeall

Thanks, will do, I’ll report issues (if any) here.

This might help. First command (moduleadmin upgrade core) output:

No repos specified, using: [standard,extended,unsupported] from last GUI settings

Starting core download…
Processing core
Downloading…
2287402/2287402 [============================] 100%
Finished downloading
Extracting…Done
Module core successfully downloaded
PHP Fatal error: Cannot redeclare superfecta_hook_core() (previously declared in /home/neil/git/Caller-ID-Superfecta/functions.inc.php:3) in /home/neil/git/Caller-ID-Superfecta/functions.inc.php on line 47
Whoops\Exception\ErrorException: Cannot redeclare superfecta_hook_core() (previously declared in /home/neil/git/Caller-ID-Superfecta/functions.inc.php:3) in file /home/neil/git/Caller-ID-Superfecta/functions.inc.php on line 47
Stack trace:

  1. () /home/neil/git/Caller-ID-Superfecta/functions.inc.php:47

For reference, although the path is different, I’m pretty sure that is an in sync version of Superfecta/functions.inc.php - I’ll check.

That’s your issue. You have an unsupported dev version of superfecta loaded. So the functions are all being loaded twice. This isn’t something we can account for.

No. The issue is that you have superfecta files in AMPWEBROOT that are referenced to /home and are being loaded twice.