CMSB v3.71 Released (Jun 18) -Help Tooltips & Upload Features

Like the new features, however, I have a minor issue when updating a project. The composer.lock file is not included with the download. This causes an issue if you run composer install.

Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`.
- Required package "guzzlehttp/guzzle" is not present in the lock file.
- Required package "league/oauth2-client" is not present in the lock file.
- Required package "league/oauth2-google" is not present in the lock file.
- Required package "firebase/php-jwt" is not present in the lock file.
This usually happens when composer files are incorrectly merged or the composer.json file is manually edited.
Read more about correctly resolving merge conflicts https://getcomposer.org/doc/articles/resolving-merge-conflicts.md
and prefer using the "require" command over editing the composer.json file directly https://getcomposer.org/doc/03-cli.md#require-r
Script cd www/cmsb && composer install && echo 'successfully installed cmsb' handling the doCmsb event returned with error code 4
Script @doCmsb was called via post-install-cmd

The composer.lock file should be included with the download.

Here is the recommened method for handling mutiple composer projects. CMSB is a sub project to my project with its own composer.json file. 

When managing Composer dependencies for a project that is included in another Composer project, it's essential to ensure that dependencies are handled efficiently to avoid conflicts and ensure smooth integration. Here are some recommended methods to handle this scenario:

### 1. Use `composer.json` for Each Project

Each project should have its own `composer.json` file that lists its specific dependencies. This allows each project to declare its dependencies independently.

### 2. Rely on Composer's Dependency Resolution

Composer is designed to handle complex dependency trees. When you include a project as a dependency in another project, Composer will attempt to resolve all dependencies to their compatible versions. Ensure that the dependencies are correctly specified with version constraints in the `composer.json` files.

### 3. Use Semantic Versioning

Ensure that all projects follow semantic versioning (semver) for their dependencies. This helps Composer determine compatible versions and resolve conflicts. Semantic versioning uses a three-part version number: MAJOR.MINOR.PATCH.

- **MAJOR** version when you make incompatible API changes,
- **MINOR** version when you add functionality in a backward-compatible manner, and
- **PATCH** version when you make backward-compatible bug fixes.

### 4. Use `composer.lock` Files

Commit the `composer.lock` files to your version control system. The `composer.lock` file ensures that the exact versions of dependencies are installed, providing consistency across different environments.

### 5. Prefer Using `composer require`

When adding dependencies, use `composer require` instead of manually editing the `composer.json` file. This command automatically determines the appropriate version constraints based on the current versions available and any existing constraints.

### 6. Run `composer update` Carefully

Be cautious when running `composer update`. This command updates all dependencies to their latest versions within the specified constraints, which might introduce breaking changes. Instead, use `composer install` to install the dependencies as specified in the `composer.lock` file.

### 7. Use Version Constraints

Specify version constraints in your `composer.json` file to avoid unwanted updates. For example:
- `"package/name": "^1.2"` allows updates for all minor and patch versions within the 1.x range but not to 2.x.
- `"package/name": "~1.2.3"` allows updates for patch versions but not minor or major versions.

### 8. Utilize `conflict` and `provide` Sections

Use the `conflict` and `provide` sections in `composer.json` to explicitly declare incompatible versions or alternatives. This helps Composer resolve conflicts more effectively.

```json
{
"conflict": {
"vendor/package": ">=2.0"
},
"provide": {
"vendor/alternative-package": "1.0.0"
}
}
```

### 9. Check for Compatibility

Periodically run `composer check-platform-reqs` to ensure that all dependencies are compatible with your PHP version and extensions.

### Example of Handling Dependencies

Consider a main project and a subproject, each with its own `composer.json`:

**Main Project (`main/composer.json`):**
```json
{
"require": {
"subproject/package": "^1.0",
"another/dependency": "^2.0"
}
}
```

**Subproject (`subproject/composer.json`):**
```json
{
"require": {
"subdependency/package": "^3.0"
}
}
```

When you run `composer install` in the main project, Composer will resolve the dependencies for both the main project and the subproject, ensuring compatibility and preventing conflicts.

By following these methods, you can efficiently manage Composer dependencies in complex projects and ensure a smooth integration process.

Hi Jeff, 

You're completely right, but unfortunately, we need to support some additional use cases beyond what that document considers.  

Most users don't use composer at all and just upload the files, while others add custom packages and we don't want to overwrite their composer files on upgrade.  

What we could do for the next release is bundle the files as composer.json.default and composer.lock.default.  Then you could add a script section to your parent composer.json to rename those files if they're present, or maybe create symlinks from composer.json to composer.json.default.

Again, we're slowly migrating to Composer, and once you can install directly from Composer none of this is going to be an issue.  I'm cautious about spending too much time on a partial solution when it's all going to change anyway.  It's great if it works, but we're not officially supporting composer yet.  

All the same, I hope that helps and appreciate the feedback.  It lets us consider how to include support for your configuration in future builds.  Thanks!

If others are not following best practices and modifying your composer file, they really need to rethink their approach. Forcing those who do follow best practices to NOT follow them is just wrong.

My 2 cents worth.

I believe you should follow best practices, and bring those who don’t do so, around instead of the other way around.

Hi Jeff, 

The best practice of including a composer.lock file is for when you don't include a /vendor/ folder, as we are. Because we're including /vendor/ in our distribution, running composer install won't actually do anything at all, so it's redundant at this point.

There will be more Composer integration in future, but it's probably best to just ignore it for now. It's just how we're building the software behind the scenes.

Jeff, 

Maybe let's back up here.  Beyond best practices, is there a specific problem you're trying to solve?  Is there something about the current setup that isn't working with your configuration?  e.g., conflicts between packages, etc?  

Yes, a conflict existed. I use several symphony packages and PHP 8.3. Specifically, the symphony/polyfill, a dependency of other packages, was conflicting. My composer file calls your composer file using install and update hooks.. Without the composer.lock file, composer threw an error. 

I had to generate a composer.lock file for CMSB using composer update, which updates your vendor files and resolves the conflict. If the lock file had been there, that would not have been necessary. My vendor directory is separate from yours as per best practices.

I am of the opinion, if you are going to use composer for what is essentially a subproject for everyone who does use composr, then you should follow recommended standards and best practices.

EDIT:

We can’t necessarily just drop a new version of CMSB on top of an older one. Plugin schemas, settings file, uploads and media files and directories need to be preserved. I use nodejs scripts to automate the process of updating CMSB.

I have 40 clients using one version of CMSB or another from 3.53 to 3.69. Whenever, they have a change, I take the opportunity to update CMSB and their version of PHP. 

Recently I had to migrate my VPS fron Cloudlinux 7 with cpanel to cloundlinix 9 due to End of Life at the end of June. This also provided the opportunity to drop EOL PHP versions prior to 7.3.

I also use cypress.io to do complete e2e integration testing so all updates can be fully tested prior to pushing to the server. Every page is tested fo ensure no php errors, html-validated and ally for accessibility. I also use it to test Basic operation of CMSB when new versions come out.

Hi Jeff, 

Ok, glad to hear it's working now, and thanks for your feedback!

Cheers