Thanks for the answer. I created a ticked (Request ID 873179) and provided a more detailed info about charset/collations.
But I like to pinpoint:
- Few already existing topics previously opened without "Driver error". Forum software did not complain about these already posted URLs before...
- The problem is that I can't control what kind of links / from where / how users are pasting (there is always a chance to have a strange character in URL), but the whole topic or editing capability can be locked due to a single character in a particular link ...
I see that in my case the biggest issues are URLs pasted by users. The characters lock topics with "Driver error". I gave some examples before. The newest occurrence involved a non-breaking space at the end of URL:
I run IPB 3.4.5 with the URLs patch. And to clarify: the problem in cache_content column appeared recently. I did two things before the problem was first time noticed: installing URLs patch and reinstalling crashed server (the differences are a little bit newer versions: Mysql 5.0.8 + PHP Version 5.3.24).
My board is Polish. All settings / tables ale 100% UTF-8. And I have the same problem with some "spoiled" characters, only in different columns (cache_content, log_url)
For example, these characters (Polish characters replaced by distorted "equivalent") as a part of URL in posts:
Error: 1366 - Incorrect string value: 'xB3yny.p...' for column 'cache_content' at row 1
Error: 1366 - Incorrect string value: 'xEAcia&a...' for column 'cache_content' at row 1
... totally locked whole topics, which could not be opened due to "Driver error". I had to go directly into database and remove characters. That was the only thing I could do on non-invasive level.
I also made some research and found utf8mb4 tip, bu t I holded before converting anything. In the past, I made a conversion to UTF-8 and it cost me a lot of work + direct characters replacements in a database. I won't repeat a similar process without any guarantee.
Disabling SQL strict mode is only a "dirty workaround".
Just to be clear: what will happen with a content [custom tag ]... [/custom tag] already saved in a database (especially a portion from pre 3.4.x) and older posts display? Will the tags show unparsed in older posts stright after upgrade?
What will happen to custom BBCodes already definied in ACP? Will the settings be preserved or completely removed and automatically ported to "custom button in the editor"? How we suppose to migrate already existing custom BBCodes (including PHP based) to a new system, adding them from scratch using "button" method?
I don't know why you don't see this in 3.3.x, but I observed this from the very beginning. The Firefox bug you reported was already in 3.2.x when CKEditor was introduced. I recently upgraded from 3.2.3 to 3.4.3 and I don't see any difference in Firefox behaviour. The same problem with a context menu called from blank field (different "website" menu shown and no Copy/Paste options present) in RTE mode. The issue does not exist in BBCode mode.
I agree. Previously in IP.SEO as independent application it was possible by disabling a hook . I don't see a way to disable it in 3.4.3, but in IP.Board 3.4 Dev Update comments an option is mentioned. Am I missing something?
I do not want to fill my database with this kind of records and I would like to avoid unnecessary SQL errors like "Data too long for column 'keywords'..."
I agree. Personally, I find the current design annoying. I would like to have a choice which mode of editor to use. BBCode mode with all buttons disabled is hardly usable. Every tag must be manually typed....