Opened 13 years ago

Closed 11 years ago

#3831 closed defect (wontfix)

Error if submitted in a wiki page with version specified

Reported by: JaeWook Choi Owned by: Steffen Hoffmann
Priority: normal Component: TracFormsPlugin
Severity: normal Keywords: wiki revision historic form data
Cc: JaeWook Choi Trac Release: 0.11


When a submission of TracForm occurs in a specific version of wiki page, it causes HTTP 500 error. Especially a newly created wiki page will be redirected to version 1 after the creation of the wiki page and caused HTTP 500 error.

For example, submitting form data in wiki/SandBox/TestForm?version=1 causes HTTP 500 error while it works fine in wiki/SandBox/TestForm

Attachments (0)

Change History (3)

comment:1 Changed 11 years ago by Steffen Hoffmann

Keywords: wiki revision historic form data added
Owner: changed from Rich Harkins to Steffen Hoffmann

Sorry for late response. I took over maintainership just yesterday, and trying to catch up.

How do you expect TracFormsPlugin to work with in (older) revisions of wiki pages?

I'd suggest trying to

  1. block it at all (soon), and later maybe trying to
  2. restore older form values related to that wiki page revision.

Second point is largely in shadows for me by now. It might be hard (involving db table changes/extension or not, I don't know.

comment:2 Changed 11 years ago by Steffen Hoffmann

Summary: Error if submiited in a wiki page with version specifiedError if submitted in a wiki page with version specified

Still relevant?

We may have a version-aware Form object/Trac resource soon, not sure about connecting wiki/ticket revisions and form revisions. But it would require at least an additional column to store such an (parent) version hint.

comment:3 Changed 11 years ago by Steffen Hoffmann

Resolution: wontfix
Status: newclosed

After more fiddling around with code when introducing the 'form' resource for TracForms recently I conclude, that this can hardly work. I even find it unreasonable to put much effort in here, while other reasonable requests would have to wait, i.e. see #3445, #5667.

What are new revisions of form content for historic forms meant to represent? I argue, that any attempt towards serving such functionality is bound to screw the whole concept of current Trac's revisions: There is always a straight, unbranched line of revisions per resource. Updating content from within a historic form version means branching from that point.


  • Easiest would be to aim at clearly blocking form update requests sent from older revisions.
  • Best would be to branch revisions like in modern VCS. Older form revisions would present corresponding older form content to start editing from there automagicly. In theory it should be possible to have one history per form (parent) revision. But how to proceed after a form (parent) change? right now I can't think of a real-world use case, that would strictly require such a concept. The previous "easy" way looks still sane and simple.

All I'll do within a reasonable time frame is following #4759 for now.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Steffen Hoffmann.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.