Review and adjust the theming of the project wiki list / project wiki entry

Probably kind of OT here, but very important.

As I briefly discussed with @LRWebks yesterday, the overview should better be a Drupal View, instead the custom listup and filters we currently have. While the items itself, should be rendered "entities" (this basically means: not views fields) and the filters, for sure, should be Views Filters (with Paging, AJAX, ...).

Or are there technical reasons for not using Views @Grevil @Anybody?

First review done, considering, we basically have the regular entity variables (like view_mode, attributes, title_attributes, content_attributes, ...) available. Untested yet.

Furthermore, I've splittet the entry template into:
- project-wiki-entry.html.twig (Fallback & 'full' view mode)
- project-wiki-entry--teaser.html.twig (Preview / 'teaser' view mode)

So first changes merged, next iteration, when the Wiki structure and functionality is basically done.

As I briefly discussed with @LRWebks yesterday, the overview should better be a Drupal View, instead the custom listup and filters we currently have. While the items itself, should be rendered "entities" (this basically means: not views fields) and the filters, for sure, should be Views Filters (with Paging, AJAX, ...).

While this is the correct general approach and way of thinking (components), it's not possible to use views here. So we should split this into two aspects:
1. The wiki entries should of course be handled as the same component. As the plugins returns an array which is then looped in twig and rendered through the same logic and templates, it should already work like this. If not, something has been done wrong. I didn't take a look at the current code yet. From the outside a wiki entry should be agnostic from his source, so it should have the same (twig) variables, look etc. where ever it was stored / created. Using the same template or inheritance is of course the right way, as @thomas.frobieter said. So proceed like that.

2. The wiki list can't be a view, but should of course stick to Drupal (views-like) standards for dom structure and classes (but not a fake view of course). It can't be a real view, as views is (SQL) query builder, but we're agnostic of the data source for our wiki entries.
So it was intended not to use a view and become source-neutral at the master module level.

Finally, we should keep in mind, that this is a helper module nobody pays us for and surely already cost a few thousand euros yet. So good and pragmatic solutions are needed. We can make it the best module ever written, but as always, someone has to pay for it. (We!)

So whatever we do here, let's focus on the important things that work well and get the job done and not get lost in details.

So, as a consequence we should close this issue?
https://www.drupal.org/project/project_wiki/issues/3384211 📌 Put list page back to a view Closed: works as designed

Finally, we should keep in mind, that this is a helper module nobody pays us for and surely already cost a few thousand euros yet. So good and pragmatic solutions are needed. We can make it the best module ever written, but as always, someone has to pay for it. (We!)

So whatever we do here, let's focus on the important things that work well and get the job done and not get lost in details.

Indeed. Because of that, I wanted to used Views instead of reinventing the wheel here ;)
Really sad, views is not really usable in a programmatic way :/

However, we should ensure then, that the custom filters using the default Drupal/Claro CSS classes and markup.

So, as a consequence we should close this issue?

Right, closed it!

Perfect, thanks! So we can proceed with the template unification here.

Please note, that I didn't do a full code review yet, so there might also be other architectural tasks, but as this is large anyway, don't get stopped by that. We'll surely have to do some more loops. Just go for it.

AND please note that the MR here was already merged, so further changes here might be complicated in the git - flow. Perhaps instead better close this fixed and create a linked follow-up with the remaining tasks?

AND please note that the MR here was already merged, so further changes here might be complicated in the git - flow. Perhaps instead better close this fixed and create a linked follow-up with the remaining tasks?

Never tried to create a 2nd ..3rd.. issue fork in the same issue, but Its possible, so it might should work? I'll give it a shot when I proceed here.. if it fails, I create an further issue.

@thomas.frobieter I'm also unsure, I think it didn't work well. I'll add 📌 [META] Implement wiki overview as single-page Active as parent task, eventually you may want to solve it there combined.

@RohitRawat676 this is not related to this issue in any way and won't be credited. I think we can call this kind of spam. Please stop it.

@thomas.frobieter perhaps better close this fixed and carry over the left points from the comments into a new task / tasks?

Automatically closed - issue fixed for 2 weeks with no activity.