-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor page tree and add page based statistics #3325
base: develop
Are you sure you want to change the base?
Refactor page tree and add page based statistics #3325
Conversation
…ags for archive nodes
…sible_box' of https://github.com/digitalfabrik/integreat-cms into feature/refactor_page_tree_and_add_statistics_to_collapsible_box
…ags for archive nodes
Current state of this PR: @jarlhengstmengel is still working on fixing the tests. As soon as this is done, this PR is ready to be reviewed :) |
The existing tests do pass now so I marked this PR as ready to be reviewed! |
@jarlhengstmengel @JoeyStk |
We decided to keep the commits until we merge so we can go back to previous states in case something doesn't work as expected |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! This is a really nice refactor! I do have a couple of small comments (see below), as well as some comments about the statistics.
However, I am not sure if this PR is just meant to add a draft of the statistics, or if it should be the "final" statistics implementation, and depending on which it is, some of my points might not be applicable.
- the sidebar-boxes should not resize when a parent page is expanded. Esp. when a lot of pages are epanded, blank space is added at weird-looking places in the sidebar boxes. IMO they should always just be their initial size and stay at the top of the page.
- the last column of the statistics page tree ("accesses" with the date range) has a left-aligned header, but right-aligned content. Just looks a bit weird.
- you are currently blocking the reordering of pages in the statistics view. Is there a reason to still show the icon used for dragging and dropping? IMO it should not be shown at all in the statistics view.
- what happened to the bar charts intended for the statistics page tree? 😁
I have tested all the views where the new and old page trees were used to the best of my abilities, and have found 0 issues with how they look or behave. Good job!! 😁 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe generic_page_tree_header.html
? From the name I initially thought this was the main "entry point" for the tree
{% if is_statistics %} | ||
{% include "statistics/statistics_viewed_pages_node.html" %} | ||
{% else %} | ||
{% include "pages/pages_page_tree_node.html" %} | ||
{% endif %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: if we decide to use the page tree for even more things / in more variants, this becomes cumbersome. Maybe we could pass something like row_template
from the view?
(...but since I do not know if we will be extending the usecases of this, it really is a nit. Feel free to ignore without comment 😄)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the error-responses, could you also add error logs here?
translation_slugs: dict = {} | ||
for page in pages: | ||
for language in languages: | ||
if page_translation := page.get_translation(language.slug): | ||
if page.id not in translation_slugs: | ||
translation_slugs[page.id] = {} | ||
translation_slugs[page.id][ | ||
language.slug | ||
] = page_translation.get_absolute_url().rstrip("/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this could be faster if formulated as a database query. This is only used in get_page_accesses_async
, which is also only called once in get_page_accesses
, where region.get_pages()
is passed to this function. get_pages()
returns a queryset
, not a list[Page]
, so you should be able to work directly on that?
But maybe you have a reason to not do that, I only took a cursory look at this part 😅
@@ -29,6 +29,7 @@ let exportLabels: Array<string>; | |||
const updateChart = async (): Promise<void> => { | |||
// Get Chart instance | |||
const chart = Chart.instances[0]; | |||
(window as any).chart = chart; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this actually used anywhere? 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think statistics-page-accesses.ts
makes use of the chart to track for changes in filtering
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NVM it's never used
}; | ||
|
||
window.addEventListener("load", async () => { | ||
updatePageAccesses(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updatePageAccesses(); | |
updatePageAccesses(); |
Not really a but but...this is causing TypeError: Cannot read properties of null (reading 'classList')
everywhere except on the statistics page 😢
updatePageAccesses(); | ||
chart = Chart.instances[0]; | ||
// Refresh the statistics every time a new timeframe or language is selected | ||
const oldUpdate = chart.update; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This chart
too. It does not exists in many pages of our system 😢
I tried this branch with the dump date from 20 Janurary, and it seems loading time needs improvement, as the chart bars never loaded (or let's hear from other reviewers testing with a dump date, it's can be only in my environment that it's so slow...). Trying with less pages in a region (by deleting or archiving most of pages), it seems to be working nice 😸 |
Co-authored-by: Charlotte <[email protected]>
That's a really good point. We spoke about this quite a bit. We also wanted to remove the icon, but then a. it looked a bit strange and the hierarchy of the child pages wasn't as clear anymore and b. we discovered that we also use the icon for archived pages, although it's also not possible to move pages there. Therefore we decided to go for what already exists in the system. But yes, maybe it would be an idea to give this to UI/UX and change it later for page statistics and for archived pages |
2957a54
to
7d82374
Compare
OK, makes sense. Then I'd say leave it as is for now, but could you open an issue for changing the icon/behavior in both instances? |
Short description
This PR refactors parts of the page tree and adds the page based statistics to statistics.
Proposed changes
pages_page_tree
andstatistics_page_tree
page_tree_archived
intopages_page_tree
Side effects
Resolved issues
Fixes: #3130
Pull Request Review Guidelines