"useslash" option breaks "Orphanmedia", all paths parsed incorrectly?

[misterjmw]

Seems that using the feature, "useslash" (useslash - Use slash as namespace separator in URLs) which improves readability for our largely IE user base (Based on documentation this should be just a character replacement feature and should not be used in actual pathing as namespace structure is still used everywhere (e.g. :wiki:intro)) breaks the links to images/media as anywhere colons are found, they break the plugin (or at least that's my best guess) and I get one of three conditions:

1. Media is listed as missing, but you can go to the page and it works fine.
2. It lists the media, but with an improper UNC path, image referenced at the bottom.
3. Some items are listed as orphans, but the namespace path listed, is the entire UNC path (with a double colon on the front) not the path to the actual media. Example:

Path Shown:
http://server.foo.com/wiki/lib/exe/detail.php?media=::foo.com:main:this%20office:wiki:data:media:department:menu.jpg

versus the correct namespace path that DOES work:
http://server.foo.com/wiki/lib/exe/detail.php?media=:department:menu.jpg

Configuration:
Server: IIS 7.5 (Windows 2008 R2)
PHP: v5.3.8
Dokuwiki: Angua Release.
Data: Located on UNC path outside of webroot.

Images:
UNC path to file (multiple slashes are required for PHP, but the colon is turned into a slash): http://i.imgur.com/NLOhI.gif
Standard Dokuwiki image: http://i.imgur.com/XvUMv.gif

/Apologies for the multiple edits, I just keep digging.

[Taggic]

1. Media is listed as missing, but you can go to the page and it works fine.

please provide an example of such media link syntax and if it is inside other tags (e.g. )

PS: I'll work on UNC path issue after point 1 is solved

[Taggic]

Please check if the new version resolves your point number 1 and provide syntax examples for points 2 & 3

[misterjmw]

I'll cite a page that's not been modified by me, since they seem to be throwing errors as well. Using compare, there are zero differences between my copy of :wiki:syntax page and this one http://www.dokuwiki.org/syntax

The author's method of usage is typical: {{wiki:dokuwiki-128.png}} but the resolution by Orphanmedia fails.

Orphanmedia shows: http://i.imgur.com/iatIZ.gif

As confirmation, the page does display correctly, and I do have "dokuwiki-128.png" in the correct location.

I will test the new version and report back, Thank you for your fast response.

[Taggic]

STOP, there is a new bug I've just implemented.

[misterjmw]

Noted. It also does not appear that this version changes the output from Orphanmedia.

Apologies, in several places I've noticed that http://www.dokuwiki.org/plugin:smblink smblink is in usage. This may be in relation to those using UNC paths. The large majority of the media are direct uploads into DW not UNC. I am not familiar enough with the plugin structure to know the interrelation between Orphanmedia and smblink.

[Taggic]

useslash does still not work but now I know wher the problem is ...
After that is solved I will search for smblink .. docu to figure out if and how I could solve that.

[Taggic]

Just solved a fatal error on Configuration Management caused by faulty config file ...
Tested with and without useslash option, both is working on my two systems. It does not seem to be there an issue. doku.php accepts the links anyway.

orphanmedia first has to learn how to detect smblinks and how it can be checked. The link seem to be very helpful but I've to doe some further analysis.

[Taggic]

I tested around with your {{wiki:dokuwiki-128.png}} issue. Copied the syntax page, stored the pictures into proper media folder, all that things. Additionally I've uses slashes and canonical urls with different combination. On my system it is working like a charm.

Regarding smblinks. I created a share of a local folder and implemented the link to a picture as explained on DW syntax page (http://www.dokuwiki.org/syntax#windows_shares). It is displayed as a share. Unfortunately if I click on the link nothing happens (I'm using IE9). I don't know what should happen but I expect that something it does (?)

Are you using the smblink plugin ? What happens if you click on such a link ? What browser you are using, FF or IE ?

[misterjmw]

I am going through my configuration and disabling addons then re-running orphanmedia to see if I can get it to generate a different result to test if it is an addon at fault or strictly a result of my configuration. Is there a cache or similar that I I should clear between viewings of the orphanmedia page?

We are using a mix of IE9, FF and Chrome. Through we don't just link to the raw shares, we link to files in them. In IE9, clicking a UNC share will prompt you to Open or save the file and it will then open the file in the associated program. In Chrome/FF it'll just save it.

I'm compiling screenshots.

[Taggic]

Is there a cache or similar that I I should clear between viewings of the orphanmedia page?

Orphan media itself is not caching anthing but DokuWiki cache seems sometimes a tricky thing. There are two cache functions implemented. One for the Text output and another one for the functios. I've not experienced a cache influence to orphanmedia but that is not a guarantee.

regarding your point 2
Any improvement on that ?
Does it work if you switch off the useslash ?

regarding shares:
So I did a mistake creating the share due to nothing happens on a click.

[misterjmw]

I'll add the nocache tag to the same page as orphanmedia, I think that should handle any potential caching issues with DW, it will induce overhead on reloads of that pages but should insure that the information is accurate. (I've enabled this as well, and saw no change in my output.)

Going down the list of addons, I didn't see any immediate change but I was concerned with the cache giving me stale information, I was waiting until I'd heard back. Turning off "useslash" would be a drastic change, as it caused instability initially and this is a live system. I'll evaluate making that change tonight and maybe late into the evening when I can kill time if I take down the wiki/restore it from a backup if it goes down.

Regarding the shares, make sure you're linking to a file.
In IE the difference between an uploaded file and a UNC link should be nothing.

In FF you get a message:
"Firefox doesn't know how to open this address, because the protocol (smb) isn't associated with any program."
Based on this, I'm disabling use of the smblink plugin as it doesn't seem to be working in Angua.

Then immediately following that you get a message (which is what pops up immediately in Chrome)
"Linking to Windows shares only works in Microsoft Internet Explorer.
You still can copy and paste the link."

I believe this message is enabled by:
$lang['js']['nosmblinks'] = ''; #fix for SMB Links throwing error messages

I have uploaded several test files using UNC method and tested them without the smblink addon, this is the result I see:
http://i.imgur.com/1m8dS.gif

In the red box, I've copied the formatting from the wiki, trimming the domain and such. I tried it with and without a description, both files were shown as missing.

[Taggic]

... nocache tag ... that should handle any potential caching issues with DW ...

Unfortunately not. As mentioned before, DW has two cache mechanism. NOCACHE refers only to the html output and effects text, pictures, styl, etc. It does not effect the functions cache. Just to explain it but that is not the root cause here.
(status of Rincewind, just had not enogh time to dig into Angua code, which may have more caching mechanisms to improve the performance).

I'm sorry, I'm a bit confused where we are. I've lost the overview. Could you please just summarise me the status regarding:

Media is listed as missing, but you can go to the page and it works fine.

Is that still the case ? Are these Media files you referring stored locally into dw/data/media/... or do we talking only about smblinks ?
I want to separate the smblink problem from others (if there are). Your picture showing only external links, thats why I'm asking.

It lists the media, but with an improper UNC path ...

Do we still have this path mismatch also after last plugin update a few days ago. The path displayed within your last picture seems to be ok (Is there an path error I missed ?)

... but the colon is turned into a slash ...

Isn't that the same question as point 2 ?

[misterjmw]

The colon interpreted as a slash issue is gone. So, if I need to file another bug report under a different title for what I'm experiencing, I will. I apologize that the issues seems to have skewed.

This is the output of OrphanMedia currently:
http://i.imgur.com/0os9f.gif

I think this information comment may have been brushed over but I feel it's very important:
"Data: Located on UNC path outside of webroot." We are using the config option "savedir" (http://www.dokuwiki.org/config:savedir) to relocate the data directory outside of the webroot path.

So, no, the files are not in that path. They are relocated. If Orphanmedia abides by the "savedir" config option, then everything should be ok.

[Taggic]

Thanks for the picture (excellent) and the savedir hint (very helpful, I never mind on savedir).
Indeed I did not check the savedir settings within orphanmedia.
I will need a bit time to implement the savedir check and handling.

[Taggic]

Found the code-line disturbing the useslash setting and modified this.
Found the code-lins where to use savedir configuration instead self-made local path and exchanged this.
Tested with local and server DokuWiki (Rincewind) . It is working as before (no test of external savedir path).
I did something but don't know if it helps you anything ...
please check.

[Taggic]

during review found a second code-line disturbing the useslash setting and modified this.
also modified the preview sizing of orphan pictures (curretly fix max width/height settings, maybe it becomes configurable with a later release).

Hope that helps your issue.

[misterjmw]

Just an FYI: The latest update causes a 500 Internal Error on any page I load it on, can't explain why.

I was writing this update below as you posted that new code:

Glad the picture helped.
I've started to look through your changes and see what could possibly be breaking, however, I am not great with PHP so this is a slow journey of stepping and prodding while not taking down a live system.

In syntax.php:104,
I see you're stripping out the media path (yay!) from the links before it changes the slashes into colons. However I think something is awry.

I've gone through and added a few debugging echos and it doesn't seem like "savedir", mediadir", or "pagesdir" ever make it to the page, they always echo empty. $media_file_path does just fine as does any number of the DOKU_ variables and so on. But I think the reason the savedir isn't being removed from the strings is because the variable is simply blank when the routine calls for it.

The actual function of "savedir" is described here: http://www.freelists.org/post/dokuwiki/more-cleanup-questions,5 but it doesn't seem that it's a global variable that can be called upon: http://www.dokuwiki.org/devel:environment

The code you added (previous to 500 Error) seems like it's sound and might be a fix, but I can't tell since the variables (mediadir & pagesdir) are empty.

Back on my image from the other day;
Take note of the double colons I highlighted in the image. Is there a "//" that is being converted into "::"?

I also noticed (as you can see on line number 1, 2 and 106 through 108 of my picture) that there is a slash missing in front of "departments." If that is the same string it is evaluating for the path, then might that cause it to fail since it's starting from the wrong place. Shouldn't it begin with a "/" or a ":"?

Just some ideas.

[misterjmw]

Just as a sidenote, adding "&do=debug" shows that in the array $conf all three variables are there. Should be able to access them by that means.

I am also off on vacation for a week as of today. I will be able to respond after then. Have a great week!

[Taggic]

so, you are out for holidays and I have the pain ... ;-)
I wish you a relaxing week.

[Taggic]

Hard to say what the root cause of a 500 Internal Server Error is. You updated the orphanmendia plugin so I would blame it. The error may be caused by exceeding the Memory threshold (php.ini => memory_limit). All Orphanned pictures will be previewed (if type of jpg, png, gif). If the plugin detects all your pictures as orphan it might exceed the memory limit ....

Problem could be raised by client side resizing of the picture. I have to investigate this. Also I will implement a config paramter to prevent preview of more than x pictures. Lets hope your 500 Internal Server Error will disappear. I'll do the mod and upload the changes.

[misterjmw]

Alright, back from my travels and back onto debugging. Hope your week vacation from my bug was nice!

The 500 error seems to appear when using a 'broken' plugin for some reason. I can't explain much more than that as any plugins that fail to load, or have code that doesn't pass as PHP seems to exhibit a 500 error to the end user since any page view also loads any plugins that might be needed to display it correctly.

The PHP memory limit is set at 512MB. Haven't had problems with anything else so far.

Have not implemented the new code yet. I did notice this while looking through the debug information, take note of the change in types of slashes used:

Page: http://foo.com/wiki/orphanmedia?do=debug
snip
[filepath] => \foo.com\local\this office/wiki/data/pages/orphanmedia.txt
snip

I'll download the latest version, I assume it's been updated to read the variables in the $conf['savedir'] method.

[Taggic]

Please update the plugin on your set-up and set the new config parameter. Sorry I cannot find such problem on my set-ups so it is impossible for me to trace anything regarding this. Therefore I'm asking you to check if that 500 error still occur after the update. If so than please delete the orphan plugin and check again. If the 500 error still is coming up than it is caused by something else (not fair but my hope ;-).

[misterjmw]

Updated Plugin. "500" issue didn't come back, however I had to delete the page with the ~~ ORPHANMEDIA:all ~~ embed before DW would update, I was given the same page over and over despite having purged everything.

Sadly not much has changed in the output:
http://i.imgur.com/YvEPI.gif

[Taggic]

"500" issue didn't come back

That is a progress I guess. Have you used the new parameter, what value ?

Output Image - Missing

Are all other findings correct (beside those 2 you marked with a box) ? Which of the files within the picture are wrongly detected as missing ?

Output Image - Orphan

The title of the orpahn document in preview seems to be ok just the link is mismatched. The path provided in column 2 seems to be correct also. Is this file referenced on a page or is it really orphan ? Can you open the doc by putting the path into your browsers address field ?

---

It is really hard to find a root cause without having access to the pages. There are so many questions which cannot be handled properly in here. Is there any way of a remote access r.g. by team viewer that we together might have a look on it ?

[misterjmw]

500 Issue - I can only assume this was a quirk here. It can be ignored. The new parameter is set to it's default value of 10.

As the title block states, all the files are shown as missing, I've truncated the page, I apologize, I should have said as much, I didn't feel it was necessary to give you a long page.

At the moment I'm doing a replace on the page to remove internal information so occasionally I may mistype. The is the reason why I haven't suggested a 'team viewer' type method. If there's a faster, less public means maybe something can be worked out, I'm all ears but the plugin reveals more information than I can give out (thus the reasoning behind "foo.com")