Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Designs & specs.
- Initial design: #1773748-1: [meta] Media + in-place editing.
Comment | File | Size | Author |
---|---|---|---|
#7 | Insert_tab.jpg | 248.79 KB | tkoleary |
#1 | Insert_tab.jpg | 81.13 KB | Wim Leers |
Comments
Comment #1
Wim Leers@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.
Comment #2
Wim LeersImplementation issue: #1760966: Aloha Editor + Media module integration.
Comment #2.0
Wim LeersUpdated issue summary.
Comment #3
Dave ReidIt 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.
Comment #4
lightsurge CreditAttribution: lightsurge commentedDoes it have to be specific to images, rather than media in general?
Comment #5
Wim Leers#3: Agreed. It should be consistent.
#4: This issue is about Media in general.
Comment #6
lightsurge CreditAttribution: lightsurge commentedI 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
Comment #7
tkoleary CreditAttribution: tkoleary commentedSo here is a design which is part of aloha wysiwyg integration in spark. It only covers images though.
Comment #8
quicksketchThis 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). :)
Comment #9
RobW CreditAttribution: RobW commentedThese 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?
Comment #10
jstollerI 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).
Comment #11
lightsurge CreditAttribution: lightsurge commentedThat 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.
Comment #12
jstollerWhat 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.
Comment #13
Deciphered CreditAttribution: Deciphered commentedI 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.
Comment #14
Wim LeersDoes 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.
Comment #15
Deciphered CreditAttribution: Deciphered commented@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.
Comment #16
Gábor HojtsyTagging for media, retitling for in-place editing instead of Aloha, that we don't use anymore.
Comment #17
quicksketchThis 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.
Comment #17.0
quicksketchUpdated issue summary.
Comment #18
webchickThis basically got fixed in core, so marking to working as designed. If that's wrong, feel free to reopen.