I’ve recently migrated an old XWiki (8.4.5 IIRC, WAR deployment) from an old Windows server to a new Linux machine and upgraded XWiki to 16.10.3 LTS, Tomcat to 9 with Java 17, Postgres to 16 and placed it behind an Nginx.
I’ve gone through all the release notes several months ago in preparation for the migration, but I don’t remember specifics anymore. I’ve stumbled on some errors with the new XWiki, one of which is CKEditor crashing with a vague and unhelpful “Internal error” and losing data, which prompted me to disable xwiki-realtime plugin.
However, my current main issue is with copying pages. In the old XWiki, when copying a page with all its children and attachments, the copied attachments retain their revision history, original author and original upload date. This is not the case with the new XWiki. Instead what happens is all this is rewritten with the user who’s performing the copying. I.e. attachments lose revision history, the original author is overwritten with the author who’s performing the copying action and the upload date is set to the current date and time. In my case, this is not a desired behaviour. Is it possible to revert to the old behaviour where all this is retained?
One other thing is error handling. For instance, I have a user who is trying to copy a page with its children, but there’s always a page missing, and the process finishes with a yellow warning about errors. If I do it with my Administrator account, the process finishes successfully, but even if it doesn’t, there is an active log I can read on the copy page. This is missing for the regular, non-admin user, which makes troubleshooting difficult. Is there any way to enable this log for normal users? Or at least a log somewhere I as an admin can find and use for troubleshooting?
You can see revision history is lost, the date is changed to the time the page was copied and the author of the attachment is changed to the user performing the copying action. The “hacky” workaround - which I’m not too fond of - is to go into page history and revert it to the state before it was copied. That (mostly) reverts the changes to reflect the original page’s attachment data.
The behavior on XWiki 8.4.3 is different. If I copy the page with all its children, the attachment data is preserved. The only difference I’ve noticed is the new XWiki switched the attachment list to LiveData, and I’m guessing this is where the discrepancy in behavior is.
I cannot reproduce this attachment history loss problem on XWiki 16.10.3.
Are reproducing this attachment revision loss when copying a page created with XWiki 8.4.3, or a new page that you then move ?
The default store for attachments content changed in XWiki 11.0 (database → filesystem) and I’m wondering if we have on bug related to moving attachments from one store to the other.
I’m not sure if it’s a typo, but this is XWiki 16.10.3.
Let’s say I have a page with multiple subpages. Several of these subpages have attachments. In the old XWiki 8.4.3 if I copy one of these subpages, the behavior is that attachments retain their original metadata. I.e. the revisions would still be there, the date would reflect the date of the last revision/upload and author would be the last user who uploaded the file. In this case, 8 revisions, last one on 2025/01/14 by John Doe.
Here is an example of a copied page with attachments retaining the metadata of the original page in XWiki 8.4.3:
The original page and its attachments remain in place, nothing is moved, just copied.
Meanwhile, the behavior of XWiki 16.10.3 is that the copied attachments on the copied page lose this metadata and revision history, as you can see in the screenshot from my previous message
Are reproducing this attachment revision loss when copying a page created with XWiki 8.4.3, or a new page that you then move?
Doesn’t matter. The behavior is the same whether the page and the attachments were created on the old XWiki version or the new one.
The default store for attachments content changed in XWiki 11.0 (database → filesystem) and I’m wondering if we have on bug related to moving attachments from one store to the other.
Yes, I’m aware. Our XWiki 8.4.3 was set to save attachments on filesystem through xwiki.cfg file.
And what do you have in xwiki.cfg now ? Have you reverted your customization ? The way to configure the attachment content storage changed a bit since 8.4.3.
I checked the config, I think this is the relevant part:
# xwiki.store.recyclebin.content.hint=file
#-# The attachment content storage.
xwiki.store.attachment.hint=file
#-# The attachment versioning storage. Use 'void' to disable attachment versioning.
xwiki.store.attachment.versioning.hint=file
#-# [Since 9.9RC1] The default attachment content recycle bin storage.
#-# This property is only taken into account when deleting an attachment and has no effect on already deleted documents.
xwiki.store.attachment.recyclebin.content.hint=file
Looks OK, but you should comment them since it’s the default already (better really set what you need in xwiki.cfg, makes much easier to merge during upgrades).
I kept thinking about rename (which is apparently working fine) so that’s what I tested. I confirm that I reproduce the same regression with copy (strangely, since rename is copy+delete from storage point of view).
I’ve noticed that this link always points to the latest version of the document, even if I change the revision number in the link, and even if it’s a non-existent revision number. For instance, let’s say there is the original attachment and one revision. I get the same outcome if I replace rev=1.2 with rev=1.1 and rev=1.9. I.e. it links to the latest version of the attachment, which is rev=1.2. Why is ?rev=## included when changing the number or entirely removing that part points to the latest document either way? Is this expected behavior?
If I wanted a specific revision, I’d have to click on the superscript revision number and choose there anyway, since the path is different then, .../download/... vs .../downloadrev/...:
The goal of that URL was not so much to point to a specific version of the attachment, but to make sure the URL is different (to avoid browser cache problems).
