Open JoeyStk opened 1 month ago
Most of the issues linked in #1097 are blocked by this issue. I would therefore like to get started on it, but tbh I am kinda lost on what/how much needs to be refactored.
Is it enough to make the page tree "work" for the purpose of showing the new statistics? Or do we actually want a ground-up, modular rebuild?
Both are certainly possible, but I am struggling to see if there is a good middle ground here.
Is it enough to make the page tree "work" for the purpose of showing the new statistics? Or do we actually want a ground-up, modular rebuild?
As I remember the idea was to "refactor" so much, that we can reuse as much as possible. Therefore I'm leaning towards the first. But @david-venhoff is there maybe something else you also would like to see get done with this issue? :)
No, I also think that it is enough to get the page tree to work for statistics :)
Alright, thanks for the clarification.
'@JoeyStk i merged archived_page_tree.html
into page_tree.html
. The page tree and the archived page tree deal with their rows quite differently, so the archived drop down of the rows has still some errors and I haven't merged the respective row templates yet
Motivation
We want to add the access statistics for individual pages to our statistics. For this we need a collapsible box containing a replicated page tree.
Proposed Solution
Refactor page tree first and then add one instance of the page tree to the statistics page as a collapsible box.
Alternatives
None
User Story
As a user of the CMS I want to see the number of accesses to individual pages in a hierarchical way so that I know which content is more generally relevant for the majority of users.
Additional Context
This part of our meta issue #1097
Design Requirements
Design proposal (v3): https://www.figma.com/file/6U7R7Xj4wL7sbjxKRmOG9D/CMS-Project?node-id=1179-830
ToDos:
_generic_page_tree
pages_page_trree
statistics_page_tree