integration with other input filters

+1
This is a very important patch for making wiki's and images more user friendly.

I applied the patch and it worked as advertised.

I think with this added flexibility there would have to be a configuration option for selecting what formats should be available to the users.

The patch looks clean enough. I'm just thinking: where will we end up if more input formats are added? For example, you could do the same for Markdown and Textile.

A nice solution would be to have a subdirectory called filters where we could put files that handled one filter each: img_assist_filter_standard.inc, img_assist_filter_html.inc, img_assist_filter_mediawiki.inc etc. (Maybe there would also have to be javascript counterparts in there: img_assist_filter_standard.js etc.) That way, people could easily add their own filters without altering img_assist.

That's kind of a big challange though. Anyone interested in working on a solution like that? Is it even a good idea?

You're right, there is no need to add an additional plug-in mechanism when we already have one (the module system). Implementing this as Drupal modules would also make it easy for admins to enable/disable formats: just enable the modules that correspond to the formats you want to use. (It would also make it possible for input format modules like Pearwiki_filter to implement the necessary hooks for integration with img_assist, so you wouldn't actually have to create any additional modules – although it might be better to keep this functionality separate.)

A natural consequence of this would be that img_assist's input filter should be moved to it's own module which takes care of the filter work and implements these new hooks. The HTML format is indeed a special case and could be kept as a standard fallback format in img_assist.module. We could do this without changing the user's view of img_assist at all (except admins would have to enable two modules instead of one).

A good start would be to outline an example module. I'd take img_assist's filter and try to make an example module out of that. That should make it obvious what hooks need to be created and what arguments they should have. It sure sounds like interesting work, but I don't have time to do it right now.

I think this is a good plan!

Wow, that's awesome! I guess it's true: talk is silver, code is gold, right? :)

I haven't tested this, nor have I looked properly at the code, but it all sounds very good! And the patch actually looks a lot smaller than I thought, which is promising.

I will test and review this properly as soon as I can. I've got some day job type work to do first...

OK, I've looked through the code a little more now. Looks good! It's nice to see how easy it would be for an input format module to implement this.

So, I had a couple of thoughts, still without having tested it:

1. Different input formats will probably support different properties of the image (title, description etc.). Would it be useful to add an argument to the hook where the modules can state which properties they support? That way, it would be possible to show that to the user somehow. I'm not sure this would be required though.
2. The hook allows modules to define more than one input format. Is this a general enough scenario to justify the (small) extra complexity, or is it in fact only pearwiki_filter that will ever need it? (Not a real problem, just thinking...)
3. I can't think of a scenario where a module would need to include a css through this hook. I think we can probably skip that.
4. People using TinyMCE probably rely on HTML for the most part, except for the img_assist input filter. But would it be possible that in some situations you'd want the same flexibility with regards to input filters when using TinyMCE as when using ordinary textareas? That would require that modules could add new filters to the drupalimage plugin. If you're using wiki syntax or Markdown for example, then I guess the answer is no (because you probably wouldn't be using TinyMCE), but what if you want to create another image input filter like [img_assist]? Yes, this might be overkill.
5. Speaking of TinyMCE, have you checked if any of the changes in img_assist_textarea.js need to be done in corresponding places in img_assist_tinymce.js?
6. I'm still thinking about moving img_assist's input format into a separate module, but that doesn't have to happen now.

Thanks for the work you put into this, I think it'll come out great! The Drupal kids are gonna love you for this! (I will anyway.) :)

...how would you access this information in the img_assist.js file?

Not sure... Maybe trough some query string? Anyway, that can definitely be saved for a later time.

I don't really understand what you mean...

Sorry. The question is simply: Should filter modules be able to talk to TinyMCE through img_assist? That would make it possible for a tag like [myimagetag|1354] to be interpreted by TinyMCE and displayed as an image in the WYSIWYG field. Now that I think about it though, it would probably be more reasonable to have such modules provide their own TinyMCE plugins (like "drupalimage", which is img_assist's plugin).

So, what we need now is testing I guess. And more reviews wouldn't hurt. We should also test how this behaves with TinyMCE. I'll do that as soon as I can, as well as doing another filter implementation as a way of testing the developer part of it.

Sorry, haven't had any time to work on this so far. It wouldn't hurt if someone could help reviewing and testing this patch.

Sorry for the dumb question, but how does one apply such a patch??

Take a look at this page in the handbook.

subscribing. I should be able to do some testing on this in a few days.

As far as moving to a seperate module, there are a number of generalized, "hookable" filter modules springing up, it may be possible to merge/piggyback with one of them.

Aren't those input filters supporting HTML? If they do, this issue should only force img_assist filter to come first, i.e. in front of all other input filters.

Img_Assist certainly won't be able to support and maintain all of these input filter tags. However,

1) Implement a new hook_image_syntax() that allows input filters to describe how they interprete images.
2) On processing of img_assist filter, img_assist invokes module_invoke_all('image_syntax') to retrieve a custom image syntax (or uses default HTML if nothing is returned) and render the image tag.
3) Ensure that img_assist is always executed in front of other input filters.

Now the show stopper:
All of this won't work out, if more than one input filter is installed (+ enabled) that provides an alternative input syntax and therefore would implement this hook.

Hi all,

I try to apply the patch and get the error message:

netomussauer@netomussauer-laptop:~/backup/diversos/arquivos/drupal/sagu-pro/modulos/img_assist$ patch < img_assist_wiki_filters.patch
patching file img_assist.js
Hunk #1 FAILED at 131.
1 out of 1 hunk FAILED -- saving rejects to file img_assist.js.rej
patching file img_assist.module
Hunk #1 succeeded at 327 (offset 12 lines).
Hunk #2 succeeded at 957 with fuzz 2 (offset 1 line).
patching file img_assist_textarea.js
Hunk #1 succeeded at 79 with fuzz 1 (offset 3 lines).

Sorry for my english, im a brazilian guy

Please note that when you change the title, you change the whole issue's title.

As for applying these patches, you will probably have a hard time due to the fact that there has been so many changes to the module since they were rolled. The patch program gets confused. You can either check out a version from CVS from the time when the patches were posted and try to apply them, or someone will have to examine them manually and roll new patches.

But I think this effort could use some rethinking. Sun's thoughts above seem like a good starting point.

So now that work on Inline API has begun, this feature request fits much better there. This is a feature, any input filter would benefit from - because of that, I'm moving this issue to Inline's queue.

Can anybody provide a similar patch for 6.x?

Using the latest dev version (6.x-3.x-dev) I just replaced line 76 of img_assist_textarea.js with

var content = '[[Image:' + captionTitle + '|' + align + '|' + width + 'x' + height + 'px' + '|' + captionDesc + ']]';

and it works for the PEAR wiki filter I have running. This was simpler than figuring out how to patch version 6.

I've gotten it to work even better by adding the following lines of code:

var size = formObj['edit-size-label'][formObj['edit-size-label'].selectedIndex].text;

in the getFilterTag function in img_assist_textarea.js followed by

var content = '[[Image:' + captionTitle + '|' + align + '|' + width + 'x' + height + 'px' + '|' + captionDesc + '|' + size.toLowerCase() +']]';

The size variable gives me the size selected in the dropdown menu which I can then use in the PEAR wiki module as described here: #1177192: Use image module presets in image