This is a static dump of issues in the old "Flyspray" bugtracker for DokuWiki. Bugs and feature requests
are now tracked at the issue tracker at Github.
Closed
Fixed
FS#2405 New media link behavior breaks plugins using FETCH_MEDIA_STATUS
Customization
2011-12-07Michitux
As reported on the mailinglist (http://www.freelists.org/post/dokuwiki/Behavior-change-with-the-new-media-file-manager) with Angua the behavior of media links changed, links to missing files now point to the media manager. This makes it impossible for plugins to use the FETCH_MEDIA_STATUS event to handle missing media files. As outlined in my answer (http://www.freelists.org/post/dokuwiki/Behavior-change-with-the-new-media-file-manager,1) there are also additional problems as the cache is not updated when linked media files change (and this would require further changes) which means that links to media files added after the link was created can't be reached directly.
My suggestion as also written on the mailinglist is:
- revert to the old behavior for Angua
- After the release implement the following changes:
- Index media links so they can be easily found (this could also be used to display pages where a file is referenced in the media manager)
- Make the cache of pages depend on referenced media files
- Offer different syntax for links that point to the media manager instead to the media file (either always or just when the file doesn't exist), keeping the current behavior as default.
I haven't changed anything yet as I would like to get feedback from other developers if plugin authors should work around this (either by intercepting calls to the media manager which is imho ugly or by replacing the media syntax) or if we should revert as I've suggested. This bug report is a reminder so this issue won't be forgotten as there was not feedback on the mailinglist for a week on this topic.
2011-12-08andi
Step one sounds good to me.
I'm not so sure I understand the reason why page caches should depend on the referenced media files.
2011-12-08Michitux
Because otherwise the color and the link target (if the target depends on the existence of the file) doesn't change when files are created or deleted. Actually the page should depend on the existence of the linked media files, i.e. it should store the current state in the meta data and compare that to the actual existence of the media files in the cache handler as it is done for linked pages already.
2011-12-10bug
I don't think we can release a version with a broken FETCH_MEDIA_STATUS, thus restoring the old behaviour is reasonable.
2011-12-17adrianlang
I don’t understand what the indexing has to do with this issue. On topic: I’d definitely revert to the old behavior. I think, lib/exe/fetch.php should redirect to the media manager when the file does not exist and the current user is allowed to upload a file; but obviously, this should happen in the default action of FETCH_MEDIA_STATUS.
2011-12-20adrianlang
The offending commit is 4a24b459 , I reverted it in df959702 . About fetch.php redirecting, I’m not so sure anymore – what about detail.php?
2011-12-26Michitux
In my opinion detail.php is good, fetch.php not that good as this might confuse download tools that expect a proper 404 response and not a redirect to an url that gives a 200 OK response.
2012-01-08andi
I agree, fetch.php should never redirect (unless someone does it in a plugin). detail.php should redirect to the mediamanager with a msg() about the file being unavailable. I'll close this bug and open a new one for the detail redirect behaviour.