Good day!
Found an unpleasant bug in Xwiki 10.10. when you create a page with a long name on Russian language.
The problem is that this page is not deleted in any way possible.
Moreover, such a page and its child pages cannot upload attachments.
Pages with short titles work correctly.
Tell me what could be the problem and how can it be solved?
This looks like Loading.... The current workaround is to change the storage in xwiki.cfg from file (the default) to hibernate (search for the “Stores with both “hibernate” and “file” support in XWiki Standard.” section).
Thanks so much for the quick response! Now I will try to switch the file storage to the Database and accomplish the results.
So what I did:
<property name="connection.url">jdbc:postgresql://localhost:5432/xwiki</property>
<property name="connection.username">xwiki</property>
<property name="connection.password">xwiki</property>
<property name="connection.driver_class">org.postgresql.Driver</property>
<property name="dialect">org.hibernate.dialect.PostgreSQLDialect</property>
<property name="jdbc.use_streams_for_binary">false</property>
<property name="xwiki.virtual_mode">schema</property>
<property name="hibernate.connection.charSet">UTF-8</property>
<property name="hibernate.connection.useUnicode">true</property>
<property name="hibernate.connection.characterEncoding">utf8</property>
<mapping resource="xwiki.postgresql.hbm.xml"/>
<mapping resource="feeds.hbm.xml"/>
<mapping resource="activitystream.hbm.xml"/>
<mapping resource="instance.hbm.xml"/>
<mapping resource="notification-filter-preferences.hbm.xml"/>
<mapping resource="mailsender.hbm.xml"/>
</session-factory>
Uncommented storage strings in /etc/xwiki/xwiki.cfg:
xwiki.store.main.hint=hibernate
xwiki.store.versioning.hint=hibernate
xwiki.store.recyclebin.hint=hibernate
xwiki.store.attachment.recyclebin.hint=hibernate
xwiki.store.migration.manager.hint=hibernate
xwiki.recyclebin=1
storage.attachment.recyclebin=1
xwiki.store.versioning=1
xwiki.store.attachment.versioning=1
xwiki.store.rollbackattachmentwithdocuments=1
xwiki.store.hibernate.path=/WEB-INF/hibernate.cfg.xml
xwiki.store.hibernate.updateschema=1
xwiki.store.hibernate.custommapping=1
xwiki.store.cache=1
As a result, I had the feeling that the wiki still stores attachments on a local disk, and not in the database. This can be seen in the changeable contents of the folder /var/lib/xwiki/data/storage/xwiki/. The problem with downloading attachments to pages with a long name has remained. Also, these pages are still not deleted.
Also, I could not find a full instruction on setting up a wiki for storing files in the database without using a local disk. Can I somehow not so tune?
XWiki always need a database. Only deleted documents and attachments are stored as files by default.
This is not what I told you to modify.
You should only modify what is in the Stores with both "hibernate" and "file" support by default. section.
See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments#HAttachmentStorage.
Thanks for your tips. I understood my mistake and set the following parameters in the xwiki.cfg file:
xwiki.store.recyclebin.content.hint=hibernate
xwiki.store.attachment.hint=hibernate
xwiki.store.attachment.versioning.hint=hibernate
xwiki.store.attachment.recyclebin.content.hint=hibernate
xwiki.store.recyclebin.hint=hibernate
After that, XWiki started storing attachments to the database and the problem with the pages being deleted and the impossibility of downloading attachments disappeared.
But there was one small problem related to the speed of loading attachments. I set a limit on the size of downloadable files to 100 MB. Small files are loaded fairly quickly, but files as small as 50 MB are processed for a very long time.
Is it possible to somehow increase the speed of loading and processing large files when working with a PostgreSQL database?
50MB is actually quite big from database storage point of view, that’s the kind of issues that made us move those to the filesystem by default. As for PostgreSQL database specifically I don’t know it well enough to suggest tricks sorry.
I hope we’ll have time to address the UTF8 encoding issue in the FS storage in 11.0 (so in about 1 or 2 month).
Thank you very much for helping me solve my problem!
I really hope that in version 11 with the storage of files in the file system everything will be fine! =)