Teaser splitter / text fields with summary support

@sun

I think the quickfix is not a great solution because even as a textarea it is better than nothing until we fix it properly.

Just so I'm sure I undertand what you want to do, the work here is to allow the summary field to also be rendered as a WYSIWYG?

Best,
J

subscribe - thanks for the work on this...

subscribe

subscribe

Referenced in #221257: text_summary() should output valid HTML and Unicode text, and not count markup characters as part of the text length See comment #93: Summary requested by ysched.

What is the status on this issue? Does the patch in http://drupal.org/node/221257#comment-4475410 solve this issue? That means: does it offer a wysiwyg editor on the teaser field in drupal 7?

--EDIT--
I tested that patch, and it does not solve this issue.

@zilverdistel: The status is that sun has identified a problem and suggested a solution strategy, but nobody has written a patch. You can help either by writing a patch, or by asking another programmer to write a patch.

@pillarsdotnet: I think there are other ways of helping than the ones you describe (e.g. bug reporting, test reporting, ...). I hope I'm not misunderstood, I'm thankfull for all the efforts you put in the drupal community/code!

subscribe (http://3281d.com/2009/03/27/death-to-subscribe-comments)

sub'n

I think this should just about do it.

There's a minor bug with this approach, but I'm not sure it's worth holding up this feature over. To reproduce (in Google Chrome, at least):

1. Click the "Disable rich text" link under the Body, then click "Enable rich text" to turn it back on.
2. Click the "Disable rich text" link under the Summary.
3. Notice that the Body field's "grippie" for normal field resizing now incorrectly appears under the Body field title.

The grippie being out of place doesn't seem to have any negative effect other than aesthetics... It's non-functional while the rich-text editor is enabled for that field (i.e. the rich-text editor's resize grippie still wins), and it pops back in place if you again disable rich text on the Body. Not sure where to look to fix this, but if the patch is otherwise acceptable, I could open up a separate issue for the grippie problem.

Just tested this out on a basic page with TinyMCE editor on the body field, using Full HTML. The node already existed with body content but no summary.

1. Clicking "Show summary" successfully displayed the summary with TinyMCE attached
2. Clicking "Disable rich text" for the summary successfully detached TinyMCE
3. Clicking "Enable rich text" for the summary threw a javascript error, and TinyMCE was not reloaded
   

   Uncaught TypeError: Cannot set property 'status' of undefined
   Drupal.wysiwyg.toggleWysiwygwysiwyg.js:231
   c.event.handlejquery.js:64
   c.event.add.h.handle.o
   

I might add that I am on Wysiwyg 7.x-2.1 rather than dev so had to apply the patch manually. Perhaps someone can confirm if these steps produce the same errors on the latest dev snapshot?

Hey mstrelan, I just setup a new test environment with TinyMCE and ran your test, but with a patched Wysiwyg 7.x-2.x-dev instead of 7.x-2.1, and I couldn't reproduce your results. Everything worked fine for me; no JavaScript error, and TinyMCE reloaded properly. Can you retry with dev and see if the patch works cleanly? Thanks!

Edit: Also be sure to clear your caches after applying the patch.

Updated the patch to fix a bug that occurred when the "Summary input" option was disabled on the field.

Ok using latest dev snapshot solved it, sorry I should have done that originally. I tried this time with the patch from #15 and it works (except the problem with grippie).

sub

Hi muriqui this patch works! It's great - exactly what I needed.

Will it be incorporated into WYSIWYG or will I have to repatch for each update?

thanks again.

Hi dawnbuie. Whether or not the patch gets committed to WYSIWYG isn't my call; I'm not a maintainer on the module. But if you've tested the patch and found it to be a good solution, feel free to change this issue's status to "reviewed and tested by the community" to indicate to the maintainers that it's ready for inclusion. Thanks!

sub

Rerolled #15 and tested it: everything seems to perform well, even the grippie, on Firefox 10, Chrome 17, Safari 5.1.1, Opera 11.51, Internet Explorer 7-8-9.

Tentatively marking RTBC to get some feedback from the maintainers.

I just had an error in wysiwyg.js while uploading an image in an image field. Reverting the patch fixes the problem. I'll try to provide a new patch fixing the issue.

We were missing a multiple detach:

   detach: function (context, settings) {
     $('.wysiwyg', context).removeOnce('wysiwyg', function () {
       var params = Drupal.settings.wysiwyg.triggers[this.id];
-      Drupal.wysiwygDetach(context, params);
+      Drupal.wysiwygDetachMultiple(context, params, 'format' + this.value);
     });
   }

Works as described.

Can confirm the patch at #23 works great :D

+1 for the patch in #23... Just retested and confirmed that the splitter works and that the issue in #22 has been resolved. Thanks, plach.

+1 for the patch in #23... Just retested and confirmed that the splitter works! Thanks!

Patch from comment #23 tested on 7.x-2.1+13-dev version.
Spliter works fine.

@muriqui & plach You rock :)

Initial tests on Drupal 7.12 + WYSIWYG 7.x-2.1+13-dev + TinyMCE are running perfectly and have resolved the 5 year headache of how to handle the teaser correctly.

Please consider rolling this into the latest dev for widespread testing.

Interesting!
This does actually work. This is a pretty big decision to make so I'd like Sun's opinion as well, but it's a go from me.

Patch from comment #23 works great (Drupal 7.14 + Wysiwyg-7.x-2.x-dev 2012-04-30).
Thanks !

Any plans to roll this patch into a coming dev version of wysiwyg ?

@plach: Your patch really made my day. A big thumb up to you!

Looks like the logic here changed with #1388224: editors detach on AJAX form submission, pushed (July 1, 2012)

The previous snapshot before this change was committed is 2012-06-26 and patch #23 still cleanly applies. You can access this here or via http://drupalcode.org/project/wysiwyg.git/shortlog/refs/heads/7.x-2.x and look at the dates to find this commit.

Reroll of #23, incorporating the changes from #1388224: editors detach on AJAX form submission, but nothing else.

What about committing the patch onto the 7.x-2.x branch right after the next stable release and try to have some wider testing to see if anything breaks? If it turns out that nothing breaks we would have an approach to experiment with and we could decide in 3.x whether keep it or switch to the other.

The patch at #37 works perfectly! Thank you very much.

Committed to 7.x-2.x. ???
Succeeds the patch in #37 or #23 in the next official release?

The patch at #37 works for me too! Thank you very much!

I can also confirm that the #37 patch works with the 2012-06-26 dev version. Thanks!

Patch #37 also works for me, however I could not get it to apply to the 2012-06-26 dev version. I did get to apply 2012-07-21 dev version. I used this version because I believe it was the active head when Patch #37 was created and it should have been the version the patch was made from.

Thanks for contributing this, I've been frustrated by this for a long time and hope the patch gets committed soon. I think it will save many people from the confusion created when the exposed summary field does not have a WYSIWYG editor.

Steve

Can we commited Patch #37 to dev version or in the next Recommended releas 2.3 ?!?

I think it's time, because the creation date of this issues: March 13, 2010! ;-)
Thanks!

Here's an alternative patch which aims to minimize the API changes (as well as the amount of settings duplication).
It does this using a new summary property in the trigger object which simply holds the id of the summary element. Any time an editor is attached or detached, this property gets checked and any actions are duplicated for a separate summary editor instance.

One significant difference compared to the #37 patch is that the instances are always toggled together, with one "Disable/Enable rich-text"-link.

I don't think this should break any contrib modules, at least not if they are using wysiwygAttach and wysiwygDetach() to manipulate editor instances.

Media module embed codes break on edit in the summary when using patch #45 & CKEditor.

Steps to reproduce:

1) create a new node
2) use the wysiwyg media embed button to add an image to the summary.
3) save the node. All works well
4) edit the node

The wysiwyg editor HTML encodes the media embed tag, so if you disable rich text, instead of seeing

[[{"type":"media","view_mode":"media_preview","fid":"700","attributes":{"alt":"","class":"media-image","height":"180","typeof":"foaf:Image","width":"180"}}]]

you see

[[{"type":"media","view_mode":"media_preview","fid":"700","attributes":{"alt":"","class":"media-image","height":"180","typeof":"foaf:Image","width":"180"}}]]

I'm not sure if this is a problem with the media module or this patch. It works fine in the body field though, it's only the summary that tries to encode the embed tag.

Re #46, some changes to the media module were required, see http://drupal.org/node/1995030 . So all is good here.

#45 works well. thank you TwoD!

#45 works great. Anything stopping it from being committed.

+1 for #45 here too, tested and works for me.

#45 thanks, works great!

#45 thanks - why not commit?

#45 Awesome work! Works on drupal 7.24

Since this is an incompatibility with a core feature I think this should be bump up to a major bug, not a feature request.

I discovered a couple of annoying issues with the previous patch.
Editors did not always like being attached to an invisible field (summary) and would behave oddly (wrong widths, not fully initialized) until disabled and re-enabled for that field.
Whether an editor was enabled or not would be lost during AJAX operations such as "Add another field".

To compensate for this, I delayed the creation of the summary field instance until the field is shown, and added an internal variable to keep track of which editors have been disabled.

This also allowed me to simplify some logic in wysiwyg.js, though it is still a bit convoluted.

The patch from #55 works great. My environment: drupal 7.26, wysiwyg-7.x-2.2+29-dev

I applied #55 in 7.x-2.2+26-dev and works well.

It looks like line 139 of wysiwyg.js has changed, so the patch doesn't apply to the latest dev. I edited the patch to see if it would apply (and it did) and the patch still seems to work, but I'm not sure if the recent change to line 139 needs to be incorporated into the patch.

Hi can you please help me to apply the patch to the last dev release?
tx
Simone

I still wasn't happy with the way settings and states had to be passed around in the #55 patch, so I put some more time into this and built another patch which I've also tested with some other patches coming up.
It's not far from the #55, which worked very well for folks, and I needed to get this done fast so I've committed the below patch to 7.x-2.x.

Thanks to everyone involved for patching, reviewing, testing, and commenting!
We can finally close this for D7!

@cimo75, you don't need to do that now, just download the 7.x-2.x-dev snapshot (will be regenerated within 12hrs).

(I'll likely backport some parts of this patch for D6, but I can't guarantee the actual summary functionality will be possible there.)

Thank you so much!

generally works! but cant edit filefields on the same node.
error: An error occurred while attempting to process /file/ajax/field_bilder/und/form-WgFZwbsvB6T00xqkswTn0RKw6Sv8IjUBG-OizJYWeik: e is undefined

@caw67

It would be best to open a new issue and provide as many details as possible about the issue. For example, versions of Drupal, core File field or Media (or any other modules that you are using for the file upload), if you are running JQuery Update and what versions and finally the editor (CK, etc).

We have been using this or one of the version of the patch for years without issue.