Item13099: PUBURL has two implementations
Priority: Urgent
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component:
Branches: master
PUBURL is implemented in Macros/PUBURLPATH. However it is also implemented in Foswiki.pm in such a way that it can't be overridden.
Both PUBURL and PURBULPATH need to be implemented in Macros, and the Foswiki.pm implementation turned off.
The same is true for SCRIPTURL and SCRIPTURLPATH.
It is important that a Contrib be able to override these without patching Foswiki.pm.
--
CrawfordCurrie - 17 Nov 2014
Later: after a bit of research and discussion it's clear to me that PUBURL needs to be delegated to the store (and usage of the unparameterised form suppressed ASAP).
The problem is that a store may not hold attachments in a pub directory, and different attachments in different webs may require different URLs. An example of this
is the static 'attachments', such as JavascriptFiles, shipped with the installation. These should be served as files - there is no need to import them into a store.
To make this possible, I'm going to extend the (internal) Store API to add a
getAttachmentURL
method, and support:
%PUBURL{web="System" topic="JavascriptFiles" attachment="strikeone.js"}%
and delegate the decision about where it's served from to the store. Note that the store needs to be in a position to abort an attachment save as well. At this time
that's done through an exception, though that may be revisited.
Note: for now, there is no in-your-face functionality change, as I have supported the default
getAttachmentURL
method in Store.pm. Someone might like to experiment with getting this method to serve read-only
pub/System
content using URLs, and other content using
viewfile
.
--
CrawfordCurrie - 19 Nov 2014