Most of them seemed obvious on code review. I was a little unsure about the changes in /installation/ but a test install worked fine AND the integration tests all pass

still seem to be about 50% of the instances still to resolve

Actually no. This leaves only the definitions of the constants, the ones in FormBehaviorTrait and the basepath in the View class. The only one without a solution is the FormBehaviorTrait, although the solution here is rather simple: Drop support for the old component structure and then you don't need these calls at all.

What about third party extensions? I have one instance of JPATH_COMPONENT_ADMINISTRATOR that I can easily change.

This PR removes those usages almost everywhere.

I agree with @ceford and why not removing them everywhere? Counting 42 findings before this PR and applying this PR 17 findings are removed 👍

grep -Ern --include='*.php' 'JPATH_COMPONENT(_(SITE|ADMINISTRATOR))?' .

Is it also possible to replace the remaining 25?

./libraries/src/MVC/Controller/BaseController.php:288:        $basePath = \array_key_exists('base_path', $config) ? $config['base_path'] : JPATH_COMPONENT;
./libraries/src/MVC/Controller/BaseController.php:425:            $this->basePath = JPATH_COMPONENT;
./libraries/src/MVC/Model/FormBehaviorTrait.php:77:        Form::addFormPath(JPATH_COMPONENT . '/forms');
./libraries/src/MVC/Model/FormBehaviorTrait.php:78:        Form::addFormPath(JPATH_COMPONENT . '/models/forms');
./libraries/src/MVC/Model/FormBehaviorTrait.php:79:        Form::addFieldPath(JPATH_COMPONENT . '/models/fields');
./libraries/src/MVC/Model/FormBehaviorTrait.php:80:        Form::addFormPath(JPATH_COMPONENT . '/model/form');
./libraries/src/MVC/Model/FormBehaviorTrait.php:81:        Form::addFieldPath(JPATH_COMPONENT . '/model/field');
./libraries/src/MVC/Model/BaseDatabaseModel.php:118:        } elseif (\defined('JPATH_COMPONENT_ADMINISTRATOR')) {
./libraries/src/MVC/View/HtmlView.php:132:            $this->_basePath = JPATH_COMPONENT;
./libraries/src/MVC/View/JsonView.php:80:            $this->_basePath = JPATH_COMPONENT;
./libraries/src/MVC/View/ListView.php:180:        \JLoader::register($helperClass, JPATH_COMPONENT . '/helpers/' . $componentName . '.php');
./libraries/src/Component/ComponentHelper.php:314:        if (!\defined('JPATH_COMPONENT')) {
./libraries/src/Component/ComponentHelper.php:326:            \define('JPATH_COMPONENT', JPATH_BASE . '/components/' . $option);
./libraries/src/Component/ComponentHelper.php:329:        if (!\defined('JPATH_COMPONENT_SITE')) {
./libraries/src/Component/ComponentHelper.php:339:            \define('JPATH_COMPONENT_SITE', JPATH_SITE . '/components/' . $option);
./libraries/src/Component/ComponentHelper.php:342:        if (!\defined('JPATH_COMPONENT_ADMINISTRATOR')) {
./libraries/src/Component/ComponentHelper.php:352:            \define('JPATH_COMPONENT_ADMINISTRATOR', JPATH_ADMINISTRATOR . '/components/' . $option);
./installation/src/Application/CliInstallationApplication.php:124:        \define('JPATH_COMPONENT', JPATH_BASE);
./installation/src/Application/CliInstallationApplication.php:125:        \define('JPATH_COMPONENT_SITE', JPATH_SITE);
./installation/src/Application/CliInstallationApplication.php:126:        \define('JPATH_COMPONENT_ADMINISTRATOR', JPATH_ADMINISTRATOR);
./installation/src/Application/InstallationApplication.php:191:        \define('JPATH_COMPONENT', JPATH_BASE);
./installation/src/Application/InstallationApplication.php:192:        \define('JPATH_COMPONENT_SITE', JPATH_SITE);
./installation/src/Application/InstallationApplication.php:193:        \define('JPATH_COMPONENT_ADMINISTRATOR', JPATH_ADMINISTRATOR);
./administrator/components/com_installer/src/Model/UpdateModel.php:532:        Form::addFormPath(JPATH_COMPONENT . '/models/forms');
./administrator/components/com_installer/src/Model/UpdateModel.php:533:        Form::addFieldPath(JPATH_COMPONENT . '/models/fields');

We don't have a solution for FormBehaviorTrait currently. The rest is either the define() call, which we can't remove in 5.4 (which is why there is #45250) or it is code which we currently can't change because of b/c considerations.

@Hackwar Thank you very much for your detailed answer, now we can understand it correctly, thank you,

I did a quick test of simply adding a new article and without the patch applied I could open the new article page but as soon as I applied the patch clicking new article caused this error

0 Call to undefined method Joomla\Component\Content\Administrator\Model\ArticleModel::shouldUseExceptions()

reverting and I am back to being able to add them

I have tested this item ✅ successfully on 8fbd1e5

did what it said on the tin

I have tested this item ✅ successfully on 8fbd1e5

Tested on Alpha2 and failed but passes using nightly.

Tested articles,users, banners, contacts, categories, tags all worked with fail on nightly.

RTC

confused as it failed for two people and then worked for those same people without any changes to this pr

I did a quick test of simply adding a new article and without the patch applied I could open the new article page but as soon as I applied the patch clicking new article caused this error

0 Call to undefined method Joomla\Component\Content\Administrator\Model\ArticleModel::shouldUseExceptions()

reverting and I am back to being able to add them

Tested on Alpha2 and failed but passes using nightly.

I think that could be because PR #44098 was not merged yet in Alpha 2. At least that's the only relevant change in 5.4-dev between Alpha 2 and latest nightly build. No idea though why that should affect this PR.

@softforge @Bodge-IT Can you confirm that, your failed test was with Alpha 2 or any other 5.4-dev from before July 28, and your successful test with latest nightly?

I did a quick test of simply adding a new article and without the patch applied I could open the new article page but as soon as I applied the patch clicking new article caused this error
0 Call to undefined method Joomla\Component\Content\Administrator\Model\ArticleModel::shouldUseExceptions()
reverting and I am back to being able to add them

Tested on Alpha2 and failed but passes using nightly.

I think that could be because PR #44098 was not merged yet in Alpha 2. At least that's the only relevant change in 5.4-dev between Alpha 2 and latest nightly build. No idea though why that should affect this PR.

@softforge @Bodge-IT Can you confirm that, your failed test was with Alpha 2 or any other 5.4-dev from before July 28, and your successful test with latest nightly?

Tests on alpha2 failed:
An error has occurred.
0 Call to undefined method Joomla\Component\Content\Administrator\Model\ArticleModel::shouldUseExceptions()
Nightlies no problem, will check another 5.4.

EDIT:
Test on 5.4alpha1 gets the same error just opening article

@Bodge-IT @softforge P.S.: How did you apply the patch? With patchtester?

I think I have the explanation.

File "libraries/src/MVC/Model/BaseDatabaseModel.php" was by PR #44098 to use a new "shouldUseExceptions" method added by that PR. That PR was merged after Alpha 2.

As the current PR #45249 was updated to the base branch, it also includes that change.

Now patchtester comes and applies the whole file.

If you do that on an Alpha 2 or older where the "shouldUseExceptions" does not exist, you get that error.

It would not happen if using the package created by Drone for the PR or working on a development environment and check out this PR instead of using patchtester.