Gary Jones

Thanks @alithewpdev, the stack traces have made the cause clear. This is a stale-JS issue on the Kinsta side, not a code defect in 4.0.x.

The first error, Uncaught TypeError: $co.attr(…).appendTo(…).suggest is not a function at co-authors-plus.js:174, is the legacy admin script trying to call .suggest(). We removed that call in 4.0.0 (commit 6d1cf8b, where we replaced the deprecated WordPress suggest library with jQuery UI autocomplete). The function name in your stack trace, coauthors_create_autosuggest, was also renamed to coauthors_create_autocompletein the same 4.0.0 change. So the JavaScript file your browser is executing is from a pre-4.0.0 version of Co-Authors Plus, even though your installed plugin is 4.0.x.

The second React error, Cannot read properties of undefined (reading 'PluginDocumentSettingPanel')at index.js, is consistent with the same problem: the bundled editor script being served is also from an older build that doesn’t have the fallback for the PluginDocumentSettingPanel API move (it shifted from wp.editPost to wp.editor in WP 6.6).

Kinsta’s CDN, like Cloudflare, will often cache static assets while ignoring query-string cache busters such as ?ver=4.0.x. Once the CDN edge has cached the pre-4.0 file, a plugin upgrade alone won’t refresh it.

Two things to try, in this order:

1. Clear Kinsta’s CDN cache and the site’s object cache. From MyKinsta, go to your site → Cache → Clear Cache, and also clear the object cache. (We had another report this week that resolved entirely after clearing Cloudflare’s cache.)
2. Hard-refresh the browser (Cmd+Shift+R on macOS / Ctrl+F5 on Windows) so it doesn’t reuse a stale local copy either.

If the errors persist after that, please share a fresh console capture and we’ll dig further. I’d be especially interested in whether co-authors-plus.js is still serving from coauthors_create_autosuggest, or whether it now shows coauthors_create_autocomplete (which is the correct name in 4.0+).

The error message “The ‘plugin-coauthors-document-setting’ plugin has encountered an error and cannot be rendered”is Gutenberg’s standard error boundary message when a registerPlugin panel throws during render. So this is our React component (src/components/co-authors/index.jsx, registered via src/index.js) crashing on mount.

@alithewpdev Please can you share your WP version, the full console error with stack trace, the active plugins, and whether your site has a CDN and/or object cache?

Thanks, that narrows it down considerably. If switching to Twenty Twenty-Five didn’t fix it, the conflict is on the plugin side rather than the theme side. Three things would help, and none of them require deactivating anything on your live site:

1. The list of active plugins. You can grab it from Plugins → Installed Plugins, or, if you have WP-CLI access, wp plugin list --status=active --field=name. With that I can check whether anything obvious filters the REST author lookup or post-save flow.
2. Whether the site uses a persistent object cache. Redis, Memcached, or any caching plugin in that category. You can check from Tools → Site Health → Info → Constants, or via WP-CLI with wp eval 'echo wp_using_ext_object_cache() ? "yes" : "no";'. This matters because the post_author re-sync happens immediately before the REST response is sent, and certain object caches can serve a stale get_post()to the code that does the sync.
3. If you have access to a staging copy, or a tool like the Health Check & Troubleshooting plugin’s Troubleshooting Mode, you can deactivate other plugins only for your own admin session without affecting other visitors at all. That would let you run the bisect safely on production. Activating Troubleshooting Mode → disable all plugins → reactivate Co-Authors Plus only → repeat the publish flow. If that fixes it, you can then re-enable plugins one by one in the same Troubleshooting session to find the culprit.

Quick Edit remains a safe workaround in the meantime.

Thanks for the report @cmurphy124, and especially for capturing the console error — that narrows it down considerably.

This looks like a different issue from a couple of other reports we’ve had this week, so I’d like to track it separately. To do that, a few things would help:

1. The full stack trace from the browser console (expand the error so we can see the file and line number it was thrown from). The minified b.split reference on its own is hard to map back to source.
2. The response body from the network request to /wp-json/coauthors/v1/search/?q=… when you try to search. If any rows in that response are missing a userNicename, id, or have null where a string is expected, that would explain the throw.
3. Whether the same site reproduces the error on a single-site WordPress install, or only on multisite. If you are able to test on a non-multisite staging environment, that would help isolate it.
4. Whether you have any plugins that filter coAuthors.formatAuthorData.label, or any custom code that filters the search endpoint response.

You mentioned this first appeared after upgrading to 4.0.1, which lines up with the editor panel rewrite in 4.0. Once I have the stack trace and a sample response, I should be able to point at the cause and open a tracking issue.

Which version of Co-Authors Plus are you using / did you first notice the issue? This will help to narrow down which change it might have been.

Also, what theme are you using and is the byline rendered by a block/template or by classic theme code?

Hi @bradley2083,

Thanks for the clear reproduction — you’ve spotted a real bug in Co-Authors Plus.

CAP’s filter on get_the_archive_title was rebuilding the author archive title from scratch with a hard-coded “Author: ” prefix, which overrode the Archive Title block’s Show archive type in title toggle. Untoggling it correctly told core to drop the prefix, but CAP put it straight back.

A fix is up for review here: https://github.com/Automattic/co-authors-plus/pull/1259

It changes the filter to reuse the prefix that core has already resolved, so the block’s toggle is honoured for both registered users and guest authors. Once it’s merged it will go out in the next CAP release.

Thank you – also reported in https://github.com/Automattic/co-authors-plus/issues/1252 and resolved in https://github.com/Automattic/co-authors-plus/issues/1253