Tikhonov Ivan

Ohanzee, take a look at the similar issue with temporary solution

Thanks, Jim. That's the point of latest release as well, compared with v4.7.15 the btoa() function appeared in core java-script and utf-8 character string is unacceptable as a btoa() argument.

Would you, please, fix this core bug of global_global_core.js soon? It is inconvenient to apply above custom patch every time after clearing system caches. I believe every forums with non-Latin topic urls are affected.

After upgrade we've noticed the new btoa() function and error "failed to execute btoa()" in global_global_core.js As a result, pagination for cyrillic urls stopped working. See https://developer.mozilla.org/en-US/docs/Glossary/Base64#the_unicode_problem As a temporary solution we implemented the convertion between UTF-8 and single-byte representations before call btoa(), like

Hello. The problem is still relevant. Hackers check login information from other hacked forums and other databases. They use an array of proxy servers and will check emails and passwords from other services. Users often use the same emails and passwords. A captcha on the login form could prevent such an attack.

I'am not sure I got the point. InnoDB strict mode is enabled by default and we guess that's correct. Rebuilding the search index is not in connection with innodb syntax rules. System core generates AGAINST ('*someword* *') or AGAINST ('*') which leads to error statement, just try to execute the following two commands. IPS applications/core/modules/front/search/search.php query: SELECT *, ( MATCH(index_title) AGAINST ('*someword* *' IN BOOLEAN MODE)) as result FROM `core_search_index` LIMIT 5; no error query: SELECT *, ( MATCH(index_title) AGAINST ('*someword*' IN BOOLEAN MODE)) as result FROM `core_search_index` LIMIT 5;

We've converted all tables of forum's DB into InnoDB format as suggested by AdminCenter. Just then the system log began collecting the errors in search query "IPS\Db\Exception: syntax error, unexpected $end, expecting FTS_TERM or FTS_NUMB or '*' (1064)" The query itself is in the following format: SELECT *, (( MATCH(index_title) AGAINST ('*some_word* *' IN BOOLEAN MODE)<... and so on...> We believe the forum core generates it while this is coming from data input when the user is asking something like to "see everything", but for InnoDB AGAINST('*' ...) is not valid. Fulltext expects to see some_word(s), not a lone wildcard '*' (nor separately). Would it be fixed (or tell us, please, how can we do it) or we are better to fall back to MyISAM table? Invision Community v4.7.5, PHP 8.0.26, Percona Server for MySQL 5.7.40-43

Hello! Do you have plans to update the app for 4.7?

Thanks!

Hello @DawPi Do you have plans to update this plugin for 4.6?

Hi. Why?

@Adriano Faria Hello! Thanks for the plugin! Maybe you will help me to solve this problem: Invision Community v4.3.4. During installation I receive an error 1S111/1 After that, there are 2 items "New Topic Rules" appear in the menu A tab "newtopicrules" appears in the section settings, but if you try to save the text, an error occurs: "EX1054 Something went wrong. Please try again. "