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

Should we also implement a generic tree node? Would that make sense?

@jarlhengstmengel
Remaining tasks:

• Fix issue with icon
• Fix issue with strange spacing
• Fix issue with page tree
• Fix issue with archived page tree (pages are sorted to the wrong parent, but probably same root)
• Change page tree to be not editable in statistics (as for archived pages)
• Fix issue to select a time frame
• Fix issue to select language

Regarding the refactoring of the archived page tree, the idea came up to show the (not archived) ancestors of a archived page so that users get a better overview where in the page tree the archived page was located. I think that could be helpful information when a page should be restored. Is that something we would like to do @JoeyStk?

Regarding the refactoring of the archived page tree, the idea came up to show the (not archived) ancestors of a archived page so that users get a better overview where in the page tree the archived page was located. I think that could be helpful information when a page should be restored. Is that something we would like to do @JoeyStk?

I have wondered about something similar in the past. I assume we would need to do a good job with it and stay in touch with ui-ux during the process, but all in all I like the idea to improve the current view

Regarding the refactoring of the archived page tree, the idea came up to show the (not archived) ancestors of a archived page so that users get a better overview where in the page tree the archived page was located. I think that could be helpful information when a page should be restored. Is that something we would like to do @JoeyStk?

I have wondered about something similar in the past. I assume we would need to do a good job with it and stay in touch with ui-ux during the process, but all in all I like the idea to improve the current view

@osmers @nikolahoff what do you think? Currently it's just a plain list of archived pages without any special structure. In the current state of refactoring, the hierarchy between a archived page and it's implicitly archived children is visible, but without the possibility of collapsing or expanding as in the page tree since that turned out to be quite complicated to realize. With showing the non archived parents, the dropdown should be a lot easier to implement, but I think that a good visual distinction would be needed