Originally outlined in my vision for handling embedded/inline content 3 years ago, there hasn't been much (or rather arbitrary) progress on this topic. Given Drupal 7, it is time to revisit this challenge.

This is a call for contributors familiar in this field, to discuss and develop a single, rock solid module. The idea is to take the best ideas and techniques from the following list of modules:

Note that there has been lots of brainstorming and discussion for Inline 2.x in the following issues, which everyone involved should at least have read once:

Most probably, we're going to use the Inline project as target. Originally, I played with the idea of using the "embed" namespace, but that has been (rightfully) taken by Embed module already. Therefore, "inline" is the closest possible term. However, this does not mean that we are bound to the current code of Inline module.

Lastly note that Wysiwyg module actually has little to do with this effort - except that most people are associating this kind of functionality with content editing and client-side editors, and in the end, most people expect to see a "button" for end-users allowing them to embed stuff. But that said, Wysiwyg is going to do any changes that may be required for this to work, if any.

So let's compare what we see and have so far, discuss technical as well as user-facing details, and everything else related to this topic. In the long run, I'd like to see a team of dedicated people working together on the project. So far, the lack of dedicated contributors willing to join forces has been the primary reason for holding up the development for so long.

Who's on board? :)

Comments

subscribe.
Also note, oEmbed (http://www.oembed.com/)

Flag me as a very interested potential contributor and discusser. This is a crucial missing piece of the Drupal puzzle, providing a friendly end user experience along with solid data storage and references.

Let's not forget Insert module.

And don't forget to first formulate the problem from a user's perspective before discussing solutions (to what?). Subscribe :-)

Subscribing

@#3

Due to the extensive work I have already done in Wysiwyg Fields, it became apparent that Insert may not be relevant due to the approach it takes to rendering the themed preview of the field.

Insert relies on FileField/ImageField passing the data back to Drupal via an AHAH call so that it can calculate the relevant outputs, which is not a possibility for any other standard CCK field like Text, Number, Node Reference, etc, where they are simple fields that don't invoke an AHAH callback.

In Wyswiyg Fields I have an alternate approach where an insert button and formatter field (hidden or selectbox depending on field configuration) is attached to every relevant element, which invokes an AHAH callback when inserting the field, solving the issue.

If Quicksketch was open to re-writing Insert in this way, or a similar way it may be usable, but for the moment his method can only be used as was intended; for FileField and ImageField.
This is in no way a critique of Quicksketch or Insert, just an observation based on my specific requirements while developing Wysiwyg Fields.

Subscribing to this super sweet thread.

This is a brief writeup on Wysiwyg Fields, I'll likely continue work on the module until a firm plan is put into action for Inline, as it's likely the common issues will be the same across both modules.

Wysiwyg Fields

https://github.com/Decipher/wysiwyg_fields/

Personal requirements:
- CCK Fields embedded directly into the Wysiwyg via Wysiwyg plugins, displayed inside a jQuery UI dialog on Invoke.
- All fields insertable into the Wysiwyg as the formatted output based on the chosen Formatter.
- On Wysiwyg Detach/Node save, previews are turned into a Token indicating CCK Field, Delta and Formatter, to be rendered via a forced enabled filter.
- Wysiwyg previews will be updated when field is updated, either via onChange() of field or when dialog is closed.

Current status
- All CCK fields can be set as Wysiwyg Fields.
- Wysiwyg Fields Wysiwyg plugins are being dynamically created as required.
- Insert button and Formatter selection are being bound to Wysiwyg Fields.
- Insertion of fields trigger an AHAH callback that returns the rendered output via the chosen Formatter.
- Wysiwyg plugin: On Detach output is converted to token, and vice versa on Attach.
- Filter renders field as required.
- Filter cache is flushed on Node update.
- 10/01/11: Filter enabled on all Input Formats on install.
- 10/01/11: Updating a node referenced by a Wysiwyg Field will flush the filter cache of the referencing node to reflect the updated node.

Todos:
- Enable required filter on all Input formats on installation of module and on creation of new Input Formats.
- ImageField/FileField doesn't work with extra AHAH wrapper.
- Node Reference doesn't pass formatter value to AHAH callback.
- Number field (and possible other fields) value not passed through all CCK hooks correctly?
- Make rendered field in Wysiwyg non-Editable, possibly based on TinyMCE non-Editable region plugin.

Not only don't forget oembed, but oembed's drupal module http://drupal.org/project/oembed is both an oembed consumer (as field formatters and input filters) and provider. It's already useful for embedding Drupal content in other Drupal content.

Inlining, embedding, or inserting content is a (hyper?) link and so it expresses relationship between pieces of content.

I'd like to be involved. Sign me up!

oembed seems good way to go

@#6
Thanks for explaining. Even if Insert (or any other module) is not the best solution in a specific area (themability, flexibility, usability, you-name-it-ability), it's good to discuss it here so we can learn from its shortcomings and strengths.

I agree with bangpound and the others mentioning oEmbed here. Being the maintainer of the oEmbed module I would happily be involved in this.

I think using URL:s to identify all embeds, like oEmbed do, would create the most flexible embed system for multiple reasons. The same system could be used to embed external and internal data and the internal data could easily be exposed to other sites for embedding. URL:s are also a concept people are very familiar with and since they can be used on their own it's very easy to recognize what is embedded by just looking at the raw non-processed body of eg. a node.

oEmbed also has good support on the web, gaining more momentum every day. Other platforms like Flickr, Twitter, YouTube, Vimeo and WordPress are already supporting it and 160 additional ones are supporting it through Embed.ly.

The provider part of the oEmbed module needs an overall improvement. Improving it to solve the needs brought up in this issue, like targeting specific fields in nodes, seems like a good way forward. I might be short of time to do it all myself - but would happily add co-maintainers to the project to ensure its future development.

What I see as needed:

  • Port oEmbed to Drupal 7: #1018938: D7 port of oEmbed
  • Add WYSIWYG-tool for oEmbed
  • Extend the oEmbed provider to better support more content and subcontent

I made proof of concept module, half year ago... Mediareference - it is a D6 special kind of multiple field based on nodereference CCK field with builtin Insert integration - so it is working with both pure textareas and Wysiwygs. It is partly similar to Aaron's Media module and was started at the same time, but it is doing things in a different way.

I see two ways in embedding content:

A) Using JIT render = content is rendered in time of presenting content to the user:
This is a Media way - together with Styles module, you are allowed to insert anything directly to the content. Users can't change (and potentially broke) the outputted HTML as they are seeing only special markup [[nid]] in the content source or preview generated by the Styles in the Wysiwyg editor. This is very cool, very robust.

B) Using pre-render = content is rendered during time of updating content by the editor.
This is a current Mediareference way, first you need to build local resources library for the content. Than you can insert this referenced content from the local node library (using Insert module) as an inline content. This is very simple, all Wysiwyg editors are supported by design (not only those supported by Wysiwyg API) but users could change (and potentially broke) the outputted HTML.

I made couple of sites which have large media libraries and implementation always resulted in the same solution: a media pool which could be accessed from story like content types in a popup window with thumbnails where you could upload, delete, edit or search the media (the images or videos in most cases) and choose them for embedding as an inline content or as a nodereference.

Development state of Mediareference
Development of Mediareference is now frozen as I need to check the new features in D7 first. I also need to think about the use cases and possibilities, because the primary use case objective is now occupied by the Media module.

Just another update on this because I don't want this to lose too much momentum, I am still working on my own module (Wysiwyg Fields), but once it is completed I intend to work towards to collaborative goal (whatever that may be).

Wysiwyg Fields could definitely use some Alpha testers if anyone had the time, otherwise I will likely be pushing out a Beta release on D.o. hopefully in the next month.

subscribe, will alpha test anything D7

Hello everyone,

Towards this end, I have proposed a GSoC project for integration of WYSIWYG and Media. Please review and suggest improvements here - http://groups.drupal.org/node/137104.

Thanks

darklrd

Subscribing from #1016376-22: Expose the media types allowed for WYSIWYG variable in the UI. Note that the Media module has just undergone some refactoring, which should make things slightly easier now on the Media integration front. Granted, that's only a small piece of this larger puzzle.

subscribe. we should have had this discussion a long time ago; sorry i missed it -- media has independently developed its own inline notation, as has node embed and nrembrowser. kicking myself for having forgotten about that earlier thread; would have been useful to at least direct some of that dev.

Subscribing.

subscribe

This is a great initiative, and I'd love to see it succeed. Drupal so needs to nail this feature. I'd like to help in any way I can.

Super subscribe

sub..

subscribe

I've created a comparison of the modules mentioned in this issue as a wiki page on groups.drupal.org. Groups.drupal.org doesn't handle wide tables very well, so I've attached a html version too, tell me if there is a better option. Please take a look at it and edit it. I hope it can give an overview of the current approaches so we can decide how to go forward.

subscribing

Subscribing.

lets not forget the video module...
see here #1070510: Integrate media with video module

Holy Jesus, this is sad. There is still no easy way to handle media :(
edit: subscribe

Subscribing as an interested Media.module co-maintainer.

Sub, want to help out aswel. But where to begin....

Subscribing.

Really want to help, really need a solution for displaying media!!!

I have everything set up, Media handling the different types , views presenting a media list and a views attachment displaying the selected media file. Image Styles handling the display of images, however I can't find anythnig that fits the case of displaying the video file.

Ideally I'd expect to set the file types file display property (in the default view for example) to 'whatever_video_renderer', but nothing seems to fit, mediafront won't take it, videoelemend.js maybe but still attempting to find a solution.

Any coding or anything I can do to help, please shout!

If you want to help, here is a link... http://groups.drupal.org/node/173749