Conversation
The dashboard widget listed top targets by raw URL. Resolve each target's post title in Statify_Dashboard::select_data() via the same Statify_Evaluation::post_title() helper the content views already use, and prefer it in the widget's top list (renderTopList). Title lookups run inside the existing statify_data transient, so they happen at most once per cache window over `limit` rows rather than on every dashboard render. Referrer rows are unaffected. Fixes #78
|
stklcode
left a comment
stklcode
left a comment
There was a problem hiding this comment.
I guess the API part with a new title field is fine.
Gathering the titles is about the same as we do in the extended view and it's OK for me that way. If we come up with a better solution we might update the backend part without user interruption.
|
The is a good first solution! 🙌 The main discussion at Cloudfest was around URLs that don't map to a post/page. Those will now still show the URL. Since getting the page title for special pages like archives, 404, searches, etc. does not work (easily) taking the URL, we have saved the title "on request" using the We also decided to introduce a meta table to enable us to store more meta information - or allow other to do so via hooks - but then didn't join the work, since we were unsure about how to aggregate this new (meta) data. See: #251 |
|
@2ndkauboy Thanks for commenting on this one. Other point is, titles may change over time which is covered by this simple approach, but may require so,e tweaks with a pre-filled tables. Think we should discuss about both topics and how we want to proceed and should not block ourselves with (maybe) conflicting ideas. But I’d prefer to postpone it to after 2.0. As said before, the API should be fine to handle for upcoming internal changes. |
3 participants
The initial #78 branch solved this with a
statifymetatable that captured the document title at track time. That predates the v2 refactor and would add write-path overhead plus reintroduce schema we've since removed, so this PR takes a different route — the one v2 already uses for the statify_content tables.Approach: resolve titles on demand from the target URL (Statify_Evaluation::post_title() → url_to_postid() + get_the_title()), enriching the target rows in select_data() before they're cached. Because that data already lives in the statify_data transient (15 min), lookups run at most once per cache window over limit rows (≤100, usually far fewer)
Is this too tacky? Let's discuss :)