When I change the title of a Wiki page it disappears from the Page Contents section although it still appears in the "All Pages" section.
This is a real pain as it no longer appears in the list of pages available for parent page selection and of course is not visible in Page Contents.
I am currently working round this by deleting my wiki and starting again - not a workable solution.
Also. Is the list of pages in the contents section always sorted a-z, or can this be modified with a query override? Even if this is possible you really need to be able to order pages ad hoc within this list for obvious reasons.
I've discovered the same problem.
I gave up on Wikis late last night, then today took a look again and my pages had re-appeared.... I changed the parent on one of the newly appeared pages and it got lost again..
I reported this a few days ago. If you restart the IIS Application the pages will re-appear instantly so seems to be a cache issue of some sort. It renders the whole Wiki module useless though.
thanks, at least I can now work around it - you're right though, useless until it's fixed.
As you have discovered, this is due to some aggressive caching. This issue is logged under 2 tickets: 1705 and 1752. We are trying to fit this work into the SP1 release.
Does this wiki problem also cause the same mulitple postings under the Site Activity section? Because that is the problem I have been having.
vrc: Does this wiki problem also cause the same mulitple postings under the Site Activity section? Because that is the problem I have been having.
That's a separate bug, logged as #1743. We are trying to fit in a fix for this in SP1.
First can someone clarify if this announcement is the sp1 release spoken of in this thread? (It would seem 2008.5 is sp1). If that is in fact that sp1, that it appears this fix did not make it in. Looks like there was an sp1 and sp2 for 2008 already, so is there an upcoming sp1 for 2008.5?
First of all I would like to say overall I love Community Server and an amazing amount of work has gone into it this great product.
That said this bug is particularly disappointing. Telligent do you realize that even after releasing the first service pack for 2008 the Wiki is still completely defective except for all but the most basic Wiki use cases (flat pages)? I'm honestly shocked you decided to ship the Wiki functionality in this state.
It was immediately clear to me on my first sit down with the Wiki that it was highly defective. Not only is the Wiki hierarchy completely crippled for real-time editing, but deleting a Wiki page does not remove it from the database immediately, which means the page appears gone, but trying to create a new page by the same name fails. I've been having to remove the pages directly in the database by hand. Also the tag entry is unreliable and defective as well. Tags entered when creating a page rarely show up when going back and editing the page. And sometimes tags added after a page has been created in the "edit tags" link are registered in the database, but they do not appear when browsing and editing the page. Sometimes tags do not appear in the tag cloud widget. When updating tags often times complete portions of the Wiki hierarchy disappear altogether (in the widget).
Really not having the cache for the Wiki hierarchy / widget cleared as soon as the hierarchy has changed is unacceptable. Wikis are all about quick content editing in real-time. There's no way I want to sit around and wait for the table of contents to update when the cache recycles (essentially restarting the web server each time I make an edit to hierarchy) to share my content with other Wiki collaborators or readers. A flat list of pages for a Wiki with a large hierarchy (common) is not an intuitive way to traverse a vast amount of content (this is an extremely poor work around).
From my experience with working with the Community Server source code this data is being stored in the applications cache object (System.Web.Caching.Cache). In theory the solution should be fairly easy to implement:
When the web page returns after an update that triggers one of those actions, it will pull the structure from the newly updated cache. If no one edits the hierarchy the data remains cached.
Ultimately if the current Wiki hierarchy structure is stored in just one or a few data structures in the web application's cache, and this is bad for performance, you can always take an approach where each level of the tree is stored in its own cached entry. Use a creative string convention with the cache key to programmatically link the required hierarchy tree level with its corresponding cache entry. This way you can only update the cache for the hierarchy level that was effected by the record change.
Anyways I will be looking forward to the day that the Wiki is usable, this will be a great feature and addition to Community Server!
michael.everett@gmail.com: First can someone clarify if this announcement is the sp1 release spoken of in this thread? (It would seem 2008.5 is sp1). If that is in fact that sp1, that it appears this fix did not make it in. Looks like there was an sp1 and sp2 for 2008 already, so is there an upcoming sp1 for 2008.5?
I'll quickly answer this part. No, CS 2008 SP1 <> CS 2008.5 SP1. The latter will be released any day now, and it includes a lot of work in the wiki space.
This is great news, thanks for the confirmation.
Copyright© 2008 Telligent Systems Inc. All rights reserved CommunityServer.com • Telligent.com