Forms that require a confirmation regularly append /confirm to the path, for example admin/build/modules/uninstall/confirm. However, the journal entry should actually be displayed one level above, at admin/build/modules/uninstall. Attached patch checks for a trailing /confirm in the path and strips it when found.

Not sure though, if this can be easily generalized that way. And an upgrade path for existing journal entries is missing here, too.

CommentFileSizeAuthor
#2 journal.action.patch2.97 KBsun
journal.patch731 bytessmk-ka

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Assigned: smk-ka » sun

It seems that admin/build/modules (system_modules()) is a special form, since it sends form values to the path admin/build/modules/list/confirm (still system_modules()), which then invokes the confirm form system_modules_confirm_form(). That's pretty ugly code in core.

However, I think we could store the real location of a form already in the $form array via form_alter()... I'll go and check that out now.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Title: Better handling for confirmation forms » #action support
StatusFileSize
new journal.action.patch2.97 KB

Yeah, this works out.

During testing I discovered that journal entries for the form on admin/build/block are not saved. However, seems to be a different issue, because I did not find any entries for that path in Journal logs of existing sites (and I'm pretty sure I've entered journal entries on that page before).

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs review » Fixed

Committed with a small fix in db update function.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.