Issue

The command php artisan clear-compiled artisan command is run (on the command line or programmatically) it flushes the package manifest.

This is an issue since the licensed packages are loaded based on the package manifest and if that file is cleared, it will attempt to load all installed packages, including custom ones, which triggers a fatal error.

Reproduction Steps

1. On the most recent build with all enterprise and custom packages installed, run the php artisan license:update {licenseFile} command and ensure it runs successfully
2. Attempt to run the upgrade migrations (be sure they have not been run yet) with php artisan upgrade
3. Notice the failure: {"errors":{"username":["cURL error 3: URL rejected: No host part in the URL (see https:\/\/curl.haxx.se\/libcurl\/c\/libcurl-errors.html) for \/api\/1.0\/\/integratingpm3onpm4\/user?username=admin"]}}

This happens because one of the custom packages has a UserObserver listening for user activities and is triggered by one of the upgrade migrations updating user information. The UserObserver looks for specific environment variables to be set and if they’re not found, it calls die() which immediately kills the process.

The greater problem is that the custom package’s service provider was being loaded in the first place. There are two programmatic calls to the clear-compiled artisan command, one in an upgrade migration and one in package-cdata.

Solution

Create a customized version of the php artisan clear-compiled command programmatically and run php artisan package:discover to ensure it is rebuilt before continuing.

Listen for clear-compiled and optimize:clear commands and return package:discover

How to Test

• Run through the replication steps (be sure the upgrade migrations are reset) and ensure they are successful.
• Run the php artisan clear-compiled command and check through the bootstrap/cache/packages.php file to ensure it contains only licensed packages.

Related Tickets & Packages

• FOUR-12669

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.