Replace custom WYSIWYG integration and support WYSIWYG Fields module instead

Also, a documented upgrade path.

I really like this idea, I've just try wysiwyg filter (I didn't know before) and it does exactly what I want.
I find that it's more logical and easy to manage to have body's images and other medias attached to a field of the same entity. You can make views on it, clean unused media easily and safely, ...

anyone pinged @Deciphered to share his thoughts?

PRO: I guess this would also open up the ability to use http://customformatters.com/ with http://drupal.org/project/custom_formatters

I'm thinking what if someone wanted to insert a cover image of a pdf that was inserted into the wysiwyg, I guess they could write a custom formatter that uses php with Image Magick and then use http://drupal.org/project/wysiwyg_fields to choose the correct formatter.

No one has pinged me no, however linking to CustomFormatters.com did help.

I'm very much interested in this, and am happy to help with anything involved. The biggest thing I need though is additional developers to hep out with the Wysiwyg Fields module, it has potential to be something great but it is a very tricky beast and I am always time constrained.

I'd love to see this happen. Has there been any movement in this direction?

Now would be the appropriate time, I've got sponsorship (a portion of it left) currently going for using Wysiwyg Fields on a project that will also being using Media (2.x), so if there are any issues with Media and Wysiwyg Fields now would be the time to point them out so that they can potentially be covered with this round of development.

Otherwise, I still plan to make this happen regardless, it's just that sometimes paid work pulls me away from the module. Other developers with interest in Wysiwyg Fields could always put there hand up to get involved though.

I've just suggested that WYSIWYG Fields be the default method for inserting media in the Spark project as well. #1773748: [meta] Media + in-place editing

A big +1 for this. I'm ready to help how I can.

Ditto +1

This method would also be a better for user to grok in my opinion. Instead of the user having to learn about the WYSWIG button that uploads and selects images/media, and the media field, that uploads and selects images/media, they would have an UI learn.

I've been doing quite a bit of research here and do agree that this is the best path to take media / wysiwyg integration.

The default implementation is nice because it seems to be the only stable option out there but has obvious limitations as noted here. There's some interesting discussions around using insert (#1140404: Add insert module integration) which was my previous go-to in D6 but it doesn't seem that's going to take the next steps towards a tighter integration (e.g. moving away from a hard-coded path & allowing the formatter to be selected).

The current implementation isn't working 100% for me. In an effort to continue progress, Deciphered, I'd be open to assisting with a sponsorship here.

dwatts3624,

The biggest problem for me isn't money, it's more lack of additional developers, primarily a Javascript and/or Wysiwyg specialist. There's so many little javascript/wysiwyg based issues with the module that it's difficult for me alone to resolve.

Ideally my plan would be to completely refactor the Javascript and make a plugin for each relevant Wysiwyg library, which should hopefully better leverage the individual APIs and therefore resolve the issues that currently exist.

If anyone knows of anyone who may be interested in getting involved with the project I would greatly appreciate the introduction.

Cheers,
Deciphered.

Maybe I'm being too simplistic, but perhaps this is just a matter of refocusing existing resources. Who on the Media module team has been responsible for the current custom WYSIWYG implementation, are they on this issue, and would they be able to transition to helping @Deciphered with the WYSIWYG Fields module instead?

That would work for me.

Does not support when WYSIWYG is used on a non-entity (and non-field) basis. For example, using WYSIWYG in core custom blocks.

bothers me.

@aaron,

I would be more than happy for someone to re-architect Wysiwyg Fields so that it had a FAPI engine as well as a Fields engine, but the complexity would be overwhelming and probably not worth the payoff.

Wysiwyg Fields utilizes the Fields system to store all data that is injected into the Wysiwyg (via Wysiwyg Fields) so that it doesn't have to re-invent the wheel and has the data tracked and accessible via Drupals various systems (such as the Field Formatter system or Views).

If someone can think of a solution for this I would be happy to take it onboard, but I doubt other than turning FAPI Wysiwygs into an entity on the fly that there is really a solution available.

Any progress on this? The current discussion of file view modes ( https://drupal.org/node/1792738 ) is I guess a not so cool integration as the one discussed here.

@mori,

Aaron has mentioned that he wants the integration to work on non-entity based fields, in which there is no way for Wysiwyg Fields to work in that scenario as Wysiwyg Fields uses the Fields system to store data.

There's nothing stopping you from using Wysiwyg Fields with Media, I currently have clients doing exactly that. It is a tiny bit buggy, but more developer support (especially javascript developers) could easily remedy that.

Cheers,
Deciphered.