@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.

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.

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!

I have modified KFM quite a bit – maybe telling you how I use it can give you some ideas for plugins.

Different users
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.

Caching
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.

Quota
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!
Mickster

If that doesn’t scratch your itch, then I’ll dig in and fix the original so that it works as it should.