Since you guys are doing all this work on the File Manager, this might be a good time to voice a couple requests I have.
It would be nice if $.ee_filebrowser.add_trigger accepted an optional 4th parameter, a settings object, where we could easily tell the File Manager which file directory it should be limited to, and whether it should allow all file types, or just images.
Currently in EE, Filemanager._upload_file() determines which file types should be allowed by actually unserializing the field settings and looking at the field_content_type value. But for something like Matrix, where a single field could have multiple file columns, the whole field can’t have any single content type set. So the Content Type setting in Matrix’s File celltype has never been able to be enforced – it simply determines whether the button says “Add File” or “Add Image”.
In EE 2.2, you added the Upload Directory setting to File fields, but it’s up to the File fieldtype to actually hide the File Directory dropdown, and reload the File Manager iframe with “&dir;_override=” set in its src= attribute. While it’s not difficult for me to just duplicate all that code (as I already have locally), wouldn’t it be a lot simpler for the File Manager JS to do all that itself, simply based on whether settings.directory is set to a number or not?
Here’s kindof what I’m picturing for ee_filebrowser.js:
$.ee_filebrowser.add_trigger = function(el, field_name, settings, callback) {
if (! callback) {
if ($.isFunction(field_name)) {
callback = field_name;
field_name = 'userfile';
settings = { content_type: 'any', directory: 'all' };
}
else if ($.isFunction(settings)) {
callback = settings;
settings = { content_type: 'any', directory: 'all' };
}
}
...
};
(Obviously it would be more involved than that – you’d have to actually enforce the settings, but you get the idea…)
Ok. Well, I’ve said this on at least a couple occasions, but I’ll say it again: If you guys want to get serious about this add-on developer program, you really need to get in the habit of sending out release candidates at least one week in advance of the actual release. Especially for a big release like this that requires us to update our code, it’s pretty nerve-racking to not have an updated RC and be told that you’re planning on releasing it in 6 days.
It’s supposed to work in your favor too – if you give yourselves a full week to QA the release after you think it’s all good to go, you’ll have a chance to find and squash a few more bugs, and have the confidence that you’re releasing something stable.
Greg posted that we released a new version this past Tuesday (the 14th) in this forum. Here’s the post. If we have to push the release back and there’s enough changes to warrant another dev build, we’ll send out another.
Wes
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.