On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar <c.robbenh...@posteo.de> wrote:
> Hi Devs, > > some users reported a problem to me concerning the Publication Workflow > Application and the nested pages feature. > The problem is as follows: > > In their old instance (some 6.4.x) they had a draft space and a public > space and workflows attaching each page in the draft space with a page in > the public space in an 1:1 manner, like: > > Draft.WebHome --> Public.WebHome > Draft.PageA --> Public.PageA > Draft.PageB --> Public.PageB > > Now if a link in, say, PageA in the Draft space points to another page, > e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]] > After publishing PageA, the link of the published variant points to the > published variant of PageB (and not the variant in the Draft space), which > is the desired effect from the users point of view. > > Now after migration to 9.10 the situation is as follows: > > Draft.WebHome --> Public.WebHome > Draft.PageA.WebHome --> Public.PageA.WebHome > Draft.PageB.WebHome --> Public.PageB.WebHome > You should be able to force the application to create terminal pages as a temporary workaround. Then we need to see if it makes sense to add support for publishing a hierarchy of nested pages. > > Now a link to PageB in PageA looks like: [[link > text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the > same space, but each in their own space. > Publishing the draft makes the link in the published variant point back to > the Draft space, of course. However this is different from the behavior > before nested pages and the users experience this as a bug. > > A manual solution would be to edit all pages and make the links point to > the published variant of the pages. However this is not only a cumbersome > and error prone task, but also the users are used to the "automatic" link > conversion that made links in the published variant point to published > pages and are wont to continue setting links to pages in the draft space, > expecting them to point to the "right place" after publishing. > The fact that now titles are used throughout in the navigation tree, and > the titles of the draft and published variant are usually the same and thus > indistinguishable complicates the problem even more. > > To fix this I could write a separate extension that listens to Publish > events send from the Workflow extension, and which converts the links in > the published variant before it gets saved. > However I remember that I once experienced strange issues where the events > were sometimes not send to the event listener in question, probably due > some class loader issues or the like. > (I only experienced these problems in a production instance and was not > able to hunt them down in a development instance.) > > Also I cannot think of a use case where users want to link from a > published variant back into the draft space (except for pointing to the > draft version of the page itself, which is provided by the panel, however.) > > Thus I would like to implement the link transformation in the extension > itself. If a link in a page points to a page in the draft space of that > workflow, I would change that link in the published variant to point to the > corresponding published variant of the link target. > I could add a checkbox to the workflow class so people can switch of that > link transformation if they do not want it. > > > What do you think? Are there any objections to implementing such a > feature? Or do you have different ideas how to solve the problem? > > Best Regards > Clemens >
