Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-25636

The url.standard.hideViewAction property has no effect and url.standard.entityPathPrefix does not replace xwiki.defaultservletpath

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Major
    • None
    • 18.9.0
    • URLs
    • None
    • Unknown

    Description

      xwiki.properties advertises two URL properties as replacements for older xwiki.cfg ones:

      • url.standard.hideViewAction — "Note that this replaces the old xwiki.showviewaction property in the xwiki.cfg file." (xwiki.properties.vm:1034-1039, since 7.2M1)
      • url.standard.entityPathPrefix — "Note that this replaces the old xwiki.defaultservletpath property in the xwiki.cfg file." (xwiki.properties.vm:1017-1024, since 5.2M1)

      Neither statement is true of the running product.

      1. url.standard.hideViewAction is read by nothing

      StandardURLConfiguration.isViewActionHidden() has no caller in main code. The only occurrences in the whole platform are the interface, DefaultStandardURLConfiguration, LegacyStandardURLConfiguration and two comments in{} AbstractEntityResourceReferenceResolver. A scan of every jar in a shipped WEB-INF/lib (18.9.0) finds the symbol only in
      xwiki-platform-url-scheme-standard and xwiki-platform-legacy-url, i.e. the declaring classes.

      Its last caller was removed by 52dfa89f801 (XWIKI-12842, "Improve URL backward-compatibility after introduction of Nested Spaces", 2015-11-20, 7.4), which replaced the conditional parsing with the unconditional one that is there today. The property has had no effect since.

      What actually decides whether view appears in a generated URL is XWikiServletURLFactory.addAction() calling{{ XWiki.showViewAction()}} (XWiki.java:7184-7194), which reads the XWikiPreferences field showviewaction and then xwiki.cfg's xwiki.showviewaction (default 1).

      2. url.standard.entityPathPrefix only affects parsing

      getEntityPathPrefix() has exactly one consumer in main code, StandardStringResourceTypeResolver:60, which decides whether an incoming path segment introduces an entity path. Generated URLs come from XWiki.getServletPath() (XWiki.java:5688-5699): xwiki.servletpath, falling back to xwiki.defaultservletpath when the request path does not start with /bin. So the property changes which URLs XWiki accepts, never the ones it emits — it does not replace xwiki.defaultservletpath.

      3. url.standard.entityPathPrefix is read under another name

      LegacyStandardURLConfiguration overrides DefaultStandardURLConfiguration (priority 900 in its components.txt) and ships in every distribution, so it is the implementation that runs. Its getEntityPathPrefix() calls super.getWikiPathPrefix() rather than super.getEntityPathPrefix(), so the value it returns comes from url.standard.multiwiki.wikiPathPrefix, with xwiki.defaultservletpath as its default:

        String prefix = super.getWikiPathPrefix(this.xwikicfg.getProperty("xwiki.defaultservletpath", "bin"));
        

      Steps to reproduce

      On a 18.9.0 standalone distribution, counting the links the home page generates:

        curl -s http://localhost:8080/xwiki/bin/view/Main/WebHome | grep -o '/xwiki/bin/view/' | wc -l
        
      • stock configuration:40
      • url.standard.hideViewAction=true in xwiki.properties + restart: 40 (no change)
      • xwiki.showviewaction=0 in xwiki.cfg + restart: 0 — links become /xwiki/bin/Sandbox/, while edit links correctly keep their action

      On the same instance, requesting /xwiki/bin/view/Main/ after each change and a restart:

      • stock configuration: 200, document Main.WebHome
      • url.standard.entityPathPrefix=zzz in xwiki.properties: 200, document Main.WebHome (no change)
      • url.standard.multiwiki.wikiPathPrefix=zzz in xwiki.properties: 404, document bin.view.Main.WebHome — bin is no longer recognised as the entity prefix, so every page URL 404s while /xwiki/rest still answers

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            ecojocariu Eleni
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: