Reply to has wrong name when reaching maximum comment depth

NicolasDerumigny commented 1 year ago

Please read the README.md in the repository's root and the support resources before submitting an issue.

Steps to reproduce the issue

Reply a comment within maximum comment depth.

Expected result

Akeeba displays "Answering to "

Actual result

Akeeba displays "Answering to "

Troubleshooting already performed

None.

System information

Linux 5.15.84 on a Raspberry Pi 3B running Debian 11

Mandatory information

Issues without this information can not and will not be replied to.

Joomla! version: 4.2.9
PHP version: 8.2.2
Am I using HTTPS: Yes
Server Operating System: Linux
My device's Operating System: Linux
My device's Operating System version: arch Linux
Browser: Firefox
Browser version: 1100

Good to have information

You can skip some or all of this information. However, the more information you provide the faster and better we can help.

MySQL version: 10.5.18
Server type: NginX
Server version: 1.18.0
Hosting company / Local server: Local Server
Server Operating System version: Debian 11

Additional comments

None

nikosdion commented 1 year ago

This is not accurate. I just tested that.

Let's say we have a maximum of three levels and three comments submitted by these users:

User A
   |
   +-- User B
          |
          +-- User C

When you click on the Reply button in User C's comment you'd normally be trying to create a 4th level comment. However, the maximum nesting level is 3 which means that the actual parent comment will be the one submitted by User B.

As a result, Akeeba Engage shows "In reply to User B".

If User B's name is empty it will show "In reply to " since the full name which goes to the right of the last space in this sentence is an empty string.

Please note that it doesn't matter if any of these users, or the current commenter, is an existing user of the site or a guest comment. All it matters is what is their full name. While both Guest commenters and real Joomla users cannot normally have an empty full name (it's checked by Engage and Joomla respectively) it is possible to do that if you mess with the database directly.

NicolasDerumigny commented 1 year ago

So Akeeba engage is doing its desired behavior? I thought the maximum nesting was only a cosmetic display option, and that the actual reply was to the comment selected by the "reply" option. I'll see how I can manage what I want with style overwrites, then. Thanks for the reply!

nikosdion commented 1 year ago

The maximum nesting level is an honest to goodness maximum which is also imposed at the database level — for performance reasons.

Since we are using an RDBMS (e.g. MySQL) we can only store comments in one of two ways:

A double linked tree, where each item stores the ID of the item to its left and to its right. That's how, for example, Joomla's tree table works.
A simplified hinted tree where each item only stores its parent item ID.

The former works great when you want to paginate items for display. It has one major problem, though: the tree modification time is O(N^2) which means that the time to insert a new item into the tree or the time to delete an item into the tree increases exponentially with the number of items in the tree. I've found that on a typical, fast, commercial host this increased to well over 3 seconds at around 100,000 items. This is what Joomla uses for articles and the reason why after ~10,000 items it starts feeling “slow”. This is nothing new, I had written the earliest benchmarks in the Joomla world to demonstrated that back in 2009.

While this is okay for articles (you write very few articles, and they are submitted by people who are okay waiting) it's not a great prospect for comments. One can expect that comments are being submitted relentlessly.

This is why I chose the latter method. However, the latter method has a major disadvantage: you cannot really paginate it using plain MySQL code (at least not without stored procedures which are computationally expensive and not well supported across commercial, shared hosting environments). So I use a hybrid solution where I read all the comment IDs and their parent IDs for a given article and resolve them into a tree using PHP code. I then flatten this tree to get the IDs belonging to each "page" of comments.

Inserting and deleting comments is blazingly fast but each nesting level requires one more recursion of the tree resolution algorithm and the tree flattening algorithm. I found that at about 30 levels it becomes a major bottleneck.

At the same time, we hope to be able to display comments on a commercially viable display. At six levels deep you have reached what you can reasonably display on a 16" Full HD display at 16px text size without causing very narrow, impossible to read columns being displayed. Hence the actual limit of six levels deep.

Nothing was selected at random. There was a lot of R&D behind it to strike a balance between performance and convenience.

NicolasDerumigny commented 1 year ago

Thank you for the heads up, I got the issue. And as the order of the tree is fixed, more complex structures as r/b tree are also out of question. And I assume that the "real parent" (i.e. comment on depth 2 for a maximum depth of 3) and the "perceived parent" (comment on which the reply button is clicked) cannot be sent separately in order to notify the owner of the "perceived parent" by mail but store in db the "real parent" (capped depth) for performances issues ?

That was my expected behavior, but I get this raises issues when replying to a comment which is not the last one, as there will be no graphical information of the target comment. I will think about it in the next days and see if I come up with any idea, but I if it was designed that way, I think there is no other sound choice.

nikosdion commented 1 year ago

And I assume that the "real parent" (i.e. comment on depth 2 for a maximum depth of 3) and the "perceived parent" (comment on which the reply button is clicked) cannot be sent separately in order to notify the owner of the "perceived parent" by mail but store in db the "real parent" (capped depth) for performances issues ?

Correct.

That was my expected behavior, but I get this raises issues when replying to a comment which is not the last one, as there will be no graphical information of the target comment. I will think about it in the next days and see if I come up with any idea, but I if it was designed that way, I think there is no other sound choice.

You can't really do much about it without going into an arbitrary reply depth.

Mind you, nobody does an arbitrary comment depth. Facebook, WordPress, The Register, and Disqus stop at three. Twitter and similar micro-blogging don't have a reply level at all (they have a graph defined by references) but they render it as a three level reply tree at most. Slashdot and Reddit allow for n-levels deep but the interface is awkward at best beyond the fourth level (if you've used these two sites you know what I am talking about).

I thought about having at-references (mention a user, therefore the user gets emailed) which would solve the problem but it introduced two new ones: a. everyone needs to have a user account on the site which would make Engage unsuitable for most use cases it is actually used for; and b. you'd get at-mention spam, solving which quickly devolves into building an honest-to-goodness social network.

I really don't have a good technical solution so I hope people use their common sense: mention the person they are replying to when things get to the maximum nesting level.

akeeba / engage