When a link in a page points to a file in the folder of the page, like <a href="/typography/x.pdf">Download</a>, Grav is not involved. The webserver itself will happily download the file, unless… - The file doesn’t exist - File permission issues - .htaccess issues - other issues beyond my imagination…
<UPDATE>
Above statement is incorrect. Grav’s involvement in fetching files depends on the url being used:
Url points to the file’s path: /user/pages/02.typography/myimage.png
=> Grav is bypassed
These urls are generated with adding images in Markdown using  or using Twigs {{ (page.media|first).html() }}
Url points to a route: /typography/myimage.png
=> Grav is needed to parse the url
</UPDATE>
A weird thing is:
Both files are in the same folder, but they produce different errors…
Maybe, there is a collision with cache when cache folder has also been copied? Try bin/grav cache and also clear the cache in the browser
Also try the following:
Create a fresh install of Grav 1.7.34
Copy file 17_2019_KT-Kolloquium_Tagungsband.pdf into folder /user/pages/02.typography/ and add link <a href="/typography/17_2019_KT-Kolloquium_Tagungsband.pdf">Download</a> to file /user/pages/02.typography/default.md.
If the download fails, your probably have one of those “unless” issues in which case I have no more suggestions…
support of the weboster first said, i have to clear the cache.
So i did in the admin interface a “clear all caches”.
This did not resolve the problem.
Next was to deactivate the caching on the server.
So i had to add to modify htaccess and for php the user.ini
htaccess → Header always set Cache-Control: s-maxage=0
user.ini → opcache.enable=0
This also did not resolve the problem.
Is there a guidance how to completely deactivate caching?
Next was to deactivate the caching on the server.
So i had to add to modify htaccess and for php the user.ini
htaccess → Header always set Cache-Control: s-maxage=0
user.ini → opcache.enable=0
Why would you want to do that?
Maybe a misunderstanding of my suggestion to “clear the cache in the browser”. I meant to make sure the browser is forced to send a request to the server. For that you can use:
Windows and Linux browsers: CTRL + F5.
Apple Safari: SHIFT + Reload toolbar button.
Chrome and Firefox for Mac: CMD + SHIFT + R.
Or (in Chrome at least), you can set option “Disable cache (while DevTools is open)”
It would probably not make a difference, it is just a matter of routinely making sure the browser is not causing any side effects.
To prevent further miscommunication: What is your level of expertise if I may ask?
thank you, i will try tomorrow when i have more time
your question about the pictures i can already answer:
at the site editorial board (Editorial Board | Grav) there are already pictures in the page … and, they do not have the problem of not loading.
please have in mind, that we have put all other pdf’s at this site in an extra folder outside grav. we linked them like http://www.kt-kolloquium.de/download/Corves_en.pdf because we needed a quick solution. but this solution is not how grav should work
This reminded me of a page I made about six months ago, so I checked the links and the source templates. Sometimes I make comments in the source about unexpected kludges but this time I didn’t unfortunately. However I do remember the link URLs weren’t what I expected (or preferred really).
So if you look at the paths, they show the full path in /user including Grav folder prefixes. (Note that a new version of this page not yet launched moves these files out of modular folders, but they still show /user/... and prefixes.)
I don’t think you specify whether you are coding your link via page markdown or in a template. I used a template pulling filenames from frontmatter. For what it’s worth, here is a simpification of the template that serves these URLs (current modular page version). It may be useful:
{% if page.header.abstracts is defined %}
{% if page.header.abstracts.file is defined -%}
<a href="{{ page.media[page.header.abstracts.file].url }}" class="image clear" type="application/pdf">
{%- endif -%}
....
{% endif %}
So I’m letting Grav derive the URL here.
I also thought of the possibility that multilingual paths are screwing up your media URLs, but simply removing the language path did not help. (My limited experience with multilingual pages makes me think paths can be buggy.)
i have to confess that i have not everything understood you wrote,
but i found some interessting things of the path where pictures and douments are linked
At your mentioned site it is all like https://marinebioinvasions.info/user/pages/60.archives/_icmb-x/ICMB-X.pdf
At my site i found differences like this
pictures: http://kt-kolloquium.de/user/pages/06.editors/Rostock.png
pdf: http://kt-kolloquium.de/de/history/1_2003_book_of_abstracts.pdf
Pictures are linked like yours, but the “not working” pdfs are completely different.
Could somebody explain?
By the Way.
I did a test with another hosting provider.
I created an test account, copied a backup to the account and everything worked fine, inluding the linked pdfs…
So, i see the possibility that some settings at Grav and/or Server could solve the problem.
Sorry it probably was confusing! I think your host’s setting might be the problem here as others suggested. One of the problems with shared/managed hosts is that you often lose control over this kind of configuration. Good luck!
according to my question regarding your hint of the symlinks i got this answer from the support of the hosting provider:
symlinks are already set correctly
furthermore they told me to test these .htaccess rules:
Header set Accept-Ranges none
RequestHeader unset Range
I am not happy, the result is the same …
have a look at http://grav.lscad.de/
I put the links at the end of the typography page.
The first link is done as you described, the second one is done within grav.
@Stephan, Hm… Is the file still symlinked, or located in the folder of the page? If still symlinked, try also copying the file into /user/pages/02.typography
And also
Above link bypasses Grav (see my update).
The link <a href="/typography/17_2019_KT-Kolloquium_Tagungsband.pdf">Download</a> does require the involvement of Grav.
Even if the link to the path of the pdf does work, which hints to an issue with Grav, I’m still inclined thinking is not an issue with Grav, since using the same site on different servers yields different results…
i just got a message from the support of the hosting provider
they added RequestHeader unset Range to the .htaccess and the download for pdfs works now as expected.
