KFM2 has begun. requesting ideas of sample plugins to develop
As ye all know now, KFM1.x is finished. I’m not interested in struggling with it anymore. I’ve started a new project which will exceed KFM1.x’s capabilities.
The main problem with 1.x was that it was monolithic – there was one single codebase, which encompassed both the server-side and the client-side. The client-side code was useless without the server-side, and the server-side code had hooks specifically designed to be used by the client-side.
The idea is this – if you want to do something incredibly simple, such as select an existing directory that will be used in your CMS to create an image gallery out-of (let’s say you need to choose from a number of existing directories full of images), then it is a total waste of bandwidth and CPU to load up a full-on file-manager.
In this case, and it’s the first I’ll be building to show how all this works, what should happen is that the browser will show something simple like this:
|Choose the image directory|
…and when that’s clicked, a small popup will appear which lets you choose the directory you want, in a tree-like manner – you open the branches until you find the one you want, then you click it. Afterwards, the form will change:
|Choose the image directory|| |
From the technical point of view, there’re a few things to explain about how this would be done.
jQuery would be used to attach an event to the button which would popup the selection window. This selection window will use Ajax to speak with the KFM2 server and retrieve the list of directories, one level at a time as the branches are expanded. When one is selected, a hidden input will be set to the name of the directory.
This sounds incredibly simple, and it is. What’s important, though, is that no-one is doing this at the moment!. Right now, if you go search for existing plugins to do this kind of thing, you’ll find either small widgets with both the server and client-side code ready for you, or full-on applications (such as KFM1.x) which can do the job, but which are overkill.
The problem with the applications is obvious – too much stuff going on, making it slow and cumbersome.
The problem with the small widgets is that each one is complete in itself, and therefore a lot of the functionality is repeated. This is a bad idea – what if you need to make a site-wide change? You’d need to go through every widget and change it!
What I’m proposing to make of KFM2 is that it will mostly be a server-side application, but which has a nice easy-to-use API which can be hooked into by lots of different jQuery widgets (or Mootools, or whatever you want, really – write it in Python or Delphi if you want…).
So, my first widget will be the one described above – a directory selector.
I’d like to know what other things people need to do with files online, which are simple and they’d prefer not to have to load a whole file-manager to do.
I’ll release the first widget and a demo of it some time over the next week. I intend to write a whole load of widgets, culminating in a full-on GUI similar to the present KFM1.x one, all hooking into the new engine.
I think that you should try and give as much control to the programer using KFM as you can. Make everything simple but powerfull! There are a hell of a lot of API’s out there that are very very complicated. It should be easy to do something quick, but also have the ability to do more complicated stuff if you need to.
One thing that would be cool would be to have a few different connection methods. These methods would not really be plugins but rather be built into the core. If you do it like that then the user could connect through FTP and also use all the plugins as normal. That way you could easily get a directory listing from anywhere!
Also you could have a multiple file uploader, or even better a zipped file uploader that has the option of unzipping the file into the upload directory. I don’t know if that’s possible in PHP though…
In the future you could look into more advanced plugins that replicate some of the features of Google Docs. A file editor that could save in the Open Office or Microsoft Office formats.
Also the ability to have default connection methods and all in a settings file, and also to make once of connections would be usefull.
Just throwing ideas at you here, I hope some of them are usefull!
most of those (including the zipped uploader 😉 ) are available in KFM 1.x already.
But yes, the goal here is to give ultimate control to the programmer. I aim to have as little PHP as possible, so most of the control is on the client-side, and the server-side is basically for verifying that the request is legitimate, and then carrying out the request.
You’ll be surprised at how /small/ the server-side is. I’ll release the first plugin in the next few days, and most of the code is on the client-side.
what do you mean by “once-off connections” ?
the networking part of it is interesting to me. I intend to make some plugins allowing a number of different file-storage systems available through KFM
I know this is the wrong area for this but comments for your multi-select are closed and I could use a little help. I have the script and html all working great, thanks to your code, but my select options sometimes, and correctly, contain an ampersand since my data comes from a database table. When rendered I get the escaped “&” sequence in its place but I need the text to display as is in my database table. I’ve tinkered with the script code but can’t come up with a way to not escape this character. Any ideas?
Hi Scott, it’s been /ages/ since I worked with that code. I’d recommend you look at a more uptodate one, such as bjorsq’s (Peter Edwards’) “inline multi-select”, which I’ve been using myself for some recent projects: http://code.google.com/p/inlinemultiselect/wiki/Introduction
If that doesn’t scratch your itch, then I’ll dig in and fix the original so that it works as it should.
I just took a look at it and have to say that I believe your original was much cooler. There wasn’t any reason to turn this into rocket science. Yours was simple. Your code was 5k. All of the jquery stuff is 64k. Not that 64k is huge, but you get the idea. Do you have any simple code samples of the inline multiselect? I just don’t have to time to mess with trying to copy the examples from the google site. You can’t just download a zip file.
Thanks again and again sorry for the posting in this area.
Scott, it’s grand. what I’ll do is I’ll write a new script which is just the multi-select code. Are you ok with jQuery? I’d prefer to write this as a jQuery plugin. it would most likely end up much smaller than the original script.
I have modified KFM quite a bit – maybe telling you how I use it can give you some ideas for plugins.
I have different users using the same installation of KFM. To accomplish that, I just assign a different base folder for each user.
In addition I have modified the database so that every file uploaded also gets a user id saved in the table. I know(/think) that you double check database versus folder content so that’s not really needed even when you have multiple users, but this enabled me to do my own flavors of the GUI. For example, I have an image selector, which only pulls the image files (from the database) that belong to user X.
That’s probably a good idea for a plugin – an image selector, showing only images (types maybe configurable) from user X.
Paired with the image selector I have a file tree – for which I use a modified version of this plugin: http://abeautifulsite.net/notebook_files/58/demo/
With modified I mean that instead of checking the file system, it checks the KFM database for different folders and their files (I’m only using the plugin to display the folders, the images are then shown as thumbs (altough received in the same AJAX-call, as JSON)).
It also doesn’t make an AJAX call every time I click on a new folder, but first checks if we already got it (then show that content and hide everything else).
A file tree is also good for a plugin and from your blog post I take it that’s what you are going to start with. Maybe it’s wise to configure it so that the user can decide for himself what to use, everything or just folders, or thumbnails, or…
Maybe that can be achieved by sending the file and folder data back as JSON, like json[‘folders’]=all folders json[‘folder_content’]=the files in the folder or something like that. Then the user can just configure the callback and do whatever i want with the data.
I load all my files through a script, so that I can serve up different sizes of an image if needed. I.e i save the original image but most of the times I make a cached copy of it in different sizes (I do this upon loading the image the first time, outside of KFM).
When I delete an image in KFM, KFM checks the cache folder if there are any cached versions of that file. If there is – all cached sizes are deleted (one part of the filename is a md5 of the path- and filename and the second part of the filename describes the item’s size. This enables me to identify and delete all cached copies of an image).
Not sure how this would make a plugin, but a plugin or options for resizing images are always good. Maybe the user can configure if all images should be processed(resized) when uploaded.
The way you’re planning to get the images through a script probably means you can implement all of the caching too quite easily, if desired.
Before uploading a file I check if the user’s quota is full and if it is I display a message instead of a browse-button. What also would be good is to have a quota check also between files in a multi-upload. As of now, my users can circumvent my quota-check by just uploading many files at once.
Hmm I think that’s it… Not very structured, but hopefully it gives you a good idea of how other people use your system!
Let me know if you have any questions!
Best regards and keep up the good work!
wow, that’s quite a lot, mickster! good stuff.
I think my next post will re-iterate the identified plugins, and I’ll probably be able to give a time-line for their creation.
I’ve also got email from the guys behind Foliopress, who’ve use a modified version of KFM in their product since it was begun. They have some ideas for plugins as well, which I’ll explain in the post.
As these articles expand over the next few months, I hope to address all the needs of every KFM user. KFM1 had a very specific target (FCKeditor), and yet was flexible enough to be used for other things. KFM2 does not have a specific target, and should be even easier to use for other things.
Alec has said that the Foliopress team is interested in keeping up a conversation through these articles, so we should be able to get a lot done in the next few months.
I hope that the first demo will show how easy it is to /start/ creating for this. Some things will not be immediately possible, but we’ll address those as we come to them. My intention with the whole plugin nature of this is that programmers such as yourselves will see how easy it is, and will be able to jump right in and write your own plugins!
We are definitely excited by the modular nature of KFM2, but we’d like to see a useable core which doesn’t require too much dressing up. I share Scott’s interest in a tight codebase. Still, we are using Jquery in all our projects and hate loading a separate library so we are glad you’ve chosen this one.
The original KFM was a gem and we are looking forward to helping you rebuild the best image manager in the world.
PS. You won’t be able to address all the needs of every KFM user. We like you to focus on the core functionality and get the product out the door quickly. We wrote a lot of image insertion routines that we needed on top of your core code. Lighten your load and let the community code bells and whistles. It would be great to have a shared space where we could keep track of the external KFM code out there.
One caveat. Security is a big issue and we’d like to see you keep a tight handle on that yourself to discourage unsafe routines and not to force users to use unsafe server settings just to make KFM run.
3 requests :
– It will be great if we can choose to run KFM with a database or not : in the case where no database is selected, you have only basic features (no search,…).
– Have the possibility to manage multiple websites with the same KFM instance (each website has his own filetree but same DB tables behind).
– More professionnal look, for instance JQuery UI aspects.
Many thanks for your work.
Thanks for a great Image Manager/Editor.
I like your idea of folder select for upload.
I would like to have an extension which uploads multiple files or folder with option to resize on upload (for multiple files), and second option to create versions at 1 or 2 other sizes. This extension would be useful for creating image galleries and product images.
@mick – this request already exists in KFM1 (images can be kept to a certain maximum size, and when requesting the image through get.php, you can specify what size you want the image returned). but I will see if I can come up with an easy way to do it for KFM2. will be working on it this weekend.
@frederic – KFM2 will by default not use a database. it’s a common request, and a database is only /really/ needed when searching for something or when thumbnails need to be related to each other. the “look” of it, I would not be good at fixing, but the plugin nature of the system will allow you to work on the design yourself. as for multiple sites using the same instance – that’s already possible with KFM1 by specifying separate userdirs for each site and keeping the databases separate, but I’ll see if it can be simplified further.