Edited issue in order to get the urls to work.

Please provide a stacktrace and additional debug details. Saying that specific pull request is the culprit not only makes no sense but provides no explanation as to why the changes in that pull request introduce the issue you are reporting.

Debug system was set to Yes. Error reporting set Development. No debug stacktrace, we don't know why. Just
Error: Call to undefined method JEventDispatcher::getContent(): Call to undefined method JEventDispatcher::getContent()
PHP 7.2.19 Joomla 3.8.11 (we have also tested J 3.9.13 and same result)

How do we know it was something introduced in 3.8.11? We started with last known working version 3.8.10 and applied the patches. As soon as the patch 3.8.11 was applied we got the error. This is also support by the reference links in my previous posts.

Other users reported disabling the readmore.php plugin resolved in the problem and this also worked for us. We also diffed the code between j 3.8.10 and the patch 3.8.11. The only change that caused the error to appear was the code change in the file

libraries/src/Plugin/PluginHelper.php

Removing the code introduced in lines 262 -272 made the error message disappear, although we would recommend as solution because the code was introduced for good reason.

So it comes down to the line of code 'editor' => $this->_subject->getContent($name), in the readmore.php file. We couldn't find the getContent method in the JEventDispatcher.

Let me know if you need any more info.

With debug enabled, there should always be a stack trace available unless the error template has no conditional code for this (which I would suggest the template should fix).

TBH, the problem boils down to the editors-xtd group expecting $this->_subject to be an instance of Joomla\CMS\Editor\Editor instead of the usual JEventDispatcher.

So why would that PR have created the issue? It made it possible for the plugin helper to load the plugin classes in that group, whereas previously it couldn't.

So, basically calls similar to Joomla\CMS\Plugin\PluginHelper::importPlugin('editors-xtd') or Joomla\CMS\Plugin\PluginHelper::importPlugin('editors-xtd', $pluginName) will cause this problem. Those calls MUST be written as Joomla\CMS\Plugin\PluginHelper::importPlugin('editors-xtd', null, false) or Joomla\CMS\Plugin\PluginHelper::importPlugin('editors-xtd', $pluginName, false) (the third param is the key here, that blocks the auto instantiation of the plugin class).

This is fixed in 4.0 by using the event system properly and not misusing certain plugin groups in awkward ways (IIRC you can get into the same kind of problem in 3.x with the captcha plugins).

For 3.x, there isn't a good solution. You either hard blacklist the editors-xtd and captcha groups from auto-creation or you revert that PR, both of which I would say mask the architectural design flaws in the Joomla\CMS\Captcha\Captcha and Joomla\CMS\Editor\Editor classes with their use of plugins and doesn't do anything to fix the problem. The best fix is in all honesty finding code incorrectly calling the plugin helper for those specific groups and fixing it. And on a cursory search, there is no "wrong" code in core.

If I understand michael correctly it's a problem of the extension and can't be fixed for 3.x.

I'm closing this for now,