time to replace FCKEditor file browser?

Just discovered: http://extplorer.sourceforge.net/

Pretty interesting! Though the only problem with it is that it is fairly self-contained and would be difficult to integrate it properly with MODx.

We’re looking at using a combo of Mootools and Ext to do the job. Looks like someone is almost done with a great file tree widget for Ext (http://ajaxian.com/archives/ext-file-tree-widget). And since Mootools and Ext are already bundled into MODx, all we have to do is write a solid file browser using something like the new file tree widget and we’ll have it made. The great thing about this approach is that since most of the javascript libraries will be cached when the manager is loaded the total footprint will be much much lower when the file browser is called. This is pretty much the primary reason why I’m against using anything that doesn’t utilize the libraries we’ve chosen to use in MODx. Not only that but we have alot of ideas for adding user-based security and folder features. This is so much easier to do when writing from scratch. As much as I’d like to just hack an existing app and call it a day...I just haven’t found anything that fits the bill just yet. However, with the file tree widget shows a ton of promise so we’re getting very close to a solution here.

Jeff

The developer of eXtplorer started with the older Xplorer program and turned it into a Joomla component (he also is the creator of Virtuemart [a Joomla fork of phpShop]). It’s nice to see him working on making his addons accessible for other CMS’.

Yeah, it’s really not bad. And it does look like it was built with Ext. It’s just...hmm...

I think the thing I’m not sure about is how it would integrate into the flow of what we’re aiming to do with MODx. I really would like to see a way of having permission sets for different shares. That way you could have dedicated user folders for different web users and manager users and, if needed, allow for manager users to access specific global shares as well. Extplorer seems to be more geared as a sort of Explorer-like way of managing files and directories on a server without the need of using an FTP client...which is great if that’s the sort of thing you really need. But not so great when you need to be concerned with security and what users can and can’t do on a server.

I would still rather do it from scratch simply because I’m also thinking we need some API features to allow for writing plugins and such.

Jeff

I feel you. I believe Xplorer originally had the ability to let different users have different folders/permissions (is that what you were saying). Either way, the work you guys have done and ARE doing is just awesome.

Well...when it comes to user permissions, the way I envision it is that you would have a permission set that applies to a whole share for any given user. For example, let’s say we want certain users to be able to use the default assets directory as well as having their own assets directory. When a user calls the file browser it would default to their own share or the default depending on what shares exist for that user. A drop-down box or the like would give them the ability to switch the view to a different share. Now, a user could have access to a bunch of different shares depending on how it’s setup. The idea would be that a user could be assigned read-only access to the default global assets directory but have full access to their own share to upload stuff. Other shares could be created to facilitate things like photo galleries and the like.

But I don’t want to implement it with any sort of mucking around with file and folder permissions. That’s just asking for trouble when it comes to your novice users. I figure that either a user has full access, read-only access, or no access at all to any given share. And the chances of a user needing to move files between shares are pretty much slim to none. The whole share concept is driven with the idea that users organize their files based on the task at hand.

That’s kind of how I’m envisioning it for now.

Jeff

Quote from: Bravado at Jul 13, 2007, 01:48 PM

But I don’t want to implement it with any sort of mucking around with file and folder permissions.

I agree this sounds like a good approach, but how are you going to secure those resources from the web server if you do not "muck" around with file and folder permissions in some way?

Well...by default, most folders won’t allow you to browse to them directly anyways so there really isn’t any risk of anyone bypassing the server’s security of the files and directories. Now, as far as securing shares and directories that exist within MODx itself, I’m thinking that a table could be used to simply keep track of all existing shares. That way we can eliminate the possibility of script injection. If a given user doesn’t have access or if it’s a directory on the server that isn’t a subdirectory under an existing share, simply put, the user won’t be able to access it. The security will be a part of MODx and thus will be locked down based on the user’s authentication in MODx and will only work for an authenticated manager or web user. I figure this makes the most sense since we really wanna allow for the most flexibility when setting up new or existing users.

Jeff