I have a Privacy Policy, Terms and Conditions and Cookies Policy, K2 items that are connected to Hidden Menu items of the same name. Instead of the article opening when I click on the links in the footer section of website, a lest of articles by the author, me in this case, opens instead.

The Menu Item is of type K2 - Item, In "Select Item" I selected the article "index.php?option=com_k2&view=item&layout=item&id=xxx," The category for the item is "User Relations Documents" which derives it's settings from another category "One column Settings."

I have rebuilt Hidden Menu, I have deleted and recreated the category "One column Settings," I have deleted and recreated the child category "User Relations Documents" and I deleted and recreated the K2 items/articles.

None of that had any effect, I still get a list of articles by the author instead of the article being displayed.

What obvious thing could I be doing wrong.

I am trying to make the site GDPR compliant and I have installed the component GDPR from Joomla Extensions Store and I discovered this issue when starting to set that component up.

Any thoughts would be very welcome of course. I have run out of ideas.

Thanks Fotis, I was afraid you were going to say that. I will take the remedial action you suggested.

I am getting this error when installing the K2 2.9.1 dev build. dbusername is substitute for real dbusername. Actuality the db name and db username are the same on this installation. So this would be the db name.

Warning

BIGINT UNSIGNED value is out of range in '(`dbusername`.`#__menu`.`level` - 1)'

Error

Error installing component

I had already re-installed Joomla first before reading this.

OK, this isn't a category list getting displayed, This is just the page with "Published In" category information and the "Latest from Author" information. That should be there. What is missing is the display of the item itself: See below.

this error BIGINT UNSIGNED value is out of range in '(`dbusername`.`#__menu`.`level` - 1)' could be because I changed the collation to utf8mb4_unicode_ci. Changing from two byte representations of the data to four byte representation of the data would raise this kind of error.

I was reading arguments like the following and decided to use Akeeba Admin Tools to change the collation from utf8mb4_general_ci to utf8mb4_unicode_ci. There are many tables in the database that used 2 byte utf8_unicode_ci and others that used utf8_general_ci, others that use utf8mb4_unicode_ci and yet others that used utf8mb4_general_ci. those didn't change after changing to utf8mb4_unicode_ci.

There is also a mix of various database engines as well, INNODB, and MYiSAM

Note: Since MySQL 5.5.3 you should use utf8mb4 rather than utf8. They both refer to the UTF-8 encoding, but the older utf8 had a MySQL-specific limitation preventing use of characters numbered above 0xFFFD.

Accuracy

utf8mb4_unicode_ci is based on the Unicode standard for sorting and comparison, which sorts accurately in a very wide range of languages.

utf8mb4_general_ci fails to implement all of the Unicode sorting rules, which will result in undesirable sorting in some situations, such as when using particular languages or characters.

Performance

utf8mb4_general_ci is faster at comparisons and sorting, because it takes a bunch of performance-related shortcuts.

On modern servers, this performance boost will be all but negligible. It was devised in a time when servers had a tiny fraction of the CPU performance of today's computers.

utf8mb4_unicode_ci, which uses the Unicode rules for sorting and comparison, employs a fairly complex algorithm for correct sorting in a wide range of languages and when using a wide range of special characters. These rules need to take into account language-specific conventions; not everybody sorts their characters in what we would call 'alphabetical order'.

I found the problem. It has something to do with SEO URLS.

When I use the JCE Editor Link Tool and select a menu item from that interface I get:

index.php?option=com_k2&view=item&layout=item&id=795&Itemid=3401

And this doesn't work.

If I use:

9-11-tap-privacy-policy

This does work and I get a nice page displayed.

As far as K2 2.9.1-dev not installing, that is troubling.

I am going to try to limp along here and create a Joomla 4.0 installation and when that is finished migrate everything over.

I have redesigned the Cassiopeia template, substituting CSS grid-area cols and spans in place to the Bootstrap cols and spans. I leave the naming convention the same so that those extensions that need the Bootstrap for whatever reason will still be able to access it, but for general layout, I will use CSS Grids instead.

Fotis, I got this from Nicholas K. Dionysopoulos this morning:

First of all, it's normal to have a mix of collations when you try to convert a site. Some older software may have not updated its database structure for UTF8MB4 requirements. For instance, MySQL only allows database keys with entries up to 767 bytes long. If you have a VARCHAR(192) column it takes up 3 x 192 = 576 bytes under UTF8 but 4 x 192 = 768 bytes under UTF8MB4. This makes it an invalid key size. If there's an INDEX / KEY on that column the conversion to UTF8MB4 will fail, therefore it needs to remain plain old UTF8.

That said, this has absolutely nothing to do with your problem! If you look at the error message, it tells you that trying to write to the Joomla menu table, and that failed because something tried to store the value -1 on a column which is supposed to only accept unsigned long integers. "Unsigned" means "without a sign", i.e. only positive values. Clearly, -1 is negative, not positive, hence it's out of range.

The column level where this happens is what is used internally by Joomla! to figure out the hierarchy of menu items. Therefore the error message tells us that your Joomla! menu structure is, not to put too fine a point on it, cocked up. The first thing you should try is going to the backend of your site, Menus, Manage and click the Rebuild button in the toolbar. It tries to fix exactly this kind of issues.

If that didn't make any difference then you should probably rebuild your site, as painful as it may be, because that'd mean you have a far more complicated issue.

PS: You may wonder why this happened when you tried to install an update. It's probably because Joomla is trying to regenerate the backend Components menu during the update of any component. Since the menus table, shared by the front- and backend, is screwed up this triggered an invalid data write which raised the database error.

So I rebuilt all the menus, but K2 2.9.1-dev still threw the same database value out of range range exception when trying to store and unsigned varchar of -1.

So I thought, OK, I'm done, I will just have to start from scratch and then begin migrating everything over.

But I decided to try one more thing. I downloaded the most recent version of K2 2.9.0 and tried to install that over the existing installation of K2 2.9.1, and to my surprise, it installed without throwing any exception.

Since that was successful, I decided to try re-installing the latest dev build of K2 2.9.1, and again to my surprise, everything installed without exception.

I think something must have gone wrong because of installing several different dev builds of K2 2.9.1.