Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 170

Deprecated: Joomla\CMS\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Input.php on line 31

Deprecated: Joomla\CMS\Input\Cookie implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Cookie.php on line 21

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Uri/Uri.php on line 141
MySQL version, Key lengths and Issue Tracker - Macrotone Forum

Unknown Error 8192: KunenaControllerApplicationDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in libraries/kunena/controller/application/display.php on line 21


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/route/route.php on line 437


Unknown Error 8192: ComponentKunenaControllerWidgetAnnouncementDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/widget/announcement/display.php on line 18


Unknown Error 8192: ComponentKunenaControllerTopicItemDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/display.php on line 25


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/forum/category/category.php on line 415


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/bbcode/bbcode.php on line 107

MySQL version, Key lengths and Issue Tracker


Unknown Error 8192: ComponentKunenaControllerTopicItemActionsDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/actions/display.php on line 23


Unknown Error 8192: ComponentKunenaControllerTopicPollDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/poll/display.php on line 21


Unknown Error 8192: ComponentKunenaControllerTopicItemMessageDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/message/display.php on line 23

9 years 4 months ago - 9 years 4 months ago #1 by geoffc

Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2022


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2070

We recently received a report about a problem installing the Issue Tracker component upon a MySQL 5.5 database.
The cause was quickly isolated to a problem with the size of a compound (multi column) INDEX key on the '#__it_people' table.

The solution was as mentioned in a blog entry we made several months ago to specify a database global variable 'innodb_large_prefix' which was introduced in MySQL 5.5.

This triggered off an internal investigation as to the use of this 'large_prefix' global setting in more detail and why we didn't need it upon MySQL 5.1 databases and had not seen a problem with the Key size. This post is a brief summary of our investigations which may prove interesting to others.

The limit for a single column prefix is 767 bytes and this has applied since MySQL 5.0 and is still current according to the official documantation in MySQL 5.7 (and MariaDB). In MySQL 5.0 this limit of 767 bytes also applied to compound (multi column ) index keys as well.

Around MySQL 5.1 (?) a change was made such that multi column key prefix could be up to 3072 bytes. Then in MySQL 5.5 it seems to have changed again so that the global variable is required to be specified so that the multi column key prefix could get to 3072 bytes, otherwise it remained at 767 bytes. This was why we required the new global varable!

This to my mind is a retrograde step and is a definite change in MySQL behaviour. We had no need of the seting in MySQL 5.1 but in MySQL 5.5 we have to specify it! We have generally internally been using MySQL 5.1.x, it being the lowest database denominator so had not experienced a problem with the KEY definition ourselves although we were aware of it.

There is however no possible query that we can make of the database to determine the 'maximum key size' since it seems to be hardwired in the code and not visible in the database settings themselves. We cannot therefore make any decision based upon the 'size' as to how the KEY should be defined. We are forced to have a 'preset' value. It has been decided that we will change the compound key so that the total size is 240 characters (person name 150, email 90), which using the UTF8 character set comes to 720 bytes which is below the 767 size limit without the global setting. This is less than the current default of 355 chars (person name 255 and email of 100). In this way we can hopefully handle all cases, at least until MySQL move the base again. This change would apply to 'new' installs only, since existing installs already have the key in place, so there seems no point in changing it. There may be a small performance impact of the change but hopefully this will not be noticable in use. Any change in the version of the underlying database upon a site would perhaps require the specification of the global parameter but that would be a database upgrade decision.

[It would be possible to determine the database version in use and if over 5.5 set the global variable dynamically but we are loathe to do this since it is not our place to change database settngs even if we can! This would require code changes as well, requiring our installer to create the Key on the table after the underlying database objects had been created. If we got or decision criteria slightly wrong it would be 'after the event' as the Joomla installer captures the errors in the installer andu doesn't pass them back to the component install script where we could handle it gracefully. Don't you just love these types of problems? ]

We have a 'solution/work' around for the future which will be in the next 1.6.6 release which will only impact new installation. Just goes to show how much investigation one requires on what on the surface seems to be a 'simple' problem.

Regards
Geoff

Unknown Error 8192: ComponentKunenaControllerMessageItemActionsDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/message/item/actions/display.php on line 25

Please Log in or Create an account to join the conversation.

9 years 4 months ago #2 by NF
Hi Support,

I have this problem. I know Joomla and SQL but not much about DB administration. I really want to use Issue Tracker on an excisting Joomla website to get the users a simple login to track their issues. Can you tell me when you expect the new release 1.6.6 will be available for me?

Thanks in advance and a very nice Christmas greeting,
Nico

Please Log in or Create an account to join the conversation.

9 years 3 months ago #3 by geoffc
Sorry for the delay in the reply. Seasons Greetings to you as well.

It being Xmas I have placed a development version of 1.6.6 in the download area for you to 'play with'. You need to log into the site to be able to access it, but it is under the Downloads - Issue Tracker - Dev releases area.

Be aware that it has had limited testing but it is believed to include all currently known problems with the 1.6.5 release. It is not a prerelease and the final version will contain a few additional changes, but since 1.6.6 is a few more weeks away from being finalised I thought you might wish to look into it for testing purposes.

Regards
Geoff

Please Log in or Create an account to join the conversation.

9 years 3 months ago #4 by brononius
fyi, just trying to install a fresh installation, and i'm getting following error with the dev version:

1146 Table 'oniriab_demo.vu0ln_it_people' doesn't exist SQL=select count(*) from vu0ln_it_people where registered = '1'


My joomla version is 3.3.6. But our hosting provider is still on php 5.3.28 and mysql 5.5.37.

Please Log in or Create an account to join the conversation.

9 years 3 months ago - 9 years 3 months ago #5 by geoffc
Hmmm. The dev version should at least install as I specifically tested that before I put it up on the site.

Given that it installed here, that means that the SQL itself is probably syntactically correct, which only leaves the UNIQUE key size that is the likely cause. The dev version deceased the key size to 240 characters, which for a UTF8 database makes it 720 bytes, which is below the common 767 bytes limit.

It is difficult for me to confirm this without a specific database set up to match yours, and the lack of a more informative error message (from Joomla) doesn't help.

If you could extract the specific SQLcode to create the it_people table and after modifying for your database prefix, run it directly in myphpadmin and post the (myphpadmin) error message it will enable me to resolve it.

Regards
Geoff

Please Log in or Create an account to join the conversation.

9 years 3 months ago - 9 years 3 months ago #6 by NF
Hi,

I missed the updates on this topic, but I have tried to install the 1.6.6 version immediately and I get the same error during installation:
1146 Table 'DBxxx.prefix_it_people' doesn't exist SQL=select count(*) from prefix_it_people where registered = '1'

I will search for which sql statement you want us to run in myphpadmin. I guess I have to get a that out of the script.php file?

Kind regards,
Nico

Please Log in or Create an account to join the conversation.

Time to create page: 0.176 seconds
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries