Publication Workflow Application breaks local Image Links on Published pages

[zwork]

Running Publication Workflow v2.4.2 in XWiki 17.1.0

Thanks to the dev team for a useful extension! However, I’ve noticed the following subtle bug impacting image links to local attachments on child pages in the page tree that is being published:

If you configure the link with the fully qualified page identifier and attachment name, that link gets properly updated when published. The image displayed is the image file attached to the page in the published tree.

However, if you insert the image with just the attachment file name, which works fine on the draft source page then the publishing workflow prepends the link with the top page path but fails to include the child page that actually has the attached image file. Thus, the image link is broken.

Image links on one page in the tree to attachments on other pages in the tree publish just fine - because those have fully qualified paths.

E.g., on a source page in the DRAFT tree I have two images that are local attachments on that page. In the first I edited the link to be fully qualified, in the second its the ‘shorthand’ link to the local attachment that is commonly used for local attachments:

[[image:Publication Workflow Testing.DRAFT EXAMPLE.Attachments Test Top Page v1\.4.Attachments Test Child Page.WebHome@calvin-hobbes-calvin-and-hobbes-23762778-1280-800_0.jpg||alt="calvin" height="31%" width="50%"]]

[[image:Spiff's_spacecraft.png]]

When I publish to a RELEASED tree, the links have been updated to:

[[image:Publication Workflow Testing.RELEASED EXAMPLE.Attachments Test Top Page v1\.4.Attachments Test Child Page.WebHome@calvin-hobbes-calvin-and-hobbes-23762778-1280-800_0.jpg||alt="calvin" height="31%" width="50%"]]

[[image:Publication Workflow Testing.RELEASED EXAMPLE.Attachments Test Top Page v1\.4.WebHome@Spiff's_spacecraft.png]]

The 1st link is correct. The 2nd link is broken, pointing at the parent page (that is the root of the published tree) rather than the child page that contains the attachment.

Unfortunately, when using the WYSIWYG editor to upload and insert and image on a page it is inserted with the short attachment reference (even if writing in raw markup that’s the quick and easy way to do it as well). Thus, for many users who use just the WYSIWYG editor mode or enter local attachments per the XWiki docs, those local images will break when the page is published.

I suspect that handing the ‘deep copy’ of links within a published tree to translate correctly while links to wiki targets outside of the published tree was one of the more ‘interesting’ problems to solve when you implemented this extension. I guess this edge case (although perhaps not uncommon) fell through the cracks.

(PS I haven’t fully tested on and off page PDF and Office attachments)

cheers!

[zwork]

Addendum:

Testing with {{pdfviewer/}} and {{office/}} macros, unfortunately, I found that the page references in those are not updated at all by the publishing workflow. The attachments that they reference and display remain the attachments on the draft pages. Is that intentional in the Publishing Workflow or an unaddressed issue?

This is subtle. Some use cases actually might want to have this behavior, but in that case perhaps the attachments shouldn’t be copied to the published page since those are not referenced on that page. That could be an optional behavior.

Perhaps the more common use case would be that all macros on the published pages that reference attachments anywhere within the published page tree should be updated to reference those attachments rather than the attachments back in the draft tree. This maintains revision consistency in the published page tree and decouples it from changes to attachments in the the draft page tree.

I’ve yet to learn me some groovy and do any groovy/velocity dev directly within xwiki so I’m sorry I can’t help solve this “properly” in the short term.

I have develped some Python tools to mangle exported page tree XAR files. I may extend those tools with a basic ‘deep copy to publish’ capability to meet our immediate needs, albeit without the interactive workflow features. Our use case is publishing a large tree of organizational processes and procedures to a location accessed by our staff whilst we revise and add to them in the draft area. That page tree has many attachments and cross-links, and will have an increasing number of custom albeit basic xwiki applications (a great feature!).

cheers to all the core XWiki devs and folks contributing extensions!