In my opinion, this is a very good solution for file upload and image management in drupal.

http://www.zhuo.org/htmlarea/docs/index.html

I have seen this converted to a WordPress plugin, and it does not require users to use HtmlArea. Because all you need is a link to pop-up the ImageManager dialog box, and you can start working at it.

Anyway, has it been decided which file upload module will make it into 4.5 ?

Comments

harald.walker’s picture

I was about to post the same.

Via Matt's article Wiki vs CMS … we have a winner! I came across ImageManager. Really looks nice.

What I could also use it a better support for multimedia files (movies,...). With the support of getId3 one could probably create a nice plug-in. Well... I know I shouldn't just be asking for things, so maybe I will start working on it myself once 4.5 is out.

Bèr Kessels’s picture

Personally i am against all these embedded solutions. I never install any of these on any of my clients sites.

The reason being simple: HTML and javascript will never (ever) get to the point a full blown office suit will. And even in the rare case that it would, a CMS is not meant for all this.

I wrote a lengthy article on why I beleive these plugins are not a good thing: http://bler.webschuur.com/node/view/145

[Ber | Drupal Services webschuur.com]

chrisada’s picture

Have you even read my post before hitting reply?

This is in no way graphical text editor or whatever you think it might be. An embedded solution, HtmlArea might be, but we were not talking about that. It doesn't do anything with layouts, as your blog entry suggested. It just insert img tags with some attrubutes. ImageManager doesn't require HtmlArea, it was just suggesting that might be one of the good places to access it from.

Bèr Kessels’s picture

And I also investigated that ImageEditor. " The Image Manager and the Image Editor are plug-ins for HTMLArea." it says clearly on their site, hence my remark in myblog that its an HTMLarea plugin!
And yes, I did read what you said about wordpress plugin.
I am not saying you should not work on it, I am merely telling, in a general story why WYSYWIG and CMS IMHO should not be integrated! that is all.

[Ber | Drupal Services webschuur.com]

jsloan’s picture

A qoute from your website post:
...tools that replace the standard text-area in a CMS.

When did the HTML test-area become the standard in a CMS? I think that you're concept of a CMS if much too broad and that imposes a lot of your correct CMS ideals on areas that outside the realm of the CMS. You state in your post on your website that...

Managing the content is the bottomline. Whether content is an image, an MP3, a piece of text, or anything else, does not really matter it is...

But then you impose your concept of a "CMS limit" on how I should add a <tag> or insert and resize an image in the body of a node. What is the difference between you using the text-area and HTML markup or using a javascript WYSIWYG? I agree that an image can be content and that it can be managed by the CMS, but I also believe that sometimes an image is just an image and it belongs in-line in the body of the node via the <image> tag. Even if I go through the exercise of doing the image manipulation using the gimp and then submitting it to the CMS as a node - I still have to position it in the correct position in the body of the node.

You came close to recognizing that there is a difference between a CMS and the CLS(content layout system) but then you retreat from the purpose of each and suggest that they are mutually exclusive. Do you not think that there is a CMS behind the BBC CLS? They are both tools. To make available a CLS tool in the form of a non-core module for Drupal does not compromise the CMS integrity at all.

Since we are way off topic now I will end this and pick up the discussion on your site where it would be more appropriate. This is the "Core Development" section and I think we are all in error by belaboring the point here - it should be moved to the Module Development section.

jim

Bèr Kessels’s picture

good idea to move the discussion over there.
I took the liberty to add your article as first comment, and replied to it.

[Ber | Drupal Services webschuur.com]

jsloan’s picture

I manage our Inranet and during the last few months I've been moving our departmental web sites to Drupal. The last hurdle was image management. The image.module is good for building photo galleries - but not for simple "images in the body" of a node. The node_image.module was a step in the right direction. I came upon this forum topic yesterday and have since been testing the ImageManager on 4.4.2 and CVS on both Win2K and Linux using GD and Imagemagic... it works great!

Our trainer is evaluating it today and I hope to be rolling this out to our webmasters soon. The big hit for us is the ability to resize and crop.

I do hope that this finds a comfortable place in the Drupal modules, even if it is only a HTMLarea plugin.

chrisada’s picture

...have since been testing the ImageManager on 4.4.2 and CVS on both Win2K and Linux using GD and Imagemagic...

How exactly? Did you roll it into a module? Could this be shared after the project is completed? :)

jsloan’s picture

Download the "PHP Image Manager + Editor" demo from SourceForge htmlarea_wei_01_04_2004.zip

From the demo I copied the plugin directory named ImageManager into the Drupal /misc/HTMLArea/plugins/ directory. Edit the config.inc.php file (lines 18 & 28) to point to your image directory. Also edit line 49 to choose the GD or ImageMagick.

Go to the Drupal "settings" page for HTMLarea and select "ImageManager" on the plugin list, then add the "insertimage" item to the toolbar.

That should do it! Things to-do would be the integration of the "config" files and option selection from within Drupal admin pages.

gordon’s picture

Remember one thing with implementing solutions like this. It means that you are forcing all users to user htmlarea. There is no way for users to add images if they are not using htmlarea.

Not all users use IE or Mozilla. People who are using Safari, Konq. and even some browsers that are derived from mozilla do not support htmlarea. If you impose the use of modules like Image Manager, how are people who don't user htmlarea going to publish content.

I have created htmlarea plugins such as the upload image and upload document which hook into drupal and still allow users to publish content.

HTMLArea is a great tool, this why I have created the drupal interface that is easy for anyone to implement HTMLArea into a drupal site. But you do have to remember accessiblity and HTMLArea can take that away from your users if you are not careful.

I actually looked at Image Manager quite a while ago before as a possible base for the upload image plugin, but their was going to be alot of work to interface it with drupal.

Don't get me wrong I do encourage the use of plugins to extend the uses of htmlarea within drupal. I have created a complete infrustructure to allow for the configuration of plugins. Take a look at the CSS plugin which is quite a complex plugin to use, but I have created a configuration page that anyone can use to configure it. If you want to create a configuration page for just look at the CSS plugin which uses the htmlarea_plugin() hook which will allow you add configuration pages and custom execution.

If I was going to use Image Manager with drupal and htmlarea I would fork the Image Manager code and the modify the backend so that it did things the drupal way, and have a seemless intergration.

--
Gordon Heydon

jsloan’s picture

Remember one thing with implementing solutions like this. It means that you are forcing all users to user htmlarea. There is no way for users to add images if they are not using htmlarea.

... not at all ! I can still use the image module or the node_image module to get images up to my site.(or anyother module that is created in the future) No one is prevented from using any of the existing modules to upload images. In my installations I point the ImageManger default directory to the same directory that the image module uses. That way I can use any image within the HTMLarea.

By keeping the ImageManger as a plugin for HTMLarea there is no need to fork it; We should keep the Drupal framework open enough to be able to use other open source projects where appropriate - we should not fork them - we should invite the authors to join in.

Now back to the original point of chrisada that there is an opportunity here it to incorporate it as a helper for a standalone module .

gordon’s picture

... not at all ! I can still use the image module or the node_image module to get images up to my site.(or anyother module that is created in the future) No one is prevented from using any of the existing modules to upload images.

Doing this means that you are required to implement and maintain multiple methods of of doing the same thing. Adding the archives together is a method that can be used to reduce this but it means that from the point of view of the image module you have orphaned images, so they are not consistant across the site.

Adding a helper stand alone module for image manager can be done, and as I said I have implemented a hook in htmlarea so that you can customise htmlarea with configuration pages and customised calling of plugin such as the CSS which required additional arguments to use it.

--
Gordon Heydon

Larry Cannell’s picture

I view this as a better alternative to the upload (simple) module, not the image.module. For community sites where multiple blogs support people who are NOT webmasters it looks like image.module is still a better choice. In this case images need to be content managed and not simply files sitting in a directory managed by a fancy ftp-like utility.

There are places for both approaches.

--
Larry Cannell
larry@cannell.org

neofactor’s picture

Quick question as to how people config this.

To make the plugin "relative" I use the following:

Folder at the root called files chmod at 777
$IMConfig['base_dir'] = '../../../../../files/';

Here is the tricky issue... for the base URL I need to hardcode the enitire path to get it to work all around. Anyone know how to make it realtive?

It would be nice if Drupal HTMLarea had a default dir and url path that each plugin pointed to... thus making it configurable from one location.

Any thoughts?

Having config issues and need your help.