has code (e671e72053e81fa, which depends on 72ac9821e56637) that fixes
this. --[[intrigeri]]
+link() pagespec on translation pages
+------------------------------------
+
+The `link()` pagespec, on translation pages, currently tests whether
+a given page links to the *current translation page*, rather than
+whether it links to its master page. I believe the later is generally
+expected. Commit 646c9a4c95a480 in my po branch fixes this.
+--[[intrigeri]]
+
Documentation
-------------
--- /dev/null
+I'd like to have some pages of my wiki to be only viewable by some users.
+
+I could use htaccess for that, but it would force the users to have 2 authentication mecanisms, so I'd prefer to use openID for that too.
+
+* I'm thinking of adding a "show" parameter to the cgi script, thanks to a plugin similar to goto.
+* When called, it would check the credential using the session stuff (that I don't understand yet). If not enough, it would serve a 403 error of course.
+* If enough, it would read the file locally on the server side and return this as a content.
+
+Then, I'd have to generate the private page the regular way with ikiwiki, and prevent apache from serving them with an appropriate and much more maintainable htaccess file.
+
+-- [[users/emptty]]
+
+> While I'm sure a plugin could do this, it adds so much scalability cost
+> and is so counter to ikiwiki's design.. Have you considered using the
+> [[plugins/httpauth]] plugin to unify around htaccess auth? --[[Joey]]
> that is clearly a raw page name, it can add it to the exact depends hash.
> Else, add it to the pagespec hash. You can tell if it's a pure page name
> by matching on `$config{wiki_file_regexp}`.
->
+
+>> Good thinking. Done in commit 68ce514a 'Auto-detect "simple dependencies"',
+>> with a related bugfix in e8b43825 "Force %depends_exact to lower case".
+>>
+>> Performance impact: Test 2 above takes 0.2s longer to rebuild (probably
+>> from all the calls to lc, which are, however, necessary for correctness)
+>> and has indistinguishable performance for a refresh.
+>>
+>> Test 1 took about 6 minutes to rebuild and 1:25 to refresh; those are
+>> pessimistic figures, since I've added 90 more photos and 90 more pages
+>> (both to the wiki as a whole, and the number touched before refreshing)
+>> since testing the previous version of this branch. --[[smcv]]
+
> Also I think there may be little optimisation value left in
> 7227c2debfeef94b35f7d81f42900aa01820caa3, since the "regular" dependency
> lists will be much shorter.
->
+
+>> You're probably right, but IMO it's not worth reverting it - a set (hash with
+>> dummy values) is still the right data structure. --[[smcv]]
+
> Sounds like inline pagenames has an already exstant bug WRT
> pages moving, which this should not make worse. Would be good to verify.
->
+
+>> If you mean the standard "add a better match for a link-like construct" bug
+>> that also affects sidebar, then yes, it does have the bug, but I'm pretty
+>> sure this branch doesn't make it any worse. I could solve this at the cost
+>> of making pagenames less useful for interactive use, by making it not
+>> respect [[ikiwiki/subpage/LinkingRules]], but instead always interpret
+>> its paths as relative to the top of the wiki - that's actually all that
+>> [[plugins/contrib/album]] needs. --[[smcv]]
+
> Re coding, it would be nice if `refresh()` could avoid duplicating
-> the debug message, etc in the two cases. --[[Joey]]
+> the debug message, etc in the two cases. --[[Joey]]
+
+>> Fixed in commit f805d566 "Avoid duplicating debug message..." --[[smcv]]