Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Add Non-Gallery Handlers for Media Module #121

cliftonc opened this Issue · 12 comments

4 participants


The first actual working release of the media module is focused on photo gallery management (which may actually be better refactored later into a gallery module!). This is because my wife was pestering me to build her a good site (not facebook or google+) to privately host our photos.

An example is up here:

So, we need to add:

  • Generic (e.g. non-gallery) media forms and screens.
  • Hooks into content forms to enable drag / drop adding of images to content when editing it.
  • Selection windows for media to insert into content.
  • Security (this is more general really)

.... anything else on future roadmap.



nice job!


2 years later...

The site is down

and i can't find image handling in actual calipso code. Additionnaly, a note in roadmap for such feature request.

Have any of you guys any help or started work for me in order to achieve an Image(s) module ?

I already have some sniplets for storing binary in mongo, and to handle HTTP native file transfert with express.


Ok I see the point for s3 and the problem for handling streaming, it's ok.

Of course, my use case is about small contents like images and decorations.

The user/client don't want an additional service and just use aloha, drops it's image from file explorer in an aloha-editable and then it shows, with tooling. In the background, it's (can be resized and) uploaded to the server and stored in db, maybe (automatically) declined in several resolutions (optimized for several uses : thumbnail, preview, full-screen, full-size).

I know how to do all that, it's implemented in some of my projects.
As i'm discovering calipso, and i find it interresting, i'd like to add this feature here, but i guess i need a "Field" module dedicated to Image(s) (just like in drupal) to handle specific content type and link it as a multi-valued property of a Node.

For optimisation purpose, mongodb file content could be duplicated in a file/memory cache or in a frontend reverse proxy.
We talked about the opportunity offered by mongo to handle big content (over 1G documents) in an earlier discussion with @draftkraft , I think a mongo content store can work, it's just a client's choice (subscribe s3 or other cdn or prefer to keep control). Implementation has to provide both.


had a look on s3 plugin...

Thought : have a multi-valued property-tuple type "Attachments" with an attachment-type (asset/native), and other fields depending of attachment type (For example : file-name, file-data and content-type for native, file-store, file-url and content-type for asset)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.