What are the core plans for a new image manager? I have one I wrote,
there is Sean’s and then the Gallery extension, but it seems like
there should be some sort of official plugin. None these (mine for
sure!) are really “ready for prime time” or all they all that they
could be. This seems to be something that people need, the list has
been flooded with questions in the last few weeks.
I’m currently quietly (and very very slowly) building
an asset management plugin hoping to encompass the
features in both my original asset manager and sean’s
manager. I’ve downloaded your extension and the gallery
extension, but have yet to look through those to figure
out if there’s any more features that are missing.
I’m hoping that I can come up with something that
provides a core that everybody is happy with that.
I’m not too worried about how it’s going to look
in the view (I’ll probably make it look the same
as my original extension), but if I can get the
core of it right, changing how the view works
can be up to debate and extensions.
Features that I’m planning are:
Loads and loads and loads of tests. I’m currently
developing in in TDD style. This is the main reason
why none of the other extensions can even be
considered at the time being.
Primary Storage is in the db as blobs:
For ease of backup and replication and making
sure we can scale horizontally. This was a
debated issue when we first started discussing
asset management, but I’m 100% convinced that
this is the right answer, mainly because all
the real arguments against are handled by:
Serving through secondary storage:
When pages are published or the assets of a
published page are modified, the assets can
be dumped either to the public dir, or
possibly exported to s3 or another external
location. The performance of radiant’s cache
is good enough that this isn’t needed in the
basic case, but for people who need a lot of
performance from the assets, it needs to be
there as an option.
It will work out of the box with no dependencies,
but some features might require dependencies.
My original extension allowed image manipulation
using fleximage templates (to resize, add shadows,
etc). I plan to have the same manipulations
performed in a similar way to the way that tags
are defined using a syntax similar to fleximage
and degrading based on whether imagescience,
rmagick or nothing is installed.
The work is going slowly. Very very slowly, as I just
haven’t had the time to dedicate to it, and because
the features that I’m putting in aren’t handled by
the usual suspects (attachment_fu and
acts_as_attachments) - I believe that CMS asset
management needs a bit more than what they provide.