Closed (fixed)
Project:
Media Browser Plus
Version:
7.x-2.x-dev
Component:
Documentation
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 Mar 2012 at 07:22 UTC
Updated:
14 Oct 2014 at 06:20 UTC
Jump to comment: Most recent
Comments
Comment #1
doublejosh commented#1717270: How to enable Library plus tab?
Comment #2
doublejosh commentedTrying to understand the need for a subfolder #1875356: File root as media root
Comment #3
das-peter commentedActually I don't see why the heck the files should be moved at all.
I mean there's code that does that, but I don't get why it does this...
Comment #4
darksnowI've just been hit with this too.
Thankfully on a test site but now all media linked in content is broken!
If there's code to move the files, surely there should also be code to change the media locations in the database so installing this module doesn't break media rich sites completely by simply installing it, without warning.
Is there an easy way to fix the broken media?
Comment #5
rob c commentedInstall D 7.18, Media 2.x, File Entity 2.x, Media Youtube 2.x. Add some videos. Then install Media Gallery 2.x.
All (remote) files loose their title, and while testing a bit with the new Media: Soundcloud 2.x branch i'm working on i see the file names used as a name for the file on the disk itself? That can't be right. For Media: Soundcloud 2.x that should be filesystem://media-soundcloud/type/id (.jpg for thumbnails) and for youtube: filesystem://youtube-id (dito jpg).
(and we also have a file we add on install in the Media: Soundcloud module, a default thumbnail. we use this file on rendering tracks without a thumbnail. i get 1 error about that file and not about anything else when i visit the new admin media page, and that file has not even been moved).
So darksnow depending on your situation, this might not even be possible. (hence the critical)
Youtube thumbnails are saved with their original disk file name, they are just copied, but also loose their filenames on Drupal. (is set to the youtube id string, and not the media title (name), as Media: Soundcloud 2.x does).
As a note: those thumbnails are part of the entity, while they also exist as separate files, they should not be touched by anything else then the providing wrapper i believe. Add a couple youtube videos and check the admin files thumbnails page to see how they are used. (without media browser plus)
Currently this will break your 'remote' media Bigtime. Files, thumbnails, filenames for files and thumbnails, even on the disk, links to content on the disk and remote, even file/mime types.
So i'm not really sure about this one / agree with das-peter in #3.
Sounds a bit critical to me to be honest, not able to use any other provider if installed. (and i just love the Media Brower Plus, hope this issue gets fixed soon). Reverting database + filesystem...
How about a small warning on the project page till this issue is fixed? (Save people some time) Thanks!
Comment #6
darksnowI started using media, from a migration, without setting up a proper media directory, so the move is actually welcome for me. It cleans up the root of my public files directory.
But moving all those files and not updating the paths and filenames in the database makes this module unusable from the start.
I really want to be able to tag media on upload for my site, which this module does beautifully, but I guess I'll need to wait for that feature to be added to media or wait for this bug to be fixed.
Comment #7
djmolny commentedI see the affected version is 7.x-2.x-dev. Before I try this module, can someone confirm that this problem does *not* exist in 7.1-beta3? Thanks much.
Comment #8
das-peter commentedI've just pushed a whole bunch of changes, enhancements and tests: http://drupalcode.org/project/media_browser_plus.git/commit/5e2db05
One important change is that there's no more silly media root folder by default.
If you already use mbp it should continue to work as expected.
Comment #9
philosurfer commentedis this issue closed then?
Comment #10
das-peter commentedNo more feedback on this, so I guess it's fixed :)