Various tweaks to allow the scripts to pass the actionlint and shellcheck checks.

... in anticipation of PRs 924 and 916.

Remove the condition containing a hard-coded repository name in favour of a more generic condition which should safeguard that the cron job doesn't run on forks just the same.

... to make it more straight-forward to see under what license the software is distributed.

Add `display_startup_errors=On` as per the current recommendation from PHPUnit.

Ref: sebastianbergmann/phpunit-documentation-english@b3b159c

…sible()

Since PHP 8.1, calling the `Reflection*::setAccessible()` methods is no longer necessary as reflected properties/methods/etc will always be accessible.
However, the method calls are still needed for PHP < 8.1.

As of PHP 8.5, calling the `Reflection*::setAccessible()` methods is now formally deprecated and will yield a deprecation notice, which will fail test runs.
As of PHP 9.0, the `setAccessible()` method(s) will be removed.

With the latter in mind, this commit prevents the deprecation notice by making the calls to `setAccessible()` conditional.

Silencing the deprecation would mean, this would need to be "fixed" again come PHP 9.0, while the current solution should be stable, including for PHP 9.0.

Ref: https://wiki.php.net/rfc/deprecations_php_8_5#extreflection_deprecations

Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4 to 5.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](actions/download-artifact@v4...v5)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 5.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v4...v5)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

`curl_close` is deprecated in PHP 8.5+, and hasn't been doing anything since PHP 8.0, when handles were switched from `resource` to `object`.

To prevent deprecation warnings it should therefore be called on older versions of PHP only, where handles are `resource`s.

See https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_no-op_functions_from_the_resource_to_object_conversion.

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5 to 6.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](actions/setup-python@v5...v6)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-version: '6'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

... to a PHP 8.5 compatible version.

Ref: https://github.com/Yoast/PHPUnit-Polyfills/releases/tag/2.0.5

---

**Mind**: this will need to be included in any further 2.0.x releases, but when backporting, the version needed should be `^1.1.5`.

…tices

Fixes deprecation notices which occur if `$this->scheme` is `null`.

Fixed now via some extra defensive coding.

This change is already covered via the existing tests.

Ref: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_using_values_null_as_an_array_offset_and_when_calling_array_key_exists

…recation notice

Fixes deprecation notices which occur if `$offset` is `null`.

Fixed now via some extra defensive coding.

This change is already covered via the existing tests.

Ref: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_using_values_null_as_an_array_offset_and_when_calling_array_key_exists

…g null as an array offset" deprecation notices

Fixes deprecation notices which occur if `$offset` is `null`.

Fixed now via some extra defensive coding.

This change is already covered via the existing tests.

Ref: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_using_values_null_as_an_array_offset_and_when_calling_array_key_exists

The `roave/security-advisories` package was an inventive method to block installation of known insecure versions of other dependencies (via a `conflict` annotation).

As of Composer 2.9, using the `roave/security-advisories` package for this purpose is no longer needed as Composer will now natively block installation of known insecure versions of dependencies.

And while not all contributors to this repo may be using Composer 2.9+ (yet), Composer 2.9+ **_will_** be used in CI and CI failing on Composer blocking an insecure dependency offers the same level of protection as the package previously offered.

Refs:
* https://blog.packagist.com/composer-2-9/
* https://github.com/composer/composer/releases/tag/2.9.0

The tests for expired or revoked SSL certificates were failing for both Curl and
FsockOpen because the test site we had been using has changed
(https://testssl-expire.disig.sk/index.en.html).

This commit switches the test site to use expired/revoked.badssl.com,
which is more of an industry standard.

The exception message to expect needed to be changed as well to make
the expired test pass.

The revoked test has been set to be skipped, as it turns out that
revocation checking is disabled by default for PHP's cURL.

See #966

The tests for the `FilteredIterator::__construct()` method were failing on PHP 8.5 as we were explicitly testing the class for accepting objects.

While this _is_ still supported on PHP 8.5, it is deprecated and results in the following deprecation notices:

```
1) /home/runner/work/Requests/Requests/src/Utility/FilteredIterator.php:43
ArrayIterator::__construct(): Using an object as a backing array for ArrayIterator is deprecated, as it allows violating class constraints and invariants

Triggered by:

* WpOrg\Requests\Tests\Utility\FilteredIterator\ConstructorTest::testValidData#ArrayIterator object
  /home/runner/work/Requests/Requests/tests/Utility/FilteredIterator/ConstructorTest.php:26

* WpOrg\Requests\Tests\Utility\FilteredIterator\ConstructorTest::testValidData#Iterator object, no array access
  /home/runner/work/Requests/Requests/tests/Utility/FilteredIterator/ConstructorTest.php:26
```

This commit now makes two changes:
1. Change the `FilteredIterator::__construct()` method to no longer accept objects as a backing array.
2. No longer pass objects to the method when testing.

With that, these test failures on PHP 8.5 are fixed.

GitHub has the annoying habit of disabling workflows with a cron job after two months if the repo doesn't see any activity.

As this repo has been semi-dormant over the past year, this may become more regularly the case for this repo and this creates the following problem:
* If the same workflow is used for both the cron job as well as the push/pull_request CI checks...
* ... and a repo doesn't have any activity in two months time...
* ... the workflow gets disabled...
* ... which then also means that CI checks will no longer be run for new PRs....
* ... which means new PRs can't be merged as (in most cases) the repo has branch protection in place and requires that the CI checks pass before a PR can be merged.

This commit basically changes the original workflow to a reusable workflow and then creates two new workflows, with different `on` targets, which each trigger the reusable workflow.
* One workflow will be triggered via `cron`.
* One workflow will have all the other triggers (`push`/`pull_request`/`workflow_dispatch`).

This way, if the cron job workflow gets disabled, the workflow which is used for the other triggers will continue to function.

The downside of this, is that it may go unnoticed that the cron job has stopped running, but so be it.

As things were, test runs on forks (when the `stable` branch in the fork is updated) would always fail on the "upload code coverage reports" step, as forks (justifiably) don't have access to the `CODECOV_TOKEN`.

Fixed now by updating the conditions to run that step.

Python 3.14 is supported by mitmproxy since mitmproxy 12.2.0 (released Oct 15, 2025).

Refs:
* [Python 3.14 changelog](https://docs.python.org/release/3.14.0/whatsnew/changelog.html#changelog)
* [mitmproxy changelog](https://github.com/mitmproxy/mitmproxy/blob/main/CHANGELOG.md#15-october-2025-mitmproxy-1220)

Recently there has been more and more focus on securing GH Actions workflows - in part due to some incidents.

The problem with "unpinned" action runners is as follows:
* Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.
    Note that GitHub is currently beta-testing a new "immutable releases" feature (= tags and release artifacts can not be changed anymore once the release is published), but whether that has much effect depends on the ecosystem of the packages using the feature.
    Aside from that, it will likely take years before all projects adopt _immutable releases_.
* Action runners often don't even point to a tag, but to a branch, making the used action runner a moving target.
    _Note: this type of "floating major" for action runners used to be promoted as good practice when the ecosystem was "young". Insights have since changed._

While it is convenient to use "floating majors" of action runners, as this means you only need to update the workflows on a new major release of the action runner, the price is higher risk of malicious code being executed in workflows.

Dependabot, by now, can automatically submit PRs to update pinned action runners too, as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to.

So, what with Dependabot being capable of updating workflows with pinned action runners, I believe it is time to update the workflows to the _current_ best practice of using commit-hash pinned action runners.

The downside of this change is that there will be more frequent Dependabot PRs.

If this would become a burden/irritating, the following mitigations can be implemented:
1. Updating the Dependabot config to group updates instead of sending individual PRs per action runner.
2. A workflow to automatically merge Dependabot PRs as long as CI passes.

Ref: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions

Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4.6.2 to 5.0.0.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](actions/upload-artifact@ea165f8...330a01c)

---
updated-dependencies:
- dependency-name: actions/upload-artifact
  dependency-version: 5.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 5.0.0 to 6.0.0.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](actions/download-artifact@634f93c...018cc2c)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-version: 6.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

> By default, using `actions/checkout` causes a credential to be persisted in the checked-out repo's `.git/config`, so that subsequent `git` operations can be authenticated.
>
> Subsequent steps may accidentally publicly persist `.git/config`, e.g. by including it in a publicly accessible artifact via `actions/upload-artifact`.
>
> However, even without this, persisting the credential in the `.git/config` is non-ideal unless actually needed.
>
> **Remediation**
>
> Unless needed for `git` operations, `actions/checkout` should be used with `persist-credentials: false`.
>
> If the persisted credential is needed, it should be made explicit with `persist-credentials: true`.

This has now been addressed in all workflows.

Refs:
* https://unit42.paloaltonetworks.com/github-repo-artifacts-leak-tokens/
* https://docs.zizmor.sh/audits/#artipacked

... which is expected to be released this Thursday.

* Builds against PHP 8.5 are no longer allowed to fail.
* Update PHP version on which code coverage is run (high should now be 8.5).
* Add _allowed to fail_ build against PHP 8.6.

…n PHP 5.6

For some unphantomable reason this test is now structurally failing on PHP 5.6 with Xdebug turned off.

schlessera spend some time trying to debug this and trying to figure out why the test only fails on PHP 5.6 and only in the `quicktest` workflow, not in the `test` workflow, without a definitive conclusion.

Considering that support for PHP < 7.2 will be dropped in the near future - see ticket 983 -, let's not spend any more time on this and just skip this test on PHP 5.6 (as flaky).

Follow up on 928 which moved the proxy related scripts, but contained an error in the new path for the proxy server stop commands in the `quicktest` workflow.

1. PR 956 added some defensive coding to the `offset*()` methods in the `CaseInsensitiveDictionary` class, but was a little overzealous by also adding the defensive coding in the `offsetSet()` method which already would throw an exception and didn't need the extra defensive coding.
This has been cleaned up now.

2. When running the tests on PHP 8.5, two more test-only deprecation notices show up, though they don't fail the tests due to the deprecation being hit in a class constant definition, i.e. when reading the class:
```
Deprecated: Using null as an array offset is deprecated, use an empty string instead in path/to/Requests/tests/Utility/CaseInsensitiveDictionary/ArrayAccessTest.php on line 24

Deprecated: Using null as an array offset is deprecated, use an empty string instead in path/to/Requests/tests/Utility/CaseInsensitiveDictionary/GetAllTest.php on line 19
```

In both cases, the downlow of it is that PHP would _already_ convert the `null` key in the class constant to an empty string _at definition of the array_, so whether the array is declared with a `null` key or a `''` (empty string) key doesn't make any actual difference for the tests as by the time the data would hit the test code, the key would already be converted to an empty string.

With that in mind, I've taken the decision to make this empty string key explicit.

This doesn't diminish the value of the test and the guard code for the `offset*()` methods receiving a `null` `$key` is still being tested via the `ArrayAccessTest::testOffsetSetWithoutKey()` test and the `ArrayAccessTest::testAccessValidEntries()` with the "Null key will be converted to empty string" data set which is still in place as the data for that test is created via the `DATASET_REVERSED` constant (instead of the `DATASET` constant). This was previously designed this way explicitly to allow for testing the `null` offset case.

Long anticipated, finally here: PHPCompatibility 10.0.0-alpha1 🎉

PHPCompatibility 10.0.0 brings huge improvements in both what is being detected (> 50 new sniffs), as well as the detection accuracy for pre-existing sniffs.

Even though still "unstable", it is stable enough for our purposes and the advantages of using it outweight the disadvantage of it being an unstable version. By setting the `minimum-stability` and `prefer-stable` settings in the `composer.json`, we can ensure that we don't get the `dev-develop` branch, but rather get a `10.0.0` tag, unstable or not.

And what with the improved detection, a number of php incompatibilities previously not flagged, are not flagged, even though we already handle them correctly via conditions.
So this commit also adds a few selective ignore comments for those few situations where they are needed.

Ref:
* https://github.com/PHPCompatibility/PHPCompatibility/wiki/Upgrading-to-PHPCompatibility-10.0
* https://github.com/PHPCompatibility/PHPCompatibility/releases/tag/10.0.0-alpha1

* Includes updating the version number constant.