Edgewall Software
Modify

Opened 19 years ago

Closed 19 years ago

#2138 closed defect (fixed)

CamelCase Wiki Links always display as missing page

Reported by: Norbert Unterberg <nunterberg@…> Owned by: Christian Boos
Priority: highest Milestone: 0.9
Component: wiki system Version: 0.9b1
Severity: minor Keywords:
Cc: nunterberg@…, dserodio@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (1)

wiki_engine_state_in_WikiSystem.patch (6.7 KB ) - added by Christian Boos 19 years ago.
Fix the issue by taking the approach already implemented in InterTrac

Download all attachments as: .zip

Change History (14)

comment:1 by Norbert Unterberg <nunterberg@…>, 19 years ago

Severity: normalminor

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?

comment:2 by Christopher Lenz, 19 years ago

Do anonymous users have WIKI_VIEW permissions?

comment:3 by Norbert Unterberg <nunterberg@…>, 19 years ago

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?

comment:4 by Norbert Unterberg <nunterberg@…>, 19 years ago

Cc: nunterberg@… added

comment:5 by Tim Hatch <trac@…>, 19 years ago

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.

comment:6 by Christian Boos, 19 years ago

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)

comment:7 by Tim Hatch <trac@…>, 19 years ago

The InterTrac switch fixes the problem for me.

comment:8 by Christian Boos, 19 years ago

Owner: changed from Jonas Borgström to Christian Boos

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

by Christian Boos, 19 years ago

Fix the issue by taking the approach already implemented in InterTrac

comment:9 by Christian Boos, 19 years ago

Milestone: 0.9
Priority: normalhighest
Status: newassigned

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?

comment:10 by Christian Boos, 19 years ago

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.

comment:11 by Christopher Lenz, 19 years ago

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.

comment:12 by anonymous, 19 years ago

Cc: dserodio@… added

comment:13 by Christian Boos, 19 years ago

Resolution: fixed
Status: assignedclosed

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'")

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.