This project is read-only.

Ideas for a new Orchard media management

Topics: Core, General
Jun 14, 2012 at 4:17 PM
Edited Jul 29, 2012 at 5:53 PM

The following contains ideas that emerged on and from a Onestop brainstorming session about media management:

  • Today: file management (!= general media management); file management would stay
  • Media content types with “Media” stereotype; general Media type as a fallback if no appropriate type is present
  • Media Picker: popup to select media editors
    • Content items of available media types can be created
    • Upload functionality is re-usable but optional (e. g. Youtube Video type wouldn’t need anything uploaded, just a video URL), has events so IEventHandlers can tap into the file processing pipeline
    • Stand-alone media editor (could be used in a popup, but also normally in a page), no TinyMCE coupling
  • MediaPart for media content types: filepath (if any; indexed in DB)
  • Somehow (unchangeably) store supported file extensions (if any) along with the media content type, possibly set when the migrations run
  • TinyMCE (or generally: WYSIWYG editor) integration:
    • Media token: a token that corresponds to a specific media item, containing its id (using the same method e.g. Request.* tokens employ), e.g.: {Media.Display.45}. -> Issue: what happens if id changes (e.g. with export/import)? Maybe should use some other identifier instead?
    • Adapter for editor integration: after saving the media item, its token is inserted into the editor at the location of the cursor. (Expose events as jQuery events?)
    • When the body text is tokenized, the media tokens are replaced by the media items’ display output (e.g. the Image type’s display shape would contain an <img> tag). -> Issue: if all embedded media items are generated by display shapes, would this cause a noticeable performance impact?
    • Inserted tokens are parsed out on the client-side. If the set of inserted tokens changes (e.g. new media item is uploaded and inserted), through an AJAX call the list of the processed values are fetched. The tokens are replaced by their corresponding values (display html output) when displaying the text for the user. This means: the body text contains tokens and is saved with tokens, but in the HTML the user sees when editing the text, not the placeholder tokens, but the processed media displays are shown.
  • Media items can have summary and detail modes just as any content item (e.g. the a bigger image is displayed in “Detail” mode, but a thumbnail in “Summary”).
  • File management (current media management): stays as it is, but when opening a file the editor of the media item (fetched based on the file path) corresponding to it comes up. When a file is new (= no media item created yet), the editor of the most appropriate (based on file extension) media type comes up.
  • Automatic summary image for content items where a media item is inserted into the body (separate module, extensibility idea): parse out first image token from body, display it in summary mode along the beginning of the body.
  • Media types, being independent content types, can be developed in parallel
  • Ideas from Media Garden module (by Pete Hurst, missing)?
  • Media items are accessible through two ways:
    • Like regular content items (this is the only option for media items that don’t need a local file; e.g. Youtube videos don’t need one)
    • When opening their corresponding file from the file browser (current media browser)
  • Not every file is a media: when opening a file from the file browser the user is asked if she/he wants to create a corresponding media item. By default the following information is displayed:
    • Public url of the file
    • View/download file link
    • File size

Maybe these can be in the same part that’s used with media items that store a local file, but here only a non-persisted general media item is created, only for displaying the above information (i.e. what displays file information is a dynamically created content item, that uses the same part for file management that persisted media items use).

  • If a media item has a local file attached, the file can be swapped out with another one from the item editor
  • Weekness: since media items that need a local file are attached to one in a 1:1 relationship, problems can arise if files are moved, renamed or deleted. This can be partially overcome by generating a hash from the files’ contents:
    • In my experience the majority of media files used in an Orchard site can be categorized into two types, without overlapping:
      • Files whose content change
      • Files whose path (including the file name part) changes

      Former ones are most likely managed by some program code (i.e. a code writes to that file, not the user directly) and their location is unlikely to change.

      Latter ones are managed by users (typically images, documents) and are possibly moved around or renamed.

    • When creating the corresponding media item the contents of a file can be hashed and this hash stored in the media item together with the file’s path. So when opening a file from the file browser its corresponding media item is searched by
      • file path
      • or if not found, file hash.
    • If a file is modified and moved simultaneously it still gets lost with the technique outlined above (this could arise if e.g. Orchard is used as a document management system). This can be partially mitigated if media items are periodically iterated over and their corresponding files re-hashed.
    • This only makes it possible to find the corresponding media item of a file, but not vice versa (since searching files in the file system by hash would be difficult).
  • When removing a media item, ask the user if she/he wants the corresponding file (files) to be deleted? Maybe this is unnecessary, since media items wouldn’t be actually deleted (as content items aren’t), therefore can be revived; if this happens, corresponding files should be present too.
  • SummaryAdmin shapes for media items (e.g. thumbnail images)?
  • Hidden media folder (like RecipeJournal) for modules to store media files that shouldn’t be directly accessible from the file browser (e.g. generated thumbnail images)?

Any feedback is welcome!

I've threw together a wireframe about the outlined enhanced Media Picker. You can import the following xml into the Balsamiq web tool and make it better.


<mockup version="1.0" skin="sketch" measuredW="1108" measuredH="627" mockupW="700" mockupH="421">
    <control controlID="216" controlTypeID="com.balsamiq.mockups::TitleWindow" x="490" y="206" w="450" h="421" measuredW="450" measuredH="400" zOrder="0" locked="false" isInGroup="-1">
    <control controlID="217" controlTypeID="com.balsamiq.mockups::List" x="505" y="252" w="100" h="315" measuredW="100" measuredH="126" zOrder="1" locked="false" isInGroup="-1">
    <control controlID="218" controlTypeID="com.balsamiq.mockups::FieldSet" x="631" y="252" w="294" h="248" measuredW="200" measuredH="170" zOrder="2" locked="false" isInGroup="-1">
    <control controlID="219" controlTypeID="com.balsamiq.mockups::TextInput" x="631" y="522" w="203" h="-1" measuredW="74" measuredH="27" zOrder="3" locked="false" isInGroup="-1">
    <control controlID="220" controlTypeID="com.balsamiq.mockups::Button" x="858" y="522" w="67" h="27" measuredW="67" measuredH="27" zOrder="4" locked="false" isInGroup="-1">
    <control controlID="221" controlTypeID="com.balsamiq.mockups::Button" x="739" y="564" w="-1" h="-1" measuredW="54" measuredH="27" zOrder="5" locked="false" isInGroup="-1">
    <control controlID="223" controlTypeID="com.balsamiq.mockups::StickyNote" x="697" y="312" w="-1" h="-1" measuredW="109" measuredH="123" zOrder="6" locked="false" isInGroup="-1">
    <control controlID="224" controlTypeID="com.balsamiq.mockups::CallOut" x="408" y="385" w="160" h="32" measuredW="160" measuredH="39" zOrder="7" locked="false" isInGroup="-1">
    <control controlID="225" controlTypeID="com.balsamiq.mockups::CallOut" x="806" y="273" w="-1" h="-1" measuredW="183" measuredH="39" zOrder="8" locked="false" isInGroup="-1">
    <control controlID="226" controlTypeID="com.balsamiq.mockups::CallOut" x="952" y="515" w="-1" h="-1" measuredW="156" measuredH="40" zOrder="9" locked="false" isInGroup="-1">
    <control controlID="227" controlTypeID="com.balsamiq.mockups::CallOut" x="818" y="582" w="-1" h="-1" measuredW="171" measuredH="40" zOrder="10" locked="false" isInGroup="-1">


Jun 14, 2012 at 6:16 PM

A few comments:

* media token in TinyMCE is something we've wanted for a while. This also applies potentially to other tokens, such as links to other content items (especially now that we have an awesome content item picker). So we should have a generic extensible mechanism for tokens in TinyMCE.

* The problem of identifiers that you mention has been solved in import/export. Re-use.

* TinyMCE should remain wysiwyg, so the image, not the token should be visible in the editor, as you seem to be saying. data-* attributes can help store the additional data that you need to map back and forth between the tag and the token.

* I would make the distinction between the file and associated item as invisible as possible. I would try to do the right thing without prompting the user.

* Hash idea is interesting but potentially very expensive: if you have thousands of big images and videos, finding a file by hash is going to cost you. It's an interesting direction but in need of a better idea for identifying a file fast that is not the path. Maybe there is something already in the Windows file system API that does something similar?

* Deleting a media item and the associated file should be the same, in the spirit of making the association implicit and almost invisible. I understand the concern about reversibility but I would in this case remove the media because file size concerns are valid for files that can weight dozens or hundreds of megabytes. Just make it clear in the confirm dialog.

* You haven't mentioned versioning. It sounds like a valid scenario for media too, but one that we don't support today.

* +1 on hidden folders for thumbnails.

Jun 14, 2012 at 6:55 PM
  • I think tokens in WYSIWYG editor should be what I tried to explain: somehow inject token-replacement into the editor where it displays the html output. So in the background only tokens are present in the content of the body (and therefore saved), but the html the user sees contains the replaced values. I don't know whether this is possible in a straightforward way...
  • By searching by file hash I've only meant searching the corresponding media item for a file. That means, if there seems to be no media item for a file based on its file path (path is stored in the item), also make a search by using the hash (since it's also stored in the item). That way if the file's path has changed, but it content hasn't, the corresponding media item could still be found.
    By "This only makes it possible to find the corresponding media item of a file, but not vice versa (since searching files in the file system by hash would be difficult)." I've meant the other direction, finding a lost file for a media item. Maybe the most simple way to deal with such a scenario would be to simply prompt the user that the media item's file has gone missing and let him optionally select one.
    This means, all files are hashed only when (if) creating their media item and when they're opened but no media item can be found based on their path. I've mentioned that probably every file could be re-hashed once in a while to deal with the situation when a file is modified from its initial state and also moved.
  • Do you also mean file versioning by media versioning?
Jun 15, 2012 at 8:00 AM

Thanks for the clarifications. Yes, I mean versioning of both file and item.

Jun 16, 2012 at 12:22 PM

How do you envision handling a media hierarchy? Or will all the media just end up in one folder?

Do you see a feature where you rename a file, and have a check box that will go and update the necessary fields with the new url?

Jun 16, 2012 at 8:48 PM
Edited Jun 16, 2012 at 8:50 PM

I would keep existing file management and extend it with media management capabilities. That means files can have a hierarchy as in the file system while media items (these can correspond to a file, but this is not necessary) can have a hierarchy as it is possible with content items. I think not every file should be (have) a media item (e.g. for files uploaded just for simple downloading) and not all media items necessarily have corresponding files (e.g. inserted Youtube videos).

So, in my opinion basically the current file management could be extended with media management capabilities. Another approach would be to handle media files totally separated (e.g. in the mentioned hidden folder) from other user-manageable files, what would solve the complexity of maintaining the association of media content items with their corresponding files (and possibly also make file versioning implementable in a straightforward way). However this would leave the user with a single choice of uploading media files (through creating a new media item and uploading a file from its editor) while currently heavy payloads can be uploaded through FTP or other file transfer channels to the media folder.

About Jetski's question: I think if we consequently use only tokens everywhere instead of referencing files directly this shouldn't be an issue.

Jun 17, 2012 at 9:57 PM

Hey chaps, I really like this!

Jun 17, 2012 at 10:09 PM
Jetski5822 wrote:

Hey chaps, I really like this!

Me too, it would be really great to have.

Jun 21, 2012 at 5:42 AM

Make the media picker extensible, ship that thing as an extension of the standard media picker.

Jul 29, 2012 at 5:54 PM

Just opened an issue about Media Picker extensibility.