We have a custom module on a couple of our sites. I am doing the upgrade from zk1.1 to 1.2. All has gone well, and all is functional, but on the custom module the tables were not converted to UTF-8. During the upgrade, the page reported "SKIPPED..." for each of these tables. Why?
All the other tables were converted. The upgrade is very conservative; only the core was upgraded, there are still quite a few 1.1 modules in it, so it wasn't just 1.2 specific modules that were converted.
Watch
GitHub Core
Show your support for Zikula! Sign up at Github account and watch the Core project!
GitHub Modules
- rgasch created topic »Using PageUtil::addVar() to load script code« 11:48 AM
- michiel responded to »password problem« 10:01 AM
- mazdev responded to »Hide "Register new account" and change template to 3 col« 07:50 AM
- mesteele101 created topic »Zikula 1.3.3 - Site Search 1.5.2 - Unable to turn off plug-ins« 07:48 AM
- mesteele101 responded to »ERR (3): E_USER_ERROR: Smarty error: [in pagesvar:pagesitem2en line XXX]…« 25. May
- mazdev responded to »Pages 2.5.0 and updating - Page not found« 25. May
- mesteele101 responded to »Zikula 1.3.3 - Selecting a category in Pages not working« 25. May
Zikula Blog
- Anatomy of Open Source Projects on Mar 07
- Continuous Review on Mar 01
- Not Invented Here on Feb 24
- How to Contribute Your Code at Github on Jan 13
- 10 Steps to Coding-Nirvana: Tips for Successful Module Writing on Nov 12
- Submitting Bug Report Tickets That Get Results on Aug 17
- Cozi Tricks #1: Syntax Highlighting on Aug 07
Login
No UTF-8 conversion on some tables
-
- Rank: Helper
- Registered: Dec 31, 1969
- Last visit: May 07, 2010
- Posts: 507
-
- Rank: Team Member
- Registered: Feb 27, 2005
- Last visit: Apr 12, 2010
- Posts: 665
I guess those tables did not start with the zikula-prefix, which is defined in your config/config.php
You can manually do the conversion yourself, replacing $table with your tablename, repeating for all tables:
Code
ANALYZE TABLE $table;
REPAIR TABLE $table;
OPTIMIZE TABLE $table;
ALTER TABLE $table DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE $table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
--
-- Teb
-- Dutch Zikula Community
Support questions in a Personal Message will be ignored. Use the forums at all times! -
- Rank: Helper
- Registered: Dec 31, 1969
- Last visit: May 07, 2010
- Posts: 507
That is correct, different non-conforming table names.
Should I anticipate any problems with non-UTF8 tables for this module in 1.2.2? Another (desktop) application uses these tables and it would be nice if I could deal with it's UTF8 conversion at a later date. -
- Rank: Team Member
- Registered: Feb 27, 2005
- Last visit: Apr 12, 2010
- Posts: 665
That completely depends on how your module was written and what it displays on the screen.
I guess it wouldn't hurt to wait if you test your module properly. But there might be undesired or unexpected results if a page is rendered using utf8 and input is stored in latin.
So, test it, and invest time in the long run by converting your app to UTF-8 if possible. This will probably be inevidable anyway.
--
-- Teb
-- Dutch Zikula Community
Support questions in a Personal Message will be ignored. Use the forums at all times!
- Moderated by:
- Support
