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]

Update: Now that I have time to comprehend the question :)

I spotted this while using textarea created by wp_editor() with quicktags on a settings page and then clicking the "link" button/quicktag.

[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 :)