Not logged in. · Lost password · Register
Forum: General Help and Support Syntax and Usage RSS
Can upload images, but cannot view
phrax #1
User title: DokuNoob
Member since Mar 2012 · 5 posts · Location: BC, Canada
Group memberships: Members
Show profile · Link to this post
Subject: Can upload images, but cannot view
I'm having problems using images in the dokuwiki pages created. NO problems creating the pages themselves, or upload pictures, but can't seem to view images that have been uploaded to the server.

Environment...

The browser(s) where the problem has occurred, and does it happen in all browsers or just certain browsers?
- firefox 11
- internet explorer 8
The operating system on which the browser is installed
- windows xp sp3
The Dokuwiki version
- Release 2012-01-25 "Angua"
The operating system on which Dokuwiki is installed
- windows 2008 r2
The web server (apache or something else).
- iis 7
Enabled plugins
- none other than stock (acl, config, info, plugin, revert, usermanager)

Steps taken...

1. Enter playground page (or any other page)
2. edit page
3. enter some fluff
4. save
5. view page and confirm that editing works
6. edit the page
7. insert image button - "media files" browser window opens.
8. select "select files" button
9. select a small (~55KB) 6qmry.jpg from the local filesytem
10. click upload
11. hop on server (RDP) and check in D:\inetpub\DokuWiki\data\media\6qmry.jpg and confirm that file has been created and is good.
12. click Done  button in Media Files browser window
13. Media Files browser window lists image filename (no thumbnail in FF, box with red X in IE) listed along with dimensions, size and view, media manager and delete buttons
14. Clicking view original button opens a new window with the url https://<server>/lib/exe/fetch.php/6qmry.jpg
15. The page is blank.
16. Right clicking the blank page and selecting "view image info" shows the correct filename along with the type: jpeg, size: 54.5KB but the dimensions are 0x0
17. Close the page info window, and the browser window for viewing the image.
18. Go back to Media Files browser window.
19. Clicking the image filename opens a 'link settings' area. selecting 'no link' for the link target and leaving alignment and image size as defaults.
20. click insert - code is inserted into editor window

{{:6qmry.jpg?200|}}

21. click save
22. wiki page renders, no image.
23. clicknig view source in the browser to view the relevant code..

<p>
foo foo foo
</p>

<p>
<a href="/lib/exe/detail.php/6qmry.jpg?id=playground" class="media" title="6qmry.jpg"><img src="/lib/exe/fetch.php/6qmry.jpg?w=200" class="media" alt="" width="200" /></a>
</p>

24. The img tag calls /lib/exe/fetch.php/6qmry.jpg?w=200
25. I should be able to view https://<server>/lib/exe/fetch.php/6qmry.jpg?w=200 in the browser
26. Open a new window and try to view that page. it does the same as trying to preview it earlier. Picture details are there but the geometry is 0x0 so the page is blank.

I've searched the forum, but maybe my search terms are out to lunch. Does anyone know why this is happening?

Thank you.
This post was edited on 2012-03-21, 20:07 by phrax.
Avatar
Taggic (Moderator) #2
Member since Jan 2011 · 738 posts · Location: Gilching, Germany
Group memberships: Global Moderators, Members
Show profile · Link to this post
I cannot solve it but the HTML output for pictures on my set-ups (with your picture)
looks like following:


<img src="/lib/exe/fetch.php?w=200&amp;media=playground:6qmry.jpg" class="medialeft" alt="" width="200" />

That may depend on your DokuWiki settings.

In your case the media seems not to be stored to the media/playground folder. That is not necessarily a fault if you have uploaded it flat into the media directory. Usually the picture is uploaded to a media path according your current namespace in edit.

Please check if the image path you are using is correct (picture stored to media or media/playground). I would prefer using of full qualified path instead of relatives.

Another point is the a href link. You have not set any specials like no link and such pictures on my systems have following link info:
<a href="/lib/exe/detail.php?id=playground%3Astart&amp;media=6qmry.jpg" class="media" title="6qmry.jpg">

And again that my differ according DokuWiki settings (e.g. you may have target="_blank_" within the <a> tag if target for open links and files is configured as such).

I would propose you upload the picture via FTP try the embedding via Media Manager again (not upload) and compare the behaviour.
best regards
Taggic
f-con wiki: http://www.fristercons.de/fcon/
phrax #3
User title: DokuNoob
Member since Mar 2012 · 5 posts · Location: BC, Canada
Group memberships: Members
Show profile · Link to this post
Hey Taggic,

Thank you for the response. You're right in noticing that I uploaded the file into the media root and not the playground namespace. I did that as a test, but have again tested by uploading the file (via the Media Files window) and placing it in the playground namespace. So the file now exists at D:\inetpub\DokuWiki\data\media\playground\6qmry.jpg However this had no affect on the problem.

With your second comment, this time I selected No Link and Original Size. So, no more w=200, and the A HREF should be gone too. Upon inserting with the options noted, this is wiki code is placed in the page.

{{:playground:6qmry.jpg?nolink|}}

And I can see that it is rendering correct HTML after saving and viewing the playground wiki page.

<p>
<img src="/lib/exe/fetch.php/playground%3B6qmry.jpg" class="media" alt="" />
</p>

However the images still do not load. Nor the embedded image within the rendered wiki page, or simply taking the img src value and attempting to view it as http://<server>/lib/exe/fetch.php/playground%3B6qmry.jpg As you can see the filename is URL encoded, but that is still accurate. Trying to replace the %3B with a / simply returns "Not Found".

So, I fired up openssl to see what's going on. Since I have http (tcp 80) shut down on that box (and don't plan on enabling it at this point), I opened up firebug in firefox and grabbed the HTTP request. I did it this way to continue using the existing cookies for my session, since auth is required to get into the wiki...

GET /lib/exe/fetch.php?media=6qmry.jpg HTTP/1.1
Host: <server>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: DOKU_PREFS=list%23thumbs%23aceeditor%23on%23sort%23name; DOKU_PREFS=list%23thumbs%23aceeditor%23on%23sort%23name%23link%231%23align%231%23size
%232; DokuWiki=aiq18oi4gp6mai5tn37ssvl731; PHPSESSID=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp_acl=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp=playground; DW7fa06
5a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09
Pragma: no-cache
Cache-Control: no-cache

Once connected to the server with openssl

C:\OpenSSL-Win32\bin>openssl.exe s_client -connect <server>:443

And pasted the request above. The server happily responded as it should..

HTTP/1.1 200 OK
Cache-Control: public, proxy-revalidate, no-transform, max-age=86400
Pragma: public
Content-Length: 55868
Content-Type: image/jpeg
Expires: Thu, 22 Mar 2012 09:56:28 GMT
Last-Modified: Wed, 21 Mar 2012 05:15:26 GMT
Accept-Ranges: bytes
ETag: "1d15ae119ff78c359961f5d6b97d0ed7"
Server: Microsoft-IIS/7.0
X-Powered-By: PHP/5.3.9
Set-Cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09; path=/; secure; httponly
Content-Disposition: inline; filename="6qmry.jpg";
X-Powered-By: ASP.NET
Date: Wed, 21 Mar 2012 09:56:28 GMT

  ╪ α ►JFIF....(stuff removed)

So I'm stumped. The browser thinks the image is 0x0 pixels, so I can't see it. But the web appears (only appears, because I don't have a point of reference, yet) to be returning exactly what is asked of it.

I decided to try fuling out I did try copying the 6qmry.jpg file to the root directory, bypassing fetch.php simply requesting the image right from the server. This actually worked. Here is the request sent to the server...

GET /6qmry.jpg HTTP/1.1
Host: <server>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: DOKU_PREFS=list%23thumbs%23aceeditor%23on%23sort%23name; DokuWiki=aiq18oi4gp6mai5tn37ssvl731; PHPSESSID=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp_a
cl=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp=playground; DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09
Cache-Control: max-age=0

And the associated reply...

HTTP/1.1 200 OK
Content-Type: image/jpeg
Last-Modified: Wed, 21 Mar 2012 09:58:45 GMT
Accept-Ranges: bytes
ETag: "98ba4434497cd1:0"
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Wed, 21 Mar 2012 10:13:51 GMT
Content-Length: 55868

 ╪ α ►JFIF....(stuff removed)

Just noting the differences in the responses..  When requesting with fetch.php, additional values are returned in the HTTP header. Specifically these ones.

Cache-Control: public, proxy-revalidate, no-transform, max-age=86400
Pragma: public
Expires: Thu, 22 Mar 2012 09:56:28 GMT
X-Powered-By: PHP/5.3.9
Set-Cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09; path=/; secure; httponly
Content-Disposition: inline; filename="6qmry.jpg";

So I'm not sure if something in the extra responses is causing a problem, or maybe the image is being corrupted in the response from fetch.php, but right now something is broken.

Yay details!!

Wow, I just noticed this. Not sure if it would be problematic. The responses contain one additional difference.

using fetch.php


  ╪ α ►JFIF....(stuff removed)

but when calling the image directly from the server (https://<server>/6qmry.jpg)...


 ╪ α ►JFIF....(stuff removed)

There is one extra charachter at the beginning of the line. When checking the validity of the image returned using firebug, it reports this...  "The image “https://<server>/lib/exe/fetch.php/playground%3B6qmry.jpg” cannot be displayed because it contains errors."

I bet that's what is broken. I'm beat tired and need to go home. But should be back at work in 6 hours or so.
This post was edited on 2012-03-21, 20:07 by phrax.
Avatar
lupo49 (Moderator) #4
Member since Jul 2009 · 1397 posts · Location: Warstein, Germany
Group memberships: Global Moderators, Members, Super Mods
Show profile · Link to this post
What character is it?

Edit: Seems like it is a Space character 0x20.
phrax #5
User title: DokuNoob
Member since Mar 2012 · 5 posts · Location: BC, Canada
Group memberships: Members
Show profile · Link to this post
Still investigating. Tracing through fetch.php I've narrowed the whitespace being introduced somewhere in init.php

By putting some placeholders in fetch.php I found the extra data being outputted when fetch.php calls init.php. This is the code I tossed in fetch.php to see where the unexpected output was coming from...

  print ('[FOO1]');
  require_once(DOKU_INC.'inc/init.php');
  print ('[FOO2]');

And I can see the whitespace being output in the response from the web server...

HTTP/1.1 200 OK
Cache-Control: public, proxy-revalidate, no-transform, max-age=86400
Pragma: public
Content-Length: 55868
Content-Type: image/jpeg
Expires: Thu, 22 Mar 2012 19:20:47 GMT
Last-Modified: Wed, 21 Mar 2012 09:58:45 GMT
Accept-Ranges: bytes
ETag: "8ba37fa601b7599dcfa9e004a44f8149"
Server: Microsoft-IIS/7.0
X-Powered-By: PHP/5.3.9
Set-Cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09; path=/; secure; httponly
Content-Disposition: inline; filename="6qmry.jpg";
X-Powered-By: ASP.NET
Date: Wed, 21 Mar 2012 19:20:47 GMT

[FOO1] [FOO2] ╪ α ►JFIF....(stuff removed)

So there is unexpected data between the end and beginning square brackets of FOO1 and FOO2. Now it's time to look at init.php and see what's going on.

If anyone else knows what I'm chasing, that information would be super helpful.
This post was edited on 2012-03-21, 20:06 by phrax.
phrax #6
User title: DokuNoob
Member since Mar 2012 · 5 posts · Location: BC, Canada
Group memberships: Members
Show profile · Link to this post
Subject: [SOLVED]
For the sake of the community, I will continue to document this as I have found the problem...

Humans!  We're the problem!

I put some placeholders in init.php to see where the extra data was being introduced. Narrowed it down to this section...

print('[FOO-101]');
// load the global config file(s)
foreach (array('default','local','protected') as $config_group) {
    if (empty($config_cascade['main'][$config_group])) continue;
    foreach ($config_cascade['main'][$config_group] as $config_file) {
        if (@file_exists($config_file)) {
        print ('[Including_('.$config_file.')]');
        include($config_file);
        }
    }
}
print('[FOO-102]');

So, It was between FOO-101 and FOO-102, so I tossed in a print line for every file that was being included. The web server responded with...

HTTP/1.1 200 OK
Cache-Control: public, proxy-revalidate, no-transform, max-age=86400
Pragma: public
Content-Length: 55868
Content-Type: image/jpeg
Expires: Thu, 22 Mar 2012 19:37:32 GMT
Last-Modified: Wed, 21 Mar 2012 09:58:45 GMT
Accept-Ranges: bytes
ETag: "8ba37fa601b7599dcfa9e004a44f8149"
Server: Microsoft-IIS/7.0
X-Powered-By: PHP/5.3.9
Set-Cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09; path=/; secure; httponly
Content-Disposition: inline; filename="6qmry.jpg";
X-Powered-By: ASP.NET
Date: Wed, 21 Mar 2012 19:37:32 GMT

[FOO1][FOO-101][Including_(D:\inetpub\DokuWiki\lib\exe/../../conf/dokuwiki.php)][Including_(D:\inetpub\DokuWiki\lib\exe/../../co
nf/local.php)][Including_(D:\inetpub\DokuWiki\lib\exe/../../conf/local.protected.php)] [FOO-102][FOO2] ╪ α ►JFIF...

FOO1 and FOO2 were introduced in fetch.php (as noted in the previous post) with the follownig lines ...

  print ('[FOO1]');
  require_once(DOKU_INC.'inc/init.php');
  print ('[FOO2]');

So, we can see a FRIKKIN space after local.protected.php is loaded. That would be the file I had to edit to get the AD integration working. The space after including local.protected.php was being displayed because I had accidentailly placed a space before the <?php tag on the first line of the file.

After removing the leading space in local.protected.php and removing all the placeholders in fetch.php and init.php, DokuWiki is now loading images correctly. I can view the images linked within wiki pages, they show up properly when using the Media Files window.

For those who have read this far, you get a gold star.
phrax #7
User title: DokuNoob
Member since Mar 2012 · 5 posts · Location: BC, Canada
Group memberships: Members
Show profile · Link to this post
This is the file I was using to test this problem..

[Image: http://i.imgur.com/i2ngG.jpg]

That might explain a few things.
Avatar
nasonov #8
Member since Apr 2012 · 1 post
Group memberships: Members
Show profile · Link to this post
In reply to post #6
Haha! I've just had the same problem. It has cost some time for me, but thankfully I've found your posts before made it rather strong. Frankly, it wasn't your mistyping. I think we both had the same source(link for old revision, i've edited it now) for our AD authentication config.
Avatar
tomatebi% #9
Member since Aug 2012 · 1 post
Group memberships: Members
Show profile · Link to this post
In reply to post #6
Subject: I still have the same problem
 I am new in dokuwiki. I installed a dokuwiki-2012-01-25b.tgz “Angua” (includes Hotfix 2).

  My installation does not have a local.protect.php  (just local.php) and I dont know which placeholders have to change.

Could you be more specific? 

Thanks in advance
Avatar
Taggic (Moderator) #10
Member since Jan 2011 · 738 posts · Location: Gilching, Germany
Group memberships: Global Moderators, Members
Show profile · Link to this post
please read following information regarding local.protect.php configurations
Configuring DokuWiki -> Configuration Options
best regards
Taggic
f-con wiki: http://www.fristercons.de/fcon/
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20120620-dev, © 2003-2011 by Yves Goergen
Current time: 2014-04-20, 15:19:07 (UTC +02:00)