Drop "Add image" button in favor of Wysiwyg API

This is much worse, than just a logic flip on the UI - at least on 6.x-2.0-alpha3 release, these settings actually WORK (more or less) as proposed here (in the same order), so the descriptions on the UI are plain wrong. This problem is with the textareas setting, where actually the first works as "Show only on listed textareas", and is (correctly) kept this way after 5.x->6.x upgrade on my site (previously set to only show on listed textareas), so I think the UI labels need to be changed.

But there's more: When I had the setting saved along the UI description (i.e. I selected the second option, to supposedly "show only on listed"), it showed just everywhere (!), listed or not. I suspect there might be some problem with the actual logic. I want to examine what exactly is going on at the end of _img_assist_textarea_match(), as this bit of code: $page_match = !($must_match xor $page_match); seems to be rather weird evaluation for a boolean.

Also it seems like changes to these settings only apply after hitting the "Clear cached data" button on Performance page, so we might want to flush some cache on submit (form cache? variables somewhere?), and for now, it makes testing a bit more difficult.

Just writing this down, so that someone else can possibly pick the issue. Otherwise I'm not done with testing yet, and I'm also fully aware, that a check against latest CVS code might be good, but it's too late night now, and I can't continue until next week.

EEEEK!

I maintain a site, where no WYSIWYG exists, the whole thing uses a pseudo-markup filter. This is partially for historic reasons, partially due to the size of WYSIWYG JavaScripts, but not only. The existence of this button, providing easy way of inserting image tags along with image uploads, is why we use Image Assist. Honestly, if you want to have real control over formatting of your posts, plain old HTML is the best, and a pseudo-code filter makes that digestible for less experienced users. Image Assist is important add-on to the workflow.

Anyway, I definitely vote for a bugfix, rather than removal of this already existing functionality. Why should be a big JavaScript bloat required for a simple textarea to work?

Well, the real issue is that Image Assist contains a bloat of code - just for this simple, single button.

The issue is that, with Wysiwyg API, you could use a so called "pseudo-editor" (no "WYSIWYG", just buttons, which insert strings into a plain-text textarea) like the ones I mentioned, only enable the Image Assist plugin, and get the same (and more) with much more reliable and stable modules.

For example, if your users like to press a button to insert an Image Assist inline tag. Well, then they probably might also like a button to insert <!--break-->, right? Oh, and a button to insert a different inline tag for uploaded files? Maybe one for inserting a flash movie?

The underlying issue is that the approach taken by Image Assist, providing a custom button for custom pseudo-editor-alike functionality, hurts the user experience and overall evolvement of a proper UI pattern for content-editing modules.

Bear in mind that this change would not remove any functionality. It would just be much cleaner, more flexible and extensible. Also, I don't let the JavaScript-filesize argument slip through here. If you look at the amount of PHP and JS code loaded by Image Assist (just for this button) and compare that to the size of a solid pseudo-editor library like markItUp, then it is just wrong.

And, yes, more to come: Additionally, those visibility settings make no sense at all. Image Assist only works on input format enabled textareas. If you configure a path, role, or whatever that makes Image Assist appear on textareas that are not input format enabled... well, UX hell is loose.

Thanks for those use-cases!

There are textareas outside normal content, still using default filter format (although not always displaying the selector/tips fieldset), such as user profile fields, custom blocks administration, and the like.

#366015: Add module to fix missing input formats in Drupal core

Embedding images into private messages is highly discouraged on my site, as it bloats the server filesystem - you see, when the message is deleted (these are numerous, and really short-lived), the image stays. Also the user naturally expects an image embedded in private message to be "private" too - but in fact it's created as regular node, and exposed in various "latest posts" lists and the like. That's why I would like to disable the button on such textareas, while still keeping the default input format having it, so it shows on regular node forms by default.

Multiple options:
a) Use Better Formats to limit the input format for private messages to a certain one, not supporting images.
b) form_alter-away the input format selector.
c) Patch the module so it allows you to configure whether there should be an input format at all (like CCK does for each text field, for example).

There was also a request to re-introduce the #wysiwyg FAPI property, so developers were able to hard-code that no client-side editor shall appear.

Actually, I might also want to disable the button on per-textarea basis on my CCK content types, where I already have a dedicated text field for images (preferably embedded in a brief description/introduction text), and so I want to discourage images in other fields to enforce consistent format of the posts.

#350696: Per field format settings with full BF options via CCK widget

How the new WYSIWYG stuff play with that?

I'm afraid - neither Wysiwyg API nor Image Assist is the module that should allow or provide such alterations, because that is plain scope creep. Ultimately, it's Drupal core, but as long as that does not provide it, you may use Better Formats to do it.

@JirkaRybka: Stop excusing yourself. :) Your thoughts and use-cases are highly appreciated!

And, yes, I won't remove this feature unless there is a valid / identical replacement. So far, there is none yet, because all pseudo-editors supported by Wysiwyg API do not implement support for so called "Drupal plugins", i.e. editor plugins provided by other Drupal modules that work with any editor.

Because I really like markItUp best from all pseudo-editors (technically), I'll try to implement support for Drupal plugins. When that is done, I'll point you (here) to test it. I predict you'll say: Wow, let's remove this crap! ;)

+1 for this, it would make so much more sense.