Articles with Autotags may have incorrect What's Related Block since autotag content can change over time and by what user is viewing it

[remyKobolski]

I did notice that what"s related (article, story) nicely detects hrefs and adds that to what"s related and stores them in the database on edit time. Now, since autotags are dynamic in nature, the article has become static content. Whenever the autotag changes, the block will not pick up the new href and shows incomplete information. In worst case the what"s related block may show broken links.

One solution is to reprocess articles with autotags in its content. This could be available to the plugin that manages the autotag. As an api call or something like that.

Another solution would be to process the article before PLG_replaceTags and accept related links from the autotag. Maybe to be configured.

[eSilverStrike]

Articles What's Related block I believe is stored when the article is saved in the database. They are also cached with the article if it is also cached.

Having articles cached means those with autotags that return information which can change does mean the user may not always see the latest information. This may be fine in some cases and not in others and that is why we allow if the editor wants to specify a cache expiry value for each article.

You bring up an interesting issue with the What's Related block for articles since it can include links from autotags. Since autotags content can change over time and also may change depending on who is looking at it (ex. an Admin User compared to a Anonymous user).

We also need to think of speed here since checking for links on a page can get expensive since the page itself has to be generated at that time to do the work (along with all the autotags, etc.).

The other thing to consider is that in most cases this will not be an issue for most articles on most websites.

So what is the ideal solution taking into account this issue will not affect most articles?

I guess ideally we would have another setting for each article that the writer can enable which will signal Geeklog to always generate the Whats Related Block.

If disabled whatever is stored in the DB will be used.

If enabled and the article cache time is 0, the block will be regenerated on every page load.

If enabled and the article has a cache time of greater than 1 then the block will be regenerated whenever the article cache file gets regenerated. This also works from a user point of view since the article cache files are stored based on the security level of the user viewing it.

[remyKobolski]

Looks good, but the solution is a bit dedicated:

The decision to ‘enable’ a autotag to refresh dynamically is left to the the author / moderator. The editing user must now be aware of present autotags AND must know if this autotag is supplying data for what’s related. And there is more: changing permissions for autotags will also produce errors in the content.

The caching features are not so important to consider; in most cases the content is cached by crawling agents anyway.

The best way to circumvent the problems is to run the algorithm BEFORE PLG_replaceTags is executed, store the result and rerun (on display) the algorithm when autotags are detected. So, the stored what”s related is only related to the ‘static' text of the article. Which makes the table columns consistent with each other. And, whenever PLG_replaceTags is executed, the what’s related block is refreshed.

My conclusion: — the algorithm for what’s related should detect the presence of autotags too. Or any dynamic content…. — if found, the algorithm should rerun for display only after PLG_replaceTags. — ignore cache settings. — maybe a column can be added: contains_dynamic_content_flag.

Remy aka Wim.

On 30. Nov 2021, at 17:28, Tom @.***> wrote:

Articles What's Related block I believe is stored when the article is saved in the database. They are also cached with the article if it is also cached.

Having articles cached means those with autotags that return information which can change does mean the user may not always see the latest information. This may be fine in some cases and not in others and that is why we allow if the editor wants to specify a cache expiry value for each article.

You bring up an interesting issue with the What's Related block for articles since it can include links from autotags. Since autotags content can change over time and also may change depending on who is looking at it (ex. an Admin User compared to a Anonymous user).

We also need to think of speed here since checking for links on a page can get expensive since the page itself has to be generated at that time to do the work (along with all the autotags, etc.).

The other thing to consider is that in most cases this will not be an issue for most articles on most websites.

So what is the ideal solution taking into account this issue will not affect most articles?

I guess ideally we would have another setting for each article that the writer can enable which will signal Geeklog to always generate the Whats Related Block.

If disabled whatever is stored in the DB will be used.

If enabled and the article cache time is 0, the block will be regenerated on every page load.

If enabled and the article has a cache time of greater than 1 then the block will be regenerated whenever the article cache file gets regenerated. This also works from a user point of view since the article cache files are stored based on the security level of the user viewing it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Geeklog-Core/geeklog/issues/1103#issuecomment-982802180, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMY6ZESJWIW4AKYR7YVZZTUOT3ULANCNFSM5JCDHSGQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.