Thread

Looks like the community has largely answered the questions.  And for those not familiar w/1.x’s gallery, it may be worth a look at the old gallery docs- part of the goal with these changes is to enable us to match the old gallery functionality.  So say you want to add captions to your images, or a better ‘title’ than just the file name, or group all of your vacation pictures in ‘Summer at the lake’ and your pictures of your dog swimming at the lake in ‘Summer at the lake’ and ‘Lucky the water dog’.  And then be able to show just your lake pictures on the frontend- or all the files uploaded by ‘Joe’, or the last 10 images in the ‘New Tech’ directory….

You get the idea.  That’s what we’re shooting for when all is said and done.

Oh- and Sean Delaney- while the XSS filter is always going to err on the side of false positives, this release did add back 2 hidden config values- xss_clean_member_group_exception and xss_clean_member_exception.  So you can leave xss filtering on- and override it for certain groups and/or members.  That’s my preference for dealing with it.  You may want your regular members to be run through the filter- who knows what they may upload as an avatar!  But your content folks, you trust not to do anything destructive- so exempt them via the hidden config.

Hope that helps!

ETA- and yes, there is a ‘sync’ ability now- it’s the only way to get the existing files in there!  That said, we want to a. add a batch upload a la the old gallery and b. give some sync ‘prompts’ if you do things like change a watermark or change/add a thumb size or such.

I have a particular interesting in seeing Gallery compatibility. I have several sites that use the galleries heavily (thousands of photos in multiple groups). This is all good news from our standpoint and we look forward to taking EE2.2 for a test drive.

Hehehe, the blog post should be more clearer because when you first read it sounds like they are moving the files to the DB (which is crazy), but it is just the metadata which is reasonable 😊

When we talk about metadata are we talking about complete metadata? For example something like what you see in Adobe Bridge?

I would like to see it to that degree being a photographer and what not. I can not speak for him though, maybe Rick will like it as well along with other photographers. ExpressionEngine has been seen as the “designers cms”, this might allow it to become the “photographers cms” as well.

I don’t know if the file manager will (or should) be able to display so much metadata in the core file manager but, maybe someone will come up with an add-on for those who want it.

With that said it would be cool if all the metadata was in the database so we can have access to it from the front-end.

This may need to be moved to a feature request.

Hehehe, the blog post should be more clearer because when you first read it sounds like they are moving the files to the DB (which is crazy), but it is just the metadata which is reasonable 😊

Yeah, the original blog post had me thinking that the actual files were going to be moved into the db:

A simple ‘Synchronization’ on the File Upload Preferences page allows you to have all files in that directory imported into the database, with the appropriate thumbnails added.  You’ll want to synchronize your files as soon as you’re done updating!

I’ve got gigs of files—hundreds of mp3’s, and thousands of images, not to mention upwards of a half terrabyte of stock vid footage clips coming online soon. That would have totaled out my MySQL install, surely. I had horror thoughts about the old days of BLOBs hosing db systems. Glad it’s just metadata! MAybe a quick edit adding a word or two would keep us old-school db techies from having a panic attack.

Man- my writing obviously lacks clarity!  And unfortunately I currently lack ‘edit’ privs in this forum, but I’ll see what I can do about clarifying that.

The actual metadata EE will story is pretty limited- file size, dimensions, name- some custom fields.  That said, the plan is for a hook to allow extensions to add metadata to the ‘metadata’ field- be it exif, IPTC, whatever.  (Lisa is dying for exif, when I freelanced, there was a request to store IPTC). 

I’m thinking store in a serialized array and bring back the data as {metadata:key} variables.  Keeps things very flexibile given that any file that’s allowed can be in there.

That’s very much in the planning stage so nothing is written in stone.  But a hook to grab metadata of that type and then store it is definitely on the todo list, and sooner rather than later.

Why can’t we browse uploaded images by thumbnail in the new file manger?
(or is that coming?)

Seems like a no-brainer to me, especially since the publish modal currently has a thumbnail view option?

Can I just ask why items get stored as serialized arrays?

I don’t know a lot about it but from a lot of posts I’ve been reading on the web this is not such a good thing to do as it makes searching through the data very difficult.

Would love to know if that’s wrong though as it would be great if we can get access to all the metadata and be able to search through it too.

Best wishes,

Mark

I know that Robin was just thinking out loud when she mentioned the serialised arrays, but I have to admit that I’m not keen on them either.

As a non-developer, I find serialised arrays to be an absolute pain to deal with (like when trying to interrogate data using SQL). For this reason, I was pleased when Matrix 2 moved away from storing its data in serialised arrays and into its own database table. Brandon said in his blog post:

Rather than jumbling all of your data into a giant serialized array and storing it in your exp_weblog_data table, Matrix 2 actually saves its data in a new exp_matrix_data table, which leads to better reliability and performance.

If file metadata is going to be stored in a table, then I think it’d be good if EXIF info (or any other useful metadata) was also able to be stored in the same consistent manner. I think this is where I add my “+1” for EXIF info to be stored with the other file metadata as standard, rather than via a third-party addon. 😊

For info, I’ve been using File Oracle to grab file info dynamically, and VZ Exif to get the Exif info dynamically.

Great work everyone! I for one applaud our new database driven overloads.

In all seriousness though storing metadata in the database is going to make it so much easier to iterate over collections of photos and pull back important details. For example adding width and height info to IMG tags under the old method was an absolute chore. You either hit the filesystem each time (yuck) or cached it in the filesystem (still yuck).

Although, I do want to agree with Mark up above that I’m a bit nervous hearing about the serialized array. A serialized array is awful to search on and is, in my opinion, only marginally better than hitting the filesystem each time. If I can’t run a query that says `SELECT * FROM files WHERE `Flash`=0` (to get photos taken without a flash) then I’m not sure you’re benefiting much. It’s a database, it’s supposed to have rows and columns, I wouldn’t worry too much about having 30 columns for exif data, pdf data, etc…

My 2¢… I’m no expert though so I’ll, of course, defer to you all. Just wanted to +1 Mark’s statement basically.

Just wanted to +1 Mark’s statement basically.

The Mark’s have spoken 😉

Would love to hear what the devs have to say about this though.

Nice to have you back in here Mark. It’s been a while.

Best wishes,

Mark

This may be moot given that we’re going to have metadata within the records, but I will be having multiple customers uploading probably hundreds of images. The upload directory will become a big, unwieldy mess unless there’s some way to create distinct directories for each customer, and I won’t want one customer having access to another customer’s images, so is there any word on how file/directory management will be integrated into this?

😉  The metadata/exif field/s serialized array?  Is still very much in the ‘back of our mind’ stage.  At a minimum, they’ll be a hook in there for folks who need more specialized handling of said data.

The directory/subdirectory issue is one that does need to be solidified asap.  It’s also one of the more complex decisions we’ll be making- and we’ll be doing so w/a good understanding of the various ways folks need to have it work.

Help! I cannot download the new BETA release?

Only these options are available in the download area:

ExpressionEngine 2.x Commercial License Update
Current Version: 2.1.3 - Build: 20110411
Download

ExpressionEngine Beta Documentation
Current Version: 2.1.5 - Build: 20110510 (Change Log)
Download

Any one have a suggestion?

I need this EE version ASAP. 😊

Kind regards,
Victor

Choose the Commercial license- at the bottom of the page where the ‘Accept license and download’ button is?  You’ll see some radios that allow you to pick which one:
Download 2.x   2.x Beta   1.x

Yell back if you’re still having trouble and we’ll get it squared away for you.