Brian Alexander

The Safari 18.0 workaround has been officially released in the plugin directory: https://www.ads-software.com/plugins/classic-editor/.

Thank you, everyone, for your testing! I’ll mark this topic resolved.

The Ned Flanders quote is quite appropriate! Are you able to change the theme or spin up a copy of the site in a staging environment? Are there any other sites with the same host or client that this happens to?

We’ll leave this topic open for more reproduction testing, and perhaps someone else with the same issue may discover additional info to share.

Gotcha. Hopefully the other plugins’ authors can extend backward compatibility support for the classic editor ???? I’ll close this topic for now.

Yes, those options are only available when the plugin is active. If saving with those settings doesn’t subsequently resolve the issues with the other plugins, then unfortunately my idea of the workaround doesn’t pan out ??. It will be up to those plugin authors to resolve the conflict when the old editor is enabled. It was worth a try!

Hi, all ???? As discussed in the related Trac issue, a workaround for this issue has been added to the plugin, and it would be great if you could help by testing to confirm it works with Safari 18.0 (and perhaps a confidence check with other browsers under macOS Sequoia). Please share your results on the issue in Github ????

You can test the fix by downloading a zip of trunk and updating locally, or directly in the browser using this Playground test link. Thanks!

Hmmm, Twenty Eleven doesn’t have a template named “Full Width” (Github repository search). The Classic Editor enables the old editing experience, but doesn’t change how classic themes expose templates (e.g. through the Template Name: file header).

As this doesn’t appear to be related to the Classic Editor plugin itself, I’ll close this topic for now. I would recommend searching the Twenty Eleven support forums if your issue relates to a customization of the theme (such as adding a new page template file).

Hi, @healthmanifested ???? The Classic Editor plugin re-enables a built-in core feature of WordPress, so as @jordesign noted, it would be up to those plugins to ensure compatibility (in this case, backward compatibility with WordPress’s classic editor). From a technical standpoint, the plugin doesn’t add this functionality, but turns it on again for those who prefer the old editing experience.

As this plugin should only affect the post/page editor, it may be possible for the other plugins to disable the classic editor when modifying post types dedicated to those plugins (conditionally reversing Classic Editor from setting the old editor as default).

Possible workaround?

While waiting for an update from the other plugins’ authors, if the errors you’ve experienced are occurring only when you access their “post” edit screens (but not on, say, the WP admin dashboard), then you could try swapping the plugin’s default settings for “default editor” and allowing editor switching:

This would prevent Classic Editor from forcing the old editor to load when modifying those plugins’ post types, and then on normal posts/pages you could “switch” to the classic editor on a per-post basis.

Hi, @guyhaines ???? The visual link inserter works for me as well, on macOS Sonoma in Safari and Chrome (here’s a quick Playground test link for Classic Editor). Could you share what OS/browser you’re having trouble with, and whether you’ve tried other combinations? Thanks!

Hi, @leprechaun999 ????

From what I can gather from this thread, it sounds like you had applied customizations to the plugin (e.g. modifying the file /wp-content/plugins/classic-editor/classic-editor.php). Unfortunately, if the plugin file still identified itself as the official Classic Editor plugin, it would have been included in a plugin update, and overwritten by the latest official files.

I didn’t see mention of this earlier, but if you have a website backup from before the update occurred (it could have been from years before), then you might be able to recover your modified plugin file(s) from that. If you are able to locate the old files, then I would suggest changing the directory name and plugin’s header to avoid a potential match with the official plugin in the future.

I’ll close this thread as this situation relates to customizations of the plugin (that sadly we can’t help with), but I encourage you to reach out in the Everything else WordPress forum if you need assistance with personal customizations to an official plugin going forward.

Hi, @narolles ???? The Classic Editor plugin enables a built-in core feature of WordPress, so it would be up to Elementor to ensure compatibility (in this case, backward compatibility with the classic editor). I would suggest reaching out to Elementor Support for assistance.

Regarding performance, this plugin should only affect the post/page editor, restoring the old way of editing content, and not impact WP admin in general. As the plugin restores the (somewhat oldish) TinyMCE-based classic editor, you might explore shifting to blocks to manage content, which might feel more performant for the editing experience.

Hi, @kt77 ????

Yes, the plugin is compatible with PHP 8.2+. In fact, you can test it directly against a specific PHP version via the “Live Preview” button on the plugin page, which defaults to PHP 8.3. (This in-browser WordPress demo magic is achieved via WordPress Playground.)

Hi, @satimis ???? Are you using a specific theme that includes that template, or is that a custom template created in the site editor?

Gotcha — The template can be accessed from that same core/edit-site store, and checking the post ID will return the template’s slug (in format theme-slug//template-name). For instance, with the TT4 theme:

> wp.data.select('core/edit-site').getEditedPostId();
// Blog Home template
"twentytwentyfour//home"
// Single Posts template
"twentytwentyfour//single"
// Pages template
"twentytwentyfour//page"

Does that help?

If clearing the queue didn’t help, then I’d recommend posting your issue in WP Mail SMTP’s support forum, where you’re likely to get more knowledgable support. Let them know what the error is, and you’ve tried so far (e.g. the scheduler log info seems it would be helpful). It’s clear that the plugin is somehow involved in this, and I’m sure the plugin authors will be able to figure something out.

I agree that those server log entries don’t appear to be related to the upload issue.

Hi, @trutherone ????

I agree that the most reliable (and safest) way to modify the look and feel of the login page is to apply customizations via CSS/JS with the login_enqueue_scripts hook, as @bcworkz shared above. 2FA plugins will likely assume use of the standard login form and flow, so an alternative page/plugin solution may require special integration (or customization) with other login-assist plugins.

To be clear, are you able to set up the site’s login flow using the standard login page, including the 2FA requirement?