Designs & specs.

- Initial design: #1773748-1: [meta] Media + in-place editing.

Files: 
CommentFileSizeAuthor
#7 Insert_tab.jpg248.79 KBtkoleary
#1 Insert_tab.jpg81.13 KBWim Leers

Comments

Assigned:Unassigned» tkoleary
StatusFileSize
new81.13 KB

@tkoleary's designs attached. I'd swear there are more extensive designs for this, but I can't find them right now. I'll ask Kevin to elaborate here.

Issue summary:View changes

Updated issue summary.

It would also be good if we could ensure that the UI for Media integration is consistent with the current code, or the current code is updated for this new design, rather than having a different UI just for Edit module integration.

Does it have to be specific to images, rather than media in general?

#3: Agreed. It should be consistent.

#4: This issue is about Media in general.

#4: This issue is about Media in general.

I was just commenting on the design in #1... it seems like the button could just be insert media rather than insert image, and use the media library for in-site media http://drupal.org/files/images/screenshot_40.jpg

StatusFileSize
new248.79 KB

So here is a design which is part of aloha wysiwyg integration in spark. It only covers images though.
insert tab design

This looks amazing @tkoleary. How do you see the caption/alt/etc. being entered on/around the img tag? It seems like you'd need an additional modal or at least a set of textfields to insert that information. Due to the difficulty of creating a caption when one doesn't exist already, I think the caption would have to be a discrete field somewhere.

Lastly, image alignment buttons should probably continue to exist also, either as separate buttons or as a single button/dropdown.

These look great, implementation details aside. I'm not sure anyone has a solid plan for what to do about cropped/rotated images (don't forget the "Reset" button too). :)

These do look fantastic. Is the eventual plan for this to integrate with file-entity-in-core, or will inserted media only be plain elements with no reference to the Drupal-managed file entity?

Component:User interface» Code

I strongly suggest looking into the WYSIWYG Fields module for this. There's already support for making it the official method of WYSIWYG integration for Media module (see #1664418: Replace custom WYSIWYG integration and support WYSIWYG Fields module instead).

That looks really promising (plus the maintainer pointed out yesterday they have sponsorship for development) but it seems like the thread has been left hanging since June, possibly because all energy getting diverted to getting file entity in core.

That's a point really, if Aloha did make it into core wouldn't there need to a fallback traditional image insert? I suppose not really, since there wasn't one in Drupal 7, seems reasonable really to expect users to download/install media module to have this functionality materialise.

What I like about WYSIWYG fields is that it's field agnostic. The same module can be used for inserting anything into a text area. Including field collections. And the site designer can have complete control over the formatting of what's inserted.

When I need to insert media into a text field, I typically don't want to just insert a picture. Along with the picture, I want to insert a caption and possibly a photo credit. Then I want my users to choose between a few set formats—generally left, right and center—so I can have complete control over how this little bundle of content is styled and displayed on the page.

The one issue I had with WYSIWYG fields the last time I played with it (in D6) was that it put the same button on every text area with a WYSIWYG toolbar. I need the ability to restrict WYSIWYG field buttons to specific WYSIWYG profiles. That way I can allow images to be inserted into body copy, but not teaser text, for instance. I'm not sure if this has been implemented in the latest D7 branch yet.

I have every intention at looking at Wysiwyg Fields and Aloha integration, I have co-maintainership on the Aloha module, although I haven't had very much time for it lately, but I do intend on seeing what can be done.

However, Wysiwyg Fields is meant to integrate Fields into the Wysiwyg module, at the moment, so the two obvious negatives I see here are:

1. Aloha is a frontend editor, therefore there are no Field elements available at the time of editing, although this could be achieved with an AJAX callback bound to the edit event so that the Fields are brought forward, but I don't see it being a simple exercise.

2. Wysiwyg API module isn't involved in the process, which means a complete recreation of the relevant Javascript in Wysiwyg Fields, however this isn't a huge issue either as that's already on the cards and in some ways has partially begun, but again not a simple thing.

 

The main thing is that unless I get a second developer on board with Wysiwyg Fields, preferably someone with a high level of competency with jQuery and Wysiwygs, then it's going to be extremely hard for me by myself to achieve this goal as while I do have a sponsorship from time to time on Wysiwyg Fields, it's for the core functionality or some specific feature and that's where my concentration has to be, and when I don't have sponsorship my time is spent on whatever is currently paying the bills.

Cheers,
Deciphered.

Does it insert some kind of token/macro thing that gets expanded later on, or does it insert actual HTML? The codebase is pretty complex and the big picture doesn't seem to be documented anywhere.

I'm working with sun on something that is related to this: #1706688: [meta] In-place editing, inline macros, editables, and Wysiwyg in core, the "inline macros" stuff. The goal is to provide a unified way for referencing "stuff" in textual fields, while still making it possible to interact (add/delete/change to a different referenced thingie from a list of referenceable thingies) with it inside a WYSIWYG editor.
I should be able to share a link to a dedicated issue soon.

Please don't hijack this issue though; this issue is specifically about integrating Aloha Editor with the Media module.

@Wim,

Yes it creates a token so that if the field or formatter or formatter settings can be changed at a later stage, manually or programatically, allowing the front-end to reflect the changes automatically.

Wysiwyg Fields integrates with the Media module, and there is talk of replacing the Media modules Wysiwyg integration with Wysiwyg Fields, hence it being bought up in here.

I'm happy to talk the specifics of Wysiwyg Fields with you in another location though.

Title:[meta] Media + Aloha Editor[meta] Media + in-place editing
Issue tags:+Spark media

Tagging for media, retitling for in-place editing instead of Aloha, that we don't use anymore.

This issue is highly relevant to implementing image handling in core: #1932652: Add image uploading to WYSIWYGs through editor.module

It lays out a plan for technically handling inline images: how they can be uploaded, where the settings for uploading live, how the files are marked as permanent and associated with a piece of content, and how they can be cleaned up upon content deletion. This issue may serve as a good template for how the modal design may look.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes
Status:Active» Closed (works as designed)

This basically got fixed in core, so marking to working as designed. If that's wrong, feel free to reopen.