__group__ ticket summary owner _component _version priority severity milestone type _status workflow _created modified _description _reporter
Tickets Awaiting Review 55120 """wp_editor_settings"" filter not working for the Classic block TinyMCE settings" TinyMCE normal normal Awaiting Review defect (bug) new 2022-02-08T21:49:55Z 2022-02-08T21:49:55Z "This filter was added in the #45348 to Classic Block but I think it's not working. To run this filter we need to use return value of `array_merge` [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/script-loader.php#L517/ reference]. I double check if there is an any version of PHP could support this usage but I couldn't found: https://3v4l.org/v4YBT
You can find below my must use plugin for test, it doesn't effect any option of Classic block.
{{{#!php
'bold,italic'
];
return $settings;
}
}}}
I hope I don't miss anything 🙂
" oztaser
Tickets Awaiting Review 54109 Classic Editor - Image edit popup toolbar no longer appears when image has link TinyMCE 5.8 normal normal Awaiting Review defect (bug) new 2021-09-11T07:55:44Z 2021-09-21T13:29:02Z "After inserting an image into the Classic Editor, you can click on it and a small popup toolbar will appear with several alignment buttons and an Edit button.
Image without link, showing popup toolbar after being clicked:
[[Image(https://p377.p0.n0.cdn.getcloudapp.com/items/o0uPJNdL/c547caaf-3ab0-4d26-9f4a-f413da275bbf.png?source=viewer&v=7d5ba87b66148f1b317100ac3baa1cf0)]]
After you add a link to the image, or if you add a link while inserting the image, this popup toolbar no longer displays when clicking on the image. The popup will flash and then disappear.
Vid: https://share.getcloudapp.com/8Lu5YGzD
macOS Big Sur 11.5.2
Firefox 92.0
WP 5.8.1
TwentyTwenty
Classic Editor (No other plugins)
" ahortin
Tickets Awaiting Review 58949 Directory 'code' missing from 'wp-includes/js/tinymce/plugins' TinyMCE 6.2.2 normal normal Awaiting Review defect (bug) new 2023-08-01T01:19:15Z 2023-08-01T01:19:15Z "Directory 'code' missing from 'wp-includes/js/tinymce/plugins'
It used to be there but it's missing now - i.e. I did NOT receive an error when using the plugin 'code' for tinymce.
I do not know when it stopped to be there.
== latest WP version
yes
== steps taken to consistently reproduce the problem
If you build a text area using the following code
{{{
}}}
you will receive an error in the web development console section:
{{{
GET https://DOMAIN.COM/wp-includes/js/tinymce/plugins/code/plugin.min.js
Status 404 Not Found
}}}
== Does problem occur when all plugins deactivated and use the default theme?
N/A
== what is the expected output or result? What did you see instead?
The expected outcomes would be:
1) the direcotry and file '//DOMAIN.COM/wp-includes/js/tinymce/plugins/code/plugin.min.js'would be available
2) tinymce would show the code icon
3) no error displayed
== additional information
Not that this really matters for this, more related to wordpress version
os: alma 8.8
php: 7.4.33 AND 8.1
browser: not applicable
" jobst
Tickets Awaiting Review 57142 Fix to the deprecated code inside wp-tinymce.js TinyMCE 6.1.1 normal normal Awaiting Review defect (bug) new 2022-11-18T04:15:45Z 2022-11-18T16:54:06Z In the current version `Event.path` is used in `wp-tinymce.js` which is deprecated and need to be replaced with `Event.composedPath()` isrgrajan
Tickets Awaiting Review 59162 Link not completely deleted in Firefox TinyMCE normal normal Awaiting Review defect (bug) new 2023-08-21T16:10:46Z 2023-08-24T20:23:11Z "**Steps to reproduce**
1. Create a new page
2. Insert a classic editor block
3. Enter ""Link1"" and ""Link2"" in separate paragraphs and link them to `https://link1.tld` and `https://link2.tld`. The resulting code should look like this:
{{{
}}}
4. Click on ""Save"" to close the block and reopen it afterwards
5. Start by marking the word ""Link1"" from the back, without clicking in the word first.
6. Press the Delete key on the keyboard. The text will be deleted, but the link will remain.
7. Press the Delete key again. The empty line will be deleted and the previously not completely deleted link will be applied to the text ""Link2"". Thus, Link2 no longer points to `https://link2.tld` but `https://link1.tld`.
**Expected result**
Link is completely deleted in step 6.
**Affected browsers**
Firefox (tested in version 116 on Windows 10 and 11)
**Test environment**
WordPress 6.3 with theme Twenty Twenty-Three 1.2 on PHP 8.1, no plugins installed" dawasi
Tickets Awaiting Review 55012 TinyMCE editor not rendering correctly in visual mode using wp_editor function in a meta box on a page with the Block editor enabled in WP 5.9 TinyMCE 5.9 normal major Awaiting Review defect (bug) new 2022-01-31T17:51:40Z 2023-12-21T12:47:56Z "Using the wp_editor function on a meta box on WP 5.9 with the block editor enabled on a page results in the TinyMCE editor not rendering correctly in Visual mode.
I note that there are several prior tickets about this same issue which unfortunately seem to have been unresolved due to being unable to be reproduced consistently: [https://core.trac.wordpress.org/ticket/52133 #52133], [https://core.trac.wordpress.org/ticket/52050 #52050], [https://core.trac.wordpress.org/ticket/53644 #53644].
Sadly I am also unable to reproduce this bug consistently either, I am experiencing it on both the development version and live versions of a particular site I'm working on at the moment, prior to the 5.9 update the wp_editor had been working correctly on both of these sites. As a test I made two clean installations on another server of both 5.8 and 5.9 with no additional plugins and a simple theme with metabox added to it and the wp_editor works correctly. So there is something specific about the particular combination of code in my site that is preventing the wp_editor from working in visual mode that didn't seem to be occurring before 5.9 for some reason, even though on these simple test installations they seem to be fine.
I am able to workaround the issue by the following steps: switch to the Text view tab in the wp_editor, refresh the page and then switch back to the Visual view tab. These steps were indicated in one of the previous tickets linked above.
The following is an example of the code I am using to add the metabox with wp_editor in it:
{{{
function tools_next_steps_metabox() {
global $post;
$custom = get_post_custom( $post->ID );
$next_steps_links = isset( $custom[ 'next_steps_links' ][0] ) ? $custom[ 'next_steps_links' ][0] : '';
echo '
';
echo '
This panel allows entering of text content for the “Next Steps” stage of the tool.
';
}
add_action( 'add_meta_boxes', 'render_page_metaboxes' );
function render_page_metaboxes() {
add_meta_box( 'a_tools_next_steps_metabox', 'Next Steps', 'tools_next_steps_metabox', 'page', 'normal', 'low' );
}
}}}
I appreciate this is perhaps not the most helpful ticket but given that issue has been reported in the past there is obviously some circumstance where using metaboxes and the wp_editor on pages using the block editor results in the editor not getting activated on load when the wp_editor is in visual mode. On the pages where I have the error occurring I have tried disabling the block editor on those pages and the wp_editor works correctly when the block editor is disabled.
" rickcurran
Tickets Awaiting Review 58486 Using WordPress 5.7.8 (but also all other more recent branches) - characters are stripped through TinyMCE Copy paste from Word TinyMCE 5.7.2 normal normal Awaiting Review defect (bug) new 2023-06-08T09:44:51Z 2023-06-08T09:44:51Z "Hi
Using WordPress 5.7.8 (but also all other more recent branches) - characters are stripped through TinyMCE Copy paste from Word.
Under conditions: Bulleted list, from word, pasted, containing a dot at the end of the word.
Detailed descpription with fix here:
https://github.com/tinymce/tinymce/issues/3480
https://github.com/aautio/tinymce/commit/b5f4db5a8377d2beb9ca3a1a7164587b280acbf4
Seems implemented in TinyMCE since March 31 2021, however the update of TinyMCE editor has not yet been included in current WordPress versions.
Can this still be applied?
Kind regards,
Ralph Gortzen
Application manager Atos.net Group site.
" rgortzen
Tickets Awaiting Review 57884 [TinyMCE] class-wp-editor.php is emitting open_basedir restriction warning when using my own error handler TinyMCE 3.9 normal normal Awaiting Review defect (bug) new dev-feedback 2023-03-08T10:42:02Z 2023-03-21T16:17:44Z "My server has open basedir restrictions.
When editing a post on classical editor, on line 530, class-wp-editor checks for translations loaded for external TinyMCE 3.x plugins.
{{{
if ( @is_file( $path . 'en_dlg.js' ) ) { ..
}}}
On standard case , ""@""supress the errors as it should.
But I have, as many users, my own error handling for pushing error logs in external collector.
So ""supress errors"" @ seems to be non-effective;
and my logs are full of these :
""is_file(): open_basedir restriction in effect. File(/en_dlg.js) is not within the allowed path(s): (..) /wp/wp-includes/class-wp-editor.php"",""error_line"":530
The correct way to check a potential outside of openbasedir restriction seems to be
{{{
// Default error handler is required
set_error_handler(null);
// Clean last error info. You can do it using error_clean_last in PHP 7.
@trigger_error('__clean_error_info');
// Testing...
@file_exists($path);
// Restore previous error handler
restore_error_handler();
}}}
as to why '$path' seems to be '/' ,thus checking file at server root, I have no clue ..
" arnolp
Candidates for Closure 47218 Update TinyMCE to 5.X.X or 6.X.X TinyMCE normal normal Awaiting Review enhancement new dev-feedback 2019-05-10T17:41:21Z 2024-03-20T10:02:28Z "TinyMCE Version 5.0.5 has been released on May 9, 2019, see:
https://www.tiny.cloud/docs/release-notes/release-notes50/
https://www.tiny.cloud/docs/changelog/
Don't we want to keep it up to date?
It ''could'' break things, though, see :
https://www.tiny.cloud/docs/migration-from-4x/
related: #47205" Presskopp
Tickets with Patches 49964 Support asynchronously loading TinyMCE TinyMCE 5.0 normal normal Future Release enhancement new dev-feedback 2020-04-20T22:05:18Z 2020-08-13T14:19:40Z "In order to facilitate [https://github.com/WordPress/gutenberg/issues/21738 asynchronously loading TinyMCE in Gutenberg] we need to be able to prevent WordPress from automatically enqueueing `wp-tinymce` and injecting inline i18n initialization scripts. (There's plenty of context in the Gutenberg issue including related tickets, so I'll try not to repeat any of that here.)
I'd like to propose wrapping [https://developer.wordpress.org/reference/classes/_wp_editors/print_tinymce_scripts/ _WP_Editors#print_tinymce_scripts] in an action that Gutenberg could use for when the editor is loading." sarayourfriend
Unpatched Bugs 57995 Popup flickering in Firefox TinyMCE 6.0 normal major Future Release defect (bug) new 2023-03-28T06:16:02Z 2024-02-09T09:06:53Z "This bug is somehow related to #44911, however, 5 years after that, the bug appears in Firefox. I copy-paste here what I wrote in the forum (https://wordpress.org/support/topic/toolbar-of-tinymce-flickering-in-firefox/):
1. Begin editing a page **in the block editor**
2. Insert a Classic block (TinyMCE)
3. Mark some text
4. Turn it into a link
5. Enter a URL which is wider than the input field, e.g. `https://de.wikipedia.org/wiki/Rindfleischetikettierungs%C3%BCberwachungsaufgaben%C3%BCbertragungsgesetz`
6. Close the input field
7. Reopen the input field
8. Click on the pencil to edit it
9. Expected behaviour: Turn it into the input field again. Actual behaviour: Starts flickering and is impossible to work with.
I found the relevant code in the file `wp-include/js/tinymce/plugins/wordpress/plugin.js` in line 1127 and following, stating:
{{{
/*
* Showing a tooltip may trigger a resize event in Chromium browsers.
* That results in a flicketing inline menu; tooltips are shown on hovering over a button,
* which then hides the toolbar on resize, then it repeats as soon as the toolbar is shown again.
*/
if ( event.type === 'resize' || event.type === 'resizewindow' ) {
}}}
Funnily enough, there is a remark about this behaviour, but it concerns only Chromium. Firefox uses the event `scroll`. I tried appending it to the condition, and it really fixed the problem. However, I do not know if just appending `|| event.type === 'scroll'` does not break other things. Actually, I think that the correct solution would be like this: The current condition is about resizing. There should be another condition which caches the previous scrolling position and bails out early if the scroll position did not change altough the event is fired.
This code is present at least since WordPress 6.0 and also in 6.1.1." robehr79
Unpatched Bugs 51417 TinyMCE stripping