Link button in custom wysiwyg textarea not compatible with new jQuery

[lgedeon]

In 5.7-beta2 using a custom textarea with the wysiwyg editor, clicking the link button causes the following in the console:

wplink.js?ver=5.7-beta2-50281:172 Uncaught TypeError: Cannot read property 'selectionStart' of undefined
at Object.refresh (wplink.js?ver=5.7-beta2-50281:172)
at Object.open (wplink.js?ver=5.7-beta2-50281:145)
at qt.LinkButton.callback (quicktags.js?ver=5.7-beta2-50281:637)
at HTMLDivElement.onclick (quicktags.js?ver=5.7-beta2-50281:188)

After the link editor box pops up you are no longer able to select an existing post and you are not able to insert a link or close the box.

I was able to trace this back to wplink.js line 121 which has:

this.textarea = $( '#' + window.wpActiveEditor ).get( 0 );

This can be fixed with vanilla JS by changing it to:

this.textarea = document.getElementById( window.wpActiveEditor );

In tests on my local machine, this worked perfectly.

[lukecarbis]

@lgedeon That change seems like an easy win, thank you! Could you help me replicate the issue so that I can try implementing it? What exactly do you mean by the wysiwyg editor? (the Gutenberg editor?) and how did you add the custom textarea?

[lgedeon]

Going for the quick answer now and will try to get something better by tomorrow...

I was working with a textarea on a settings page in the admin. It then had an editor added to it. Not Gutenberg and not even the full editor from before Gutenberg, just the one that adds a few buttons above the text editor.

Sorry, I will try to provide more info soon.

[Clorith]

I had a look here, but I'm not able to replicate these errors, in a custom settings page (for simplicity sake, using the ​plugins handbook example but with a wp_editor() implementation instead of a select box.

The full code used to test can be grabbed from the following Gist ​https://gist.github.com/Clorith/f411d04237328415d2fa60f7e192c9de

I've added links both in text and visual mode without encountering the issues you are describing.

The jQuery function referenced it self is still a valid one to return the first DOM object that matches the pattern as well, so not sure if that's truly the root cause or not on your end, but I am suspecting something else may be interfering with your DOM that isn't core.

I should mention this is tested using WordPress 5.7-beta3 at this point.

[lgedeon]

@Clorith, thank you so much for creating the sample code.

Using your example, I updated line 38 to:

<?php
wp_editor( '', 'my_custom_editor_id[description]' );

Since the implementation I am debugging expects an array, it uses the square brackets for the id. The square brackets, then are the source of the error.

That of course, points to a simple work-around, but since I imagine this might be a common use-case, we might still want to update core to accommodate this or at least document that this is no longer supported.

[Clorith]

Thank you, I can then replicate the problem you are experiencing.

This isn't related to the jQuery update it self, as the behavior is also replicable on WordPress 5.5, but rather a problem in accessing arrayed results in jQuery with .get() when square brackets are used in the selector in the first place.

There are other issues as well displayed when using square brackets for the editor id, as it locks you out of the visual part of the WYSIWYG editor.

This is all expected behavior though, as the ​documentation for `wp_editor` explicitly notes that you should not be using square brackets in the ID.

I'm closing the ticket then, as this isn't an unexpected scenario, but further discussions about it can still happen, it's just to keep the workflows sane around releases :)