Hi All,
I’ve realised that since setting up urlrewrite as per Short URLs, uploading from click a browse button and using the windows dialog box fails. Tried in /admin/XWiki/XWikiPreferences and directly on a page using the attachments browse button.
It does however work fine when you drag and drop an image or file onto a page when editing with wysiwyg, or using the browse button in File Manager.
Before setting up Short URLs the upload definitely work as I had uploaded a few company Logos for subwikis without issue.
I’ve set xwiki up as ROOT webapp, hidden /view, and urlrewrite setup to remove /bin. I haven’t had any other issues with urlwrite, that I’m aware of at least.
The only difference in the urlrewrite.xml is I removed the gwtrpc rule as I’m using 14.2.1 (13.10 at the time of setting up urlrewrite)
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN"
"http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
<urlrewrite decode-using="null">
<rule>
<note>
Ensure that URLs that must not be served by the Struts Servlet are not modified.
</note>
<from>^/((bin|resources|skins|asyncrenderer|rest|webdav|xmlrpc|wiki|jcaptcha|webjars)/(.*)|robots\.txt)$</from>
<to type="forward" last="true">-</to>
</rule>
<rule>
<note>
For all other URLs we prepend the "/bin/" prefix so that they get routed to the XWiki Action Servlet.
</note>
<from>^/(.*)$</from>
<to type="forward">/bin/$1</to>
</rule>
<outbound-rule>
<note>
Rewrite outbound URLs to remove the "/bin" part when there are two paths after it.
</note>
<from>/bin/(.*)/(.*)$</from>
<to>/$1/$2</to>
</outbound-rule>
<outbound-rule>
<note>
Rewrite outbound URLs to remove the "/bin" part when there's a single path after it.
</note>
<from>/bin/(.*)$</from>
<to>/$1</to>
</outbound-rule>
<outbound-rule>
<note>
Rewrite outbound URLs to remove the "/bin" part it's the last path.
</note>
<from>/bin$</from>
<to>/</to>
</outbound-rule>
</urlrewrite>
There is also an issue with notifications not loading , or even showing No notifications message, but this was happening both before and after urlrewrite. I think it is an IIS reverse proxy issue as notifications work when accessing the wiki locally via http://{ipaddress}:8080.