Include doesn't create backlinks any more since Hogfather

[tmo26]

Dokuwiki: Release rc-2020-06-09 "Hogfather" RC3
Include plugin: Installed version: 2020-04-16

Previously, includes via page or section include created a backlink.
Since the upgrade to Hogfather, no backlinks are visible any more.

Exception: At least pages that have been edited recently do show backlinks to included pages.

Example:

1. searchindex rebuild on 29.06.2020 01:46 (with clearing / removing) the old index
2. page edited on 29.06.2020 05:14
3. check backlinks of included page: only one backlink of the recently edited page visible, although 1686 pages do have this include
4. different page with this included edited on 29.06.2020 07:17 -> backlink now shows up, in addition to the previously edited page, but still 1684 backlinks missing.

[michitux]

Is it possible that the included page is not public? The safeindex configuration option might also influence this, is this option enabled in your wiki? Possibly the searchindex rebuild indexed the whole wiki without a user, and thus the include plugin only considered public pages. Whenever a page is edited, the page is indexed again by a user that can read the included page.

[tmo26]

The included pages are public, they have no special access restrictions.
@ALL = read
@user = read, edit

safeindex is activated, but shouldn't have any effect since the included pages are public.
Indexer is run via sudo -u www-data /var/www/dokuwiki/bin/indexer.php -c from inside a script

[michitux]

Then this is clearly a bug that I cannot easily explain. I will try to find some time to take a closer look. Did this work before upgrading to Hogfather in an otherwise unchanged wiki?

[tmo26]

Yes, before Hogfather it definetly worked.

[michitux]

I think I understand at least why it does not work, I do not understand why it did work in the past. The reason is that at some point I thought it was a good idea to filter out pages the user cannot access rather early. This has the consequence that the include plugin does not even create a relation references metadata for them even when they are directly referenced in the wiki text. And therefore they also cannot be found in the backlinks. In theory, this should only affect non-public pages. However, in the CLI indexer, no session is created and as far as I understand the code, in this case actually all ACL checks return AUTH_NONE, i.e., that the page cannot be read by the current user. Therefore, via the CLI indexer, no information for backlinks is created. In the "normal" indexer runner, a session is at least present initially and thus those ACL checks are executed for the current user. I do not understand why this has not been an issue in the past. I could not find any relevant code change with respect to these ACL checks. An explanation might be that some cached information has been used in the past and metadata has not been regenerated. I'm also not aware of any changes with respect to caching, though.

Anyways, the correct fix for this is to always generate relation references metadata for all pages that are candidates for inclusion even when the ACL check says that there are no read permissions. I will see if I can get this fixed without too many changes.

Just for reference, this issue is most likely also the reason for broken move plugin support, see #259.

[tmo26]

Thanks for your feedback and looking into this! :)

[Klap-in]

@michitux I have not yet looked into this, but is this something only in this plugin, or are there possible changes in DokuWiki needed? If yes, it is good to open an issue at DokuWiki repository as well and get it included in the next release.

[michitux]

I haven't followed the latest changes in DokuWiki that closely, but from my analysis I think this is something in this plugin, basically my comment above explains what needs to be done. It's just not a one-line-fix but instead a rather fundamental change where ACL checks happen that also affects caching (though cache handling should also be changed, anyway, as the current state is rather fragile). I have no idea when I'll find the time to do this, if you have some time and want to look into this, I would also be happy to explain my ideas (or how this plugin works in general) in more detail.

[Klap-in]

It is interesting, but at the moment I have quite some other thing on my wish list, and as this one will take some effort, I prefer not to dive in it at the moment.

[fthommen]

thanks a lot for looking into it @michitux and @Klap-in. However your assessments leaves me slightly unsure about the future of the this plugin. I see that #274 has just been solved, but other issues might pop up at latest with the next DW release. Our department Wiki relies heavily on page includes. The problem with the renaming (#276) has just come up recently.

Basically I think that what the include plugins offers should be a core functionality of DW

[michitux]

If you rely on this plugin in your company/institution, I would suggest paying for commercial support instead of relying on volunteers maintaining this plugin in their free time. Have a look at https://www.wikimatrix.org/consultants/dokuwiki/ for a list of DokuWiki consultants if you are looking for a suitable consultant (note that I'm not affiliated with any of them).

[tmo26]

Whenever you will find time to look into this: Your efforts are appreciated!
In case you need someone for testing, please let me know.