silverstripe-framework/docs/en/04_Changelogs/beta/4.10.0-beta1.md

# 4.10.0 beta1

## Overview

- [Stable module forcing installation of unstable framework](#unstable-framework)
- [PHPUnit 9.5 and PHP 8.0 official support](#php8)
- [Dropping support for PHP 7.1 and PHP 7.2](#phpeol)
- [Features and enhancements](#features-and-enhancements)
- [Bugfixes](#bugfixes)

## Stable module forcing installation of unstable framework{#unstable-framework}

If you recently updated your project's `composer.json` file, you may have accidentally got an unstable version of `silverstripe/framework`.

In the process of publishing Silverstripe CMS Recipe 4.10.0-beta1, we ended up releasing a few modules as "stable" but with a requirement on the unstable `silverstripe/framework` 4.10. For most projects, this won't be a problem if your `composer.json` file uses the `"prefer-stable": true` flag. However, if you explicitly require the very latest version of a module that depends on `silverstripe/framework ^4.10` then composer may install an unstable version of `silverstripe/framework`.

To double check what version of `silverstripe/framework` is installed on your project, run this command `composer show silverstripe/framework`. This will show the currently installed version of `silverstripe/framework`. If it comes out with `4.10.0-beta1` or `4.x-dev` or `4.10-x-dev`, you are running an unreleased version.

To remedy this problem you can explicitly require `"silverstripe/framework": "~4.9.0"` in your composer file and run `composer update -W`. If you get conflicts, you might need to loosen some constraints to get older versions of some modules. Once you are ready to upgrade to `silverstripe/framework` 4.10.0 stable then you'll need to remove that explicit constraint.

Alternatively, if you want to be 100% sure that you never run any unstable dependencies, you can set the `minimum-stability` in your composer file to `stable`. Run `composer update -W` to detect any unstable requirements.

### Why did this happen?

In the process of getting all our modules compatible with PHPUnit 9.5, we had to force them to use `silverstripe/framework` 4.10 or greater. We ended up tagging a few module as stable earlier than we normally would to get our CI green. We didn't fully appreciate the nuances of composer's `prefer-stable` setting when we made this decision. We apologise for any inconveniences.

## PHPUnit 9.5 and PHP 8.0 official support{#php8}

Previous Silverstripe CMS Recipe releases could be run against PHP 8.0. However, the Silverstripe CMS Recipe 4.10.0 is the first release to officially support PHP 8.0. 

The major road block to official PHP 8.0 support was our reliance on a deprecated version of PHPUnit. Adding support for PHPUnit 9.5 removed this road block. All core module tests have been rewritten to run with PHPUnit 9.5.

### What about my project test suite?

Silverstripe CMS Recipe 4.10.0 retains support for the `sminnee/phpunit` fork of PHPUnit 5.7. So your project's tests can still be run without modification ... as long as you are not using PHP 8.0. If you want your own tests to run with PHP 8.0, then you have have to upgrade to PHPUnit 9.5 and update your tests to be compatible with the latest PHPUnit API.

We'll be providing guidance on how to transition to PHPUnit 9.5 closer to the release.

## Dropping support for PHP 7.1 and PHP 7.2{#phpeol}

We've recently updated our [PHP support policy](/Getting_Started/Server_Requirements#php). The immediate affects of this changes are:

- The Silverstripe CMS Recipe release 4.10.0 drops support for PHP 7.1 and PHP 7.2. Those two PHP releases have been end-of-life for several years now and continued support would detract effort from more valuable work.
- The 4.11 minor release will drop support for PHP 7.3 later this year.
- We expect to drop support for PHP 7 altogether around January 2023.

## Features and enhancements {#features-and-enhancements}

### New `SS_TEMP_PATH` environment variable

This release adds support for a new `SS_TEMP_PATH` environment variable, which allows developers to control where a series of “temporary” files are created. These include [Manifests](/developer_guides/execution_pipeline/manifests), [Object Caching](/developer_guides/performance/caching) and [Partial Template Caching](/developer_guides/templates/partial_template_caching).

The environment variable can be set to either an absolute path which must have a leading `/` (e.g. `SS_TEMP_PATH='/tmp/silverstripe/cachedir'`), or a path relative to the project root (e.g. `SS_TEMP_PATH='silverstripe-cache'`). See the [environment management](/getting_started/environment_management) section for more information.

**Please note:** setting this environment variable will impact both requests served by a webserver (i.e. a typical website pageview) and command-line execution. If your webserver user and command-line user are different, or have different filesystem permissions, you may encounter problems when using this setting.

The new `SS_TEMP_PATH` environment variable replaces the similarly-named `TEMP_PATH` environment variable, which only ever offered partial support for adjusting the temporary files' location. This is because setting a `TEMP_PATH` _environment variable_ would affect [Injector](/developer_guides/extending/injector) service definitions, but would **not** affect code that referenced the `TEMP_PATH` _PHP constant_. The confusion with both environment variables and PHP constants having the same name is why the environment variable has been renamed and prefixed with `SS_`, in-keeping with other environment variables.

The functionality of the `TEMP_PATH` and `TEMP_FOLDER` PHP constants remains unchanged.

## Bugfixes {#bugfixes}

This release includes a number of bug fixes to improve a broad range of areas. Check the change logs for full details of these fixes split by module. Thank you to the community members that helped contribute these fixes as part of the release!


<!--- Changes below this line will be automatically regenerated -->

<!--- Changes above this line will be automatically regenerated -->