Question: Can we put we 'add comment' button above the comment list?

[jjnxpct]

Can we put we 'add comment' button above the comment list? In the default template the button (or form when opened by default) is shown below the comments list. I was looking for an option to put this above the list, but did not find it.

For now I have created an override to have the button/form above the comments. I use the button (form hidden). For sites that show the form by default it might not be the best position for the form. In that case I would put it (open form) after the comments.

But when it's just the button tis is visible sooner when the comment list get longer. So it might be more inviting to use.

[nikosdion]

The correct way is, indeed, with an override.

I have explained it plenty of times in the past. Things which are easily customisable with overrides won't get an option. You will not see an option to move the position of the button. You will not see an option to adjust colors, margins, indentations etc. You will only see options to change how things work in the backend of the component.

This is a very deliberate choice stemming from the insufferably shitty experience I had with Akeeba Subscriptions over a decade ago. Back then, I would gladly add options to move things around the page, change what should be CSS overrides etc. The problem with that approach is that the code became impossible to maintain very fast. Within two years, the slightest change required a week of hard work to figure out what else was breaking and fix it. There were so many nested if-blocks and view template files dependent on other view template files dependent on even more view template files that I had started to say no to reasonable feature requests just because the cost of implementing the smallest change was astronomical. If changing the button color requires 30+ hours of a developer paid between 50 and 100 Euros an hour, that's a horrible value proposition, right? Not to mention that the files were so incredibly convoluted that nobody could do template overrides, therefore they had to ask for more options.

So, here's the lesson learned: keep it simple, stupid (a.k.a. the KISS rule). Keeping the options affecting the view templates at a bare minimum makes it easy to do template overrides, which in turn does away with the need to implement any more options affecting the view templates. If that means that less experienced users won't like it and won't use it, that's fine by me.

[jjnxpct]

I understand!

" If that means that less experienced users won't like it and won't use it, that's fine by me."

I'm just glad I'm a bit more experienced then ;-) Otherwise I would maybe miss out on your great extension(s). Thanks for your work!

[nikosdion]

True that :)

To be clear, the "less experienced" in this context means people who can only build sites using a point-and-click interface. They are plenty, they are important, but this is not software built with them in mind. I built this for site integrators who are are not afraid to do a template or media override to customise the look, feel, and functionality of the software. That's why I said that if the former won't use it it's fine by me; I have to choose where I put the bulk of my time and energy, and Engage is not it.