WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 16 months ago

#30094 closed defect (bug) (wontfix)

wp.mce.views.toViews() not handling nested shortcodes

Reported by: csixty4 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.0
Component: TinyMCE Keywords:
Focuses: javascript, administration Cc:

Description

Working on a custom shortcode implementation that uses a wp.mce.View for a display in TinyMCE. Our QA tester noticed a rendering issue when there was an audio shortcode nested inside our shortcode, ex: [a][audio mp3="https://archive.org/download/jcalebgreenemp3sample/4_2nd_Perception_of_LightMoon_Mist_and_Rainbow_64kb.mp3"][/audio][/a]

This loop at the start of wp.mce.view.toViews() processes the audio shortcode first:

_.each( views, function( view, viewType ) {

Why? Some implementation detail of underscore.js I'm sure. Most likely because wp.mce.views.register() was called for the 'audio' shortcode early on, and its property was added to the views object before ours.

Further down in wp.mce.view.toViews(), this loop breaks the content into an array of "pieces" around the shortcodes:

					// Iterate through the string progressively matching views
					// and slicing the string as we go.
					while ( remaining && (result = view.toView( remaining )) ) {
						// Any text before the match becomes an unprocessed piece.
						if ( result.index ) {
							pieces.push({ content: remaining.substring( 0, result.index ) });
						}

The "piece" before the audio shortcode is the opening tag of our custom shortcode, which is now separated from its closing tag and rendered incorrectly in the editor without it (see attached).

Attachments (1)

Screen Shot 2014-10-24 at 4.29.07 PM.png (39.8 KB) - added by csixty4 5 years ago.
TinyMCE editor showing nested wp.mce.View shortcodes rendering incorrectly

Download all attachments as: .zip

Change History (10)

@csixty4
5 years ago

TinyMCE editor showing nested wp.mce.View shortcodes rendering incorrectly

#1 @azaozz
5 years ago

Yeah, nested shortcodes are "evil" :)

Don't see a straightforward way to add some sort of "priority" when registering views. Perhaps it would be nice to have something similar to the PHP filters and actions, default priority 10, plugins can choose higher or lower. Also if the [a] shortcode was registered first, we will have to ensure that the nested [audio] shortcode is parsed. Ideas for a patch welcome.

Last edited 5 years ago by azaozz (previous) (diff)

#2 @joelworsham
4 years ago

+1 for this. I'm having the same issue, and would really love to nest rendered shortcodes.

#3 @sunny_johal
4 years ago

  • Keywords needs-patch added

Hi @azaozz as the mce-views api has changed since this ticket was created what would you recommend as the best approach in order to implement nestable shortcode views in the api?

#4 @khromov
4 years ago

+1 would like to see this addressed.

#5 @iseulde
4 years ago

  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in Slack in #core-editor by westonruter. View the logs.


3 years ago

#7 @danieliser
3 years ago

I think the solution may be simple. What if you simply take a page out of the PHP do_shortcode book. The inner content of a typical shortcode is simply processed again (recurring) until no further shortcodes are detected.

Is there a way that on completion of a single view render (IE the [a] shortcode above) then the inner content should then be passed back through again. Guarantees that all rendering is done correctly and the output should perfectly match that of do_shortcode.

Also in the case of the OP's issue, an AJAX render function may go much further. I believe that that should be doable without hacks, so maybe that could be the solution here as well.

This ticket was mentioned in Slack in #core-tinymce by anteprimorachr. View the logs.


3 years ago

#9 @danielbachhuber
16 months ago

  • Keywords needs-patch removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Shortcodes are dead. Long live Gutenberg blocks!

Note: See TracTickets for help on using tickets.