Hi Jan-Philip, What would be nice is if you could apply the workaround defined at http://jira.xwiki.org/browse/XWIKI-8046?focusedCommentId=71549&page=com.atla... and let us know if that fixes your issue. This will have 2 benefits: * We'll know it's the same problem * You'll have a patch for your issue till the issue is really fixed in the core Thanks -Vincent On Jan 18, 2013, at 11:41 PM, Jan-Philip Loos <[email protected]> wrote:
We upgraded to the latest minor versions as they were released, first migration was from 3.1 to 4.2, followed by 4.2 -> 4.3 and finally 4.3 -> 4.4
The problem still occurred with 4.3 (4.4 is to new to figured it out now). In the last 3-4 month the problem occurred round about 3 times. I wrote a small script which compares the name of the header image. If the name is not the one customized in the XWiki.DefaultSkin it notifies me with an email.
Notable: When the problem occurs its tends to occur on the same weekday - Wednesday, but not regular every Wednesday. I checked all system crons and xwiki scheduled jobs, no one was triggered at the same time the problems occurred. The rate seems to be lower than before, but I guess it's only because the crawler isn't as active as before and we have less visits per day.
To outline it once more: - When I flush the cache manually with the Admin Tools extension, the subwiki is immediately restored. - The state (e.g. the header) is not the one from the main XEM-Wiki, its the default one - The content of the wiki is still present, "only" the styles and sadly the rights seems to be the default one
We consider to switch now back to XE, in hope to get rid of the problem. But this seems not as easy as I hoped. Currently XEM is not super essential for us, but it will leave me sick behind not being able to solve the problem.