CamelCase Wiki Links always display as missing page

[Norbert Unterberg <nunterberg@…>]

We have a strange thing going on here. We have one repository where CamelCase wiki links always display as invalid link (in grey with a question mark). The refered page does exist, so that is not a problem. Some examples:

• TestPage displays as link to missing wiki page (grey with question mark)
• [wiki:TestPage] displays as valid link (red with underline)

The trac environment was copied from a different server (running Trac 0.8) using plain copy command, and the name of the environment was changed. The trac-admin upgrade/wiki upgrade procedure as been done, and all other features work fine.

Other Trac environments on the same server seem to work fine. However, I have once noticed the same on another environment, but before I could write a bug report the problem went away by magic.

[Norbert Unterberg <nunterberg@…>]

Some additional information:

The problem disappeared when I set the check_auth_ip ini setting to false. Can someone explain what is going on here, or what this setting means?

[Christopher Lenz]

Do anonymous users have WIKI_VIEW permissions?

[Norbert Unterberg <nunterberg@…>]

No, the anonymous user did not have WIKI_VIEW permissions. Adding it did not improve it. I forgot to write that the links work correctly, it is just they display as if the pages were missing.

Our setup is a bit different from the recommended, maybe that's a problem. We have no <Location …/login> section in our apache config file, since all users authenticate and anonymous access is not allowed (this is an internal company network). Instead we have the Require valid-user directive inside the <Location /projects> section. We are running Trac from trunk in revision [2288].

One additional observation: After restaring the Apache service, the links do work correctly on the first Trac environment that is used, and fail on all others (we have trac setup for multiple projects). Maybe mod_python mixes up environments when looking for the links?

[Tim Hatch <trac@…>]

I also see this running two environments on the same server via mod_python and Trac 0.9b2 (on Debian stable, for the most part). It's a little weirder for me though, in that restarting apache will toggle which one is is used for resolving CamelCase links' existence with pretty good accuracy. Both environments were upgraded as per the documentation (from 0.8.4), and, like Norbert's case, everything else appears to work properly.

Being logged in or not did not seem to change the behavior for me.

[Christian Boos]

Just a guess: this is maybe related to #1750. It would be interesting to see if you also have the problems described above when using the InterTrac branch, which implements an alternative solution for #1750.

(you can easily test the InterTrac branch by applying attachment:ticket:2041:trac-0.9b2-intertrac-r2308.patch​)

[Tim Hatch <trac@…>]

The InterTrac switch fixes the problem for me.

[Christian Boos]

I'll prepare a patch containing the appropriate bits from InterTrac.

[Christian Boos]

Fix the issue by taking the approach already implemented in InterTrac

[Christian Boos]

The "alternative" approach is actually more than that… it is the correct approach: in the trunk, it's the Formatter class that keeps track of the link resolvers, i.e. the link resolvers of the environment which was the first to need the Formatter…

All subsequent formatting from any other environment will make use of the link resolvers kept in the static Formatter._link_resolvers… Those link resolvers are of course still referring to their original environment (those are lambdas containing a reference to the self of their component).

This explains the difference seen between the CamelCase syntax (a link resolver tied to the wrong environment) and the wiki: link syntax (the correct environment is used).

Also, I don't quite understand the necessity of a periodic reload of the page index. Initializing the index on first use and then maintaining it with the change listener methods should be enough, shouldn't it?

[Christian Boos]

Oops, sorry, in the above explanation, I used "link resolvers" where I should have used "external handlers". Link resolvers are actually kind of OK since r1979 and that's why the wiki: link work. External handlers are not OK, and that's why the CamelCase syntax fail.

[Christopher Lenz]

I think the proposed change is nice.

Not related, but to answer your question about the page index:

Also, I don't quite understand the necessity of a periodic reload of the page index. Initializing the index on first use and then maintaining it with the change listener methods should be enough, shouldn't it?

This is true for threaded servers, but not for servers using the prefork/worker model. There you'll have multiple processes running against the same environment. Only one of them will get notified using the WikiChangeListener mechanism. The others would still use the old page index.

[Christian Boos]

Patch applied in r2313.

About the periodic reloading of the page index: OK, I understand the context now, but I think that one could instead poll the db for a change, e.g. something like:

  # in WikiSystem

  def _update_index(self):
    ...
    cursor.execute("SELECT value FROM system WHERE name='wiki_generation'")
    row = cursor.fetchone()
    if row:
      if int(row[0]) > self.generation:
         # update the index

  # in WikiPage

  def delete(self, ...):
    ...
    if version is None:
      # Delete a wiki page completely
      cursor.execute("UPDATE system SET value = value+1 where name='wiki_generation'")

  def save(self, ...):
    ...
    if self.text != self.old_text:
      cursor = db.cursot()
      cursor.execute("INSERT ...")
      if self.version == 0:
        cursor.execute("UPDATE system SET value = value+1 where name='wiki_generation'")