Item9703: Preserve skin specified via URL across topic actions like edit, history, raw view, save etc.
Priority: Normal
Current State: Proposal Required
Released In: n/a
Target Release: n/a
Sometimes users add a
?skin=foo
(or
?cover=bar
) parameter to the URL. That skin/cover should be preserved on all pages linked from the rendered page, unless explicitly overridden (say by a link to view a page with a different skin). That is, the Edit, Raw view, Attach, revisions, differences between revisions etc. links should add the
skin=foo
URL query parameter to the URL in order to keep the skin. This roughly means that all templates should add something like
;%QUERYSTRING%
to all
<a href
links, with a few caveats:
- most of the time, there won't be any query parameters. In those cases, the ';' at the end of the links will be unnecessary
- adding the entire QUERYSTRING may add extraneous parameters. Links to differences between revisions, if they appear in a page that list a revision already (URL has
?skin=foo&rev=123
), should not carry on the ?rev=123 parameter, but stay as rdiff/Web/Topic?skin=foo;rev1=124;rev2=125
One idea would be to create a %SKINARGS% macro, similar to the %REVARG% macro (currently undocumented, see
Item9702). This macro would output the skin and/or cover, and prefix them with a semicolon if at least one of them was in the URL; otherwise return the empty string:
-
;skin=foo
-
;cover=bar
-
;skin=foo;cover=bar
- <empty string>
Are there other URL parameters that should be preserved across topic actions?
--
DanDascalescu - 17 Sep 2010
I think such behavior will create more problems than it will solve to be honest. Constantly trying to hack urls will go wrong. It would be better to add a feature and maybe UI to enable setting skin and cover in session variables carried either by cookie or in the stored session files. And even with that we have to be careful. You can end up fighting for minute getting a print skin to stop being active.
--
KennethLavrsen - 17 Sep 2010
I agree that this is probably a big enough change to warrant feature proposal first.
I
don't think we should expect users to hack the URL directly in order to change skins. For example, we don't an AJAX request with
?skin=plain
to emit links with
?skin=plain
in them - those links should remain with the user's setting.
I
do think we need an easy way to change skin.
Doing it with session variables + making accessible in UI is probably the best way.
--
PaulHarvey - 17 Sep 2010