Symphony.

I know it's been mentioned, but is anyone working on/ interested in putting together an image browser extension? Something that behaves as a filebrowser like Ubu's WYmeditor would be great, or another route would be something that could browse entries in an images Section. Its at the top of my list of needed S2 features, but I'm really not the one to do it. Perhaps we could take up a collection to reimburse someone? If anyone would like to quote on it, let me know: ashooner -at - gmail - dot - com.

I might be persuaded to contribute to this collection... but let's clarify a bit more: How exactly would it need to function? Where would the interface live, what would it do, etc?

I also wonder whether it might be worth considering to integrate something 3rd-party, like Lussumo's Filebrowser (they're the ones behind this very forum software).

some startingpoints;my favourite, relay, a comparison from one of the best (but too extensive) and if you don't mind java: jumpoader

Minimally, I'm really just looking for something to replace the functionality that the WYMeditor CS had, which would be a plugin for a formatter that would provide file browsing and thumbnails, then output an img tag with the file url into the formatter textarea. Basically I need my designers to be able to browse thumbnails when they are adding content images, as they did in 1.7.

However, I do think it could be much more than that. A few questions for us to consider:

1. Should this be a true backend Symphony Extension, or a frontend template/module that could be implemented in a custom backend of the bauhouse variety. (I'm pretty ambivalent on this one. I'd eventually like to have some sort of common framework for creating custom backends, but would this be needlessly dividing our efforts? Sun Tzu would not approve.)

2. In either case, should it navigate through the filesystem or entries? In my mind, the only current reason not to store all my images in entries is the lack of the kind of interface we're considering.

My ideal would be a browser box at the entry editing/creation page. This would list your files, and each file could be selected. Selecting would display a thumbnail and possibly other metadata. The box would have an 'add' button, which would add the corresponding image at your cursor in whatever textarea you're editing. If it was an image, then the output would be an img tag, if another file type, just an a tag.

Lewis was describing his method, which records the output location by paragraph position into the image entry. This is pretty cool, but I bet it would be easier in this application to write the image placement reference into the destination content (e.g. a plain old img tag). If this were to use image entries, I can't think of a particular reason to store the image entry ID (which would mean a custom element to be processed) vs. just the URL of the image itself.

I've been thinking about this a fair bit recently, and while I haven't really come to any firm decisions, I was leaning towards building a image/media/file management system that you could integrate nearly into either the frontend or backend administration interfaces.

I don't think you need an overly complex system for keeping tracking of files — types, categories, dates, etc are probably enough — you just need a neat way of allowing people to embed that content in the site. I'm kind of just thinking out loud here, but I had envisaged a system that lets you upload whatever you want, and then lets you browse for files and generates markup for you based on the input.

So, if you've got an image, you could integrate it with Symphony's built-in image function and allow users to specify the parameters to resize/crop/align, you'd then generate an tag (or Markdown syntax etc) that they could paste into the content — you could certainly integrate it with TinyMCE pretty easily I imagine.

Thoughts?

Just had a look at Relay and it's sort of the first half of what I was talking about. I think all you'd need from there is a neat way of inserting that media into posts.

As far as the image resizing, that could simply be a matter of an xsl template that takes @height and @width from the img tag and converts it into the appropriate url to use the image function.

I think the shortest route is as you mentioned, just creating something that would work as a plug-in for TinyMCE, or some similar formatter. That way it could be front- or backend.

Programmatically speaking, though, I think there would be a considerable difference between browsing files and browsing records/entries in the Symphony DB. Both have their advantages.

While we're brainstorming, what about a function that could batch a folder, adding all files into entries. That would be great.

1) What about section relationships? Having a sort of parent > child relationship between sections like 'Articles' and 'Images' is often desirable. This image browser would, I imagine, need to work through those relationships (and thus, I suppose, be entry-based rather than filesystem based), so that you could a) create associated file entries directly, and/or b) browse either all files or only associated files, etc.

2) Another argument for having it be entry-based is that people will have varying needs when it comes to the kinds of data they need to capture with their files. A casual blogger, for instance, might only need a title and caption for her photos, while a photographer building a portfolio might need things like 'camera,' 'lens,' 'aperture,' etc. Allowing the site admin to model their file sections and then select which sections are open to this browser might be best.

3) Image resizing. I think there would need to be something more flexible than simply having XSL read the @height and @width, because you may need custom sizing in certain situations...

An entry-based browser is the long-term solution, and I think it's a good idea. So going that direction here are some more questions:

1. What is the output into the target/destination entry? Straight xhtml, or a custom element. The latter would mean needing a template to further transform the image for final output, but it would also give the system better access to image usage (e.g. if the custom element just held the entry-id of the image, then you could lookup usage of the image entry.) I kind of like the custom element idea, but I suppose <img> could be an option as well.

2. Browser interface location: symphony admin, or 'frontend'? I'm leaning towards frontend, but it would also be very nice to have access to it from a normal Symphony entry editing page. This leads me to the thought: what about an extension that would load arbitrary Pages or 'admin widgets' into the standard Symphony admin? If something like this was possible, then we could develop this thing as a frontend template, and be able to use it in either context.

3. Configuration: The idea of configurable instances of the browser depending on context/user is also a good long-term solution. How would this function exactly? We're really talking about several data operations:

Read: the actual browsing of existing records, possibly using related entries such as section relationships, etc.

Write (to image entry): Being able to add images or edit image entry field data.

Write (to destination): Placing the images by adding a reference of the image (by img tag or otherwise) into the target content field.

If this were to be done as a frontend template, then there would really not be much PHP involved, would there? It would be mostly JS for placing the reference into the target/destination field, and any browser fanciness, and plain old XSL for the rest of it. I guess to structure the data correctly it would need to be an extension, or would we want that to be done by the site admin?

Ok, so looking at TinyMCE's custom file browser documentation, it looks like it should be possible to incorporate a Symphony page as an image browser that could then send the url (or image entry ID) back to the content field. I'm going to play with this and report back...

http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/custom_elements

Any developments with the TinyMCE filebrowser?

I've kind of put my extension exploration on hold until RC1 and maybe some api documentation. I still definitely need it, but don't have anything right now.