Your XWiki usability pain points

I agree, the behavior on playground is usable, although still not perfect. To be honest, if it didn’t show the spinner when the load time is < 100ms or something, it would probably “feel” more seamless.

It is possible there is additional latency going to my AWS instance for some reason. According to the Page Index, there are 239 pages total in the wiki. From my xwiki.cfg:

#-# Maximum number of documents to keep in the cache.
#-# The default is 500.
# xwiki.store.cache.capacity=500

Is there a way to tell if the server cache is saturated? I know very little about Java. I will say, on a reboot, XWiki takes several minutes to start up, and only after the first attempt at a page view. I assumed that was XWiki caching stuff. Not sure if this is helpful, but a quick peak at free memory:

$ cat /proc/meminfo 
MemTotal:        2046536 kB
MemFree:          134408 kB
MemAvailable:     868540 kB
Buffers:          262932 kB
Cached:           444620 kB
SwapCached:            0 kB

Should I start a new topic for this conversation? It seems like there are two threads: one, can the Navigation Panel be made to be more robust; two, is there a degenerate case with re: performance on AWS t2.small instances.

I agree, it would be better to start two new threads on that. Thanks!

On my xwiki I displayed users group in user profil with this piece of code in XWiki.XWikiUserProfileSheet (with xwiki editor):

          <dd #if("$!vCardProperty" != '' && !$inEditMode)class="$vCardProperty"#{end}>$doc.display($sectionProperty)</dd>
          #end
        #end
        </dl>
      #end
    #end
    </div>
  </div>
  #if (!$inEditMode)
    <div class='half column'>

      #if (!$isGuest)
      <div class='userMessage profile-section'>
        <h1>Groupes</h1>
        ##  * $xwiki.getUserName($doc.fullName, false)
        ##  * $doc.fullName
        #set($rightsAPI=$xwiki.rightsmanager)
        #set($groupsAPI=$rightsAPI.getGroupsApi())
        #set($groups=$groupsAPI.getAllLocalGroupsNames())
        #set($user=$doc.fullName)
        #foreach($group in $groups)
          ## * [[$group]]
          ##set($user=$doc.fullName)
          #if($xwiki.getUser($user).isUserInGroup($group))
          ##* $xwiki.getUserName($user)
          * [[$group]]
        #end
      #end
      </div>
      #end

      <div class='userRecentChanges'>
      #if ($xcontext.user == $doc.fullName)
        <h1>$services.localization.render('platform.core.profile.section.activity')</h1>
      #else
        <h1>$services.localization.render('platform.core.profile.section.activityof', [$xwiki.getUserName($doc.fullName, false)])</h1>
1 Like

Another point: a user space missing. I mean a space where the xwiki user could create his personal pages (like homedir on Linux.)
Maybe the profile of user could be a parent page (and not a terminale page anymore)?

Yes ideally user profile should be or the form Users.ThomasMortagne.WebHome I think. The issue is all the code that would be broken by any change in the format of the user profile reference…

yes I think about this issue. Maybe keep XWiki.ThomasMortagne and add XWiki.ThomasMortagne.WebHome parent page (and add a link to this page in profile setting like (profile, Preference, watchlist, etc)?
(or better maybe XWiki.home.ThomasMortagne.WebHome to avoid the mess?)
I don’t know I just try to find a simple way.

I agree. Would you mind creating a JIRA issue about this? Thx

=> https://jira.xwiki.org/browse/XWIKI-14705 :slight_smile:

The problem with URL name and title name. If you give name of the page with space it creates problem when the url is generated. Escape characters are placed instead of space and when you try editing & saving the page further it gives problem. What I do is give name without space and once url is generated later on rename the title of page.
Is this problem faced by everyone and there is solution for this problem? or I am the only one with this problem here?

XWiki handles spaces in page names. Your browser will convert spaces to %20 which is normal but xwiki will handle that well. If you have a problem please describe the exact steps to reproduce but I doubt it’ll reproduce. IMO the only cases when users have such problems is when they have proxy servers which are badly configured.

Step 1: Creating new blog post with name “Demo Blog For Space”:

1

Step 2: Add content:

2

Step 3 : Save it finally:

3

This is thing is happening everywhere, while creating new page, Adding new blog post, editing the record in awm live table.
But i observed, this problem does not exist in the extensions/applications I imported.

It should be easy for you to check if the problem is local or not by testing the blog on playground.xwiki.org

I just checked it. I have two installations. On one it is handled on other it is not. The later one is the installation on which I am always having some issues. :frowning:

This thread remind me I need to review http://dev.xwiki.org/xwiki/bin/view/Community/ContributingPainPoints, something I did not do in a while and we fixed several things (including this very forum).

Would be nice if we could implement aliases since we could automatically create aliases for user profiles (i.e. XWiki.ThomasMortagne pointing to Users.ThomasMortagne.WebHome). See http://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases

I have seen quite a few other posts about the speed of the Navigation Panel, so I am going to skip the whole “debug AWS” thread.

3 wishes for a further XWiki release:

  1. Update option for XWiki release directly from the backend (as known from eg. WordPress) and as it actually works fine for plugins

  2. Project Planing tool including agile methods like Scrum / Kanban to take control over project resources like time, budget (related and steered via related project team member with individual defined hourly rates)

  3. More Design elements for direct use via drag and drop for setting up an XWiki as soon as possible for individual needs… Maybe a “flex grid system” with some standard tools would be great for making XWiki more flexible in defining more individualized elements and already coming up with a large number of predefined elements.

That would be even more great than XWiki already is today and would be a big step forward!

Yours
Sascha

I agree to this point, too. In our XWiki I would also give some enhancements to this, but do not know how to do it best…