PHP Wiki

rfc - move "Minimum supported versions for PHP 8.6" to "pending implementation"

enorris (enorris@undisclosed.example.com) — 2026-07-30T16:01:56+00:00

2026/07/30 14:45		current
Line 15:		Line 15:
	* [[rfc:pipe_assignment_operator\|Pipe Assignment Operator]] (created 2026-07-09, discussion started 2026-07-09, voting started 2026-07-28)		* [[rfc:pipe_assignment_operator\|Pipe Assignment Operator]] (created 2026-07-09, discussion started 2026-07-09, voting started 2026-07-28)
	* [[rfc:deprecations_php_8_6\|Deprecations for PHP 8.6]] (Created 2025-07-02, Discussion started 2026-06-22)		* [[rfc:deprecations_php_8_6\|Deprecations for PHP 8.6]] (Created 2025-07-02, Discussion started 2026-06-22)
-	* [[rfc:min_supported_versions_php_8_6\|Minimum supported versions for PHP 8.6]] (created 2026-05-03, discussion started 2026-07-02, voting started 2026-07-16)
	* [[rfc:duration_class\|Duration class]] (created 2026-06-16)		* [[rfc:duration_class\|Duration class]] (created 2026-06-16)
	* [[rfc:readonly_property_defaults\|Readonly Property Defaults]] (created 2026-07-04, Discussion started 2026-07-04)		* [[rfc:readonly_property_defaults\|Readonly Property Defaults]] (created 2026-07-04, Discussion started 2026-07-04)
Line 146:		Line 145:
	==== Pending Implementation / Landing ====		==== Pending Implementation / Landing ====

		+	* [[rfc:min_supported_versions_php_8_6\|Minimum supported versions for PHP 8.6]] (created 2026-05-03, discussion started 2026-07-02, voting started 2026-07-16, voting ended 2026-07-30)
	* [[rfc:limit-maximum-number-of-filter-chains\|Limit maximum number of filter chains]] (created 2026-05-05)		* [[rfc:limit-maximum-number-of-filter-chains\|Limit maximum number of filter chains]] (created 2026-05-05)
	* [[rfc:stream_errors\|Stream Error Handling Improvements]] (Created 2025-11-18)		* [[rfc:stream_errors\|Stream Error Handling Improvements]] (Created 2025-11-18)

min_supported_versions_php_8_6 - update RFC status

enorris (enorris@undisclosed.example.com) — 2026-07-30T15:59:12+00:00

2026/07/16 21:40		current
Line 3:		Line 3:
	* Date: 2026-07-02		* Date: 2026-07-02
	* Author: Eric Norris, erictnorris@gmail.com; Tim Düsterhus, timwolla@php.net		* Author: Eric Norris, erictnorris@gmail.com; Tim Düsterhus, timwolla@php.net
-	* Status: Voting	+	* Status: Accepted
	* Thread: https://news-web.php.net/php.internals/131707		* Thread: https://news-web.php.net/php.internals/131707

Line 63:		Line 63:
	Each proposal is voted on separately and requires a 2/3 majority:		Each proposal is voted on separately and requires a 2/3 majority:

-	<doodle title="Implement autoconf 2.71 requirement as outlined in the RFC?" voteType="single" closed="false" closeon="2026-07-30T15:48:00Z">	+	<doodle title="Implement autoconf 2.71 requirement as outlined in the RFC?" voteType="single" closed="true" closeon="2026-07-30T15:48:00Z">
	* Yes		* Yes
	* No		* No
Line 71:		Line 71:
	----		----

-	<doodle title="Implement COM_RESET_CONNECTION requirement as outlined in the RFC?" voteType="single" closed="false" closeon="2026-07-30T15:48:00Z">	+	<doodle title="Implement COM_RESET_CONNECTION requirement as outlined in the RFC?" voteType="single" closed="true" closeon="2026-07-30T15:48:00Z">
	* Yes		* Yes
	* No		* No

function-autoloading-five-oh - open the vote

pmjones (pmjones@undisclosed.example.com) — 2026-07-30T14:43:02+00:00

2026/07/15 15:17		current
Line 358:		Line 358:
	Primary Vote requiring a 2/3 majority to accept the RFC:		Primary Vote requiring a 2/3 majority to accept the RFC:

-	<doodle title="Implement Function Autoloading as described in this RFC?" voteType="single" closed="true" closeon="2026-07-15T00:00:00Z">	+	<doodle title="Implement Function Autoloading as described in this RFC?" voteType="single" closed="false" closeon="2026-08-13T14:45:00Z">
	* Yes		* Yes
	* No		* No

literal_scalar_types - Chage the PHP version Target

azjezz (azjezz@undisclosed.example.com) — 2026-07-29T23:21:30+00:00

2026/07/23 05:42		current
Line 1:		Line 1:
	====== PHP RFC: Literal Scalar Types ======		====== PHP RFC: Literal Scalar Types ======

-	* Version: 1.0	+	* Version: 2.0
	* Date: 2026-07-23		* Date: 2026-07-23
	* Author: Seifeddine Gmati, <azjezz@carthage.software>		* Author: Seifeddine Gmati, <azjezz@carthage.software>
	* Status: Under Discussion		* Status: Under Discussion
-	* Target Version: PHP 8.6	+	* Target Version: PHP 8.7
	* Implementation: https://github.com/php/php-src/pull/22314		* Implementation: https://github.com/php/php-src/pull/22314
	* First Published at: http://wiki.php.net/rfc/literal_scalar_types		* First Published at: http://wiki.php.net/rfc/literal_scalar_types
Line 308:		Line 308:
	===== Changelog =====		===== Changelog =====

		+	* 2.0 (2026-07-30): Retargeted PHP 8.7
	* 1.0 (2026-07-23): Merged the accepted-syntax rules into the per-type sections, added the structural-data framing to the introduction, hardened the argument against coercive matching, and added a note on enum comparisons to the Performance section.		* 1.0 (2026-07-23): Merged the accepted-syntax rules into the per-type sections, added the structural-data framing to the introduction, hardened the argument against coercive matching, and added a note on enum comparisons to the Performance section.
	* 0.3 (2026-06-30): Added a Performance section, documented the leading unary ''+''/''-'', reworded the strict-matching rationale, and clarified the intersection and Reflection impacts.		* 0.3 (2026-06-30): Added a Performance section, documented the leading unary ''+''/''-'', reworded the strict-matching rationale, and clarified the intersection and Reflection impacts.
	* 0.2 (2026-06-17): Strict matching by default; restructured into three votes.		* 0.2 (2026-06-17): Strict matching by default; restructured into three votes.
	* 0.1 (2026-06-15): Initial version.		* 0.1 (2026-06-15): Initial version.

security_fixes - Remove outdated/stale information, link to and document current sources

edorian (edorian@undisclosed.example.com) — 2026-07-29T13:35:55+00:00

2025/04/03 13:08		current
Line 1:		Line 1:
-	====== Handling security fixes ======	+	====== Security fixes ======

-	This is the instruction for how to handle security fixes for currently active PHP branches. Note this is not an instruction on how to fix bugs in PHP (if you're reading this, you already supposed to know that, if you do not, please seek help from one of the experienced PHP group members), but only how to merge patch once you have a working one.	+	This page used to contain information about handling security issues in PHP. This has been moved to GitHub.

-	===== Verify =====	+	See:
-		+
-	- Post the patch to the bugs.php.net to the issue where it was reported. If the patch is big, use the "[[https://help.github.com/articles/creating-gists/\|secret gist]]" function on github.com. Do not use github pull requests, those are public!	+
-	- Ask the original reporter to confirm that the patch works.	+
-	- Assign the bug to yourself so that it is clear you are working on it now.	+
-	- Verify that the tests accompanying the patch and other relevant tests work. Note that you can not use CI for that for now, you'll have to run the tests locally. Rasmus' Vagrant box setup may help: https://github.com/rlerdorf/php7dev	+
-		+
-	===== Commit =====	+
-		+
-	- If you have access to PHP security repository, please proceed below. Otherwise, please contact somebody that does and send them the patch, or contact security@php.net if you do not know anybody who does. Since edits on security bugs are reported to the security list, adding note to the bug works too.	+
-	- Make a branch for the patch in a lowest version where it is relevant. If the patch is significantly different in other versions (such as 5.5 from 7.x), make the branches for all versions.	+
-	- Create the NEWS entry for the fix and all other file updates that are necessary (tests, UPGRADING, etc.).	+
-	- Commit the patch to the branch. Do not push the branch to main repo or your own public fork. Ensure that the commit message mentions bug number and contains a short description of what was done, e.g.: "Fixed bug #44666: removed buffer overflow and introduced proper boundary checking".	+
-	- Verify that the tests still run (the repository may have changed while you were working on the patch and waiting for feedback).	+
-	- Push the branch into the security repo.	+
-	- Notify the RM for the branches affected about the existence of the pending fix, preferably well in advance of the release date.	+
-	- Leave the note on the bug that the fix has been pushed to the security repo and the commit hash or branch name.	+
-	- If desired, especially if working on multiple patches, copies of current master branch (i.e. PHP-5.6 or PHP-7.0) and/or release branch (PHP-5.6.7 or PHP-7.0.2) may be used to merge the patches. These branches should be pushed only to the security repo. Never push those into any of the public repos.	+
-		+
-	===== Merge and release =====	+
-		+
-	Releases are usually tagged every 4 weeks on Tuesday and released on Thursday, so to know the date when the next release will be tagged, take 4 weeks from the last release date and count two days back. Please watch announcement on the list and contact RMs when in doubt since release dates can be changed in some circumstances.	+
-		+
-	- On the day of tagging or the day immediately before (consult with RM about relative timezones, etc.) merge the branches for the security fix into the main repository. Please note that if the fix is not the same for all active branches and you need to merge multiple branches, you will need to merge both the fix branch and the lower branch into higher branch. Optionally, RM can choose to merge the fixes, please communicate.	+
-	- Set the bug on bugs.php.net into public status. Note that doing that before pushing will allow the relevant bug to be auto-closed.	+
-	- Push the result into the main repository	+
-	- Verify that CI tests run clearly and that NEWS are updated for all relevant versions (including higher versions).	+
-	- Verify that the bug on bugs.php.net is indeed closed (may take several minutes for the bots to catch up). If it did not happen, close the bug manually (quoting the commit highly recommended if it wasn't attached automatically).	+
-	- After done merging all pending security fixes you had, notify the RMs. The RMs may have to pull the fixes into the release branches, so please choose the time that will allow them to do so before it is time to tag. However, try not to commit too early so that time between bug being disclosed and the fix released would be minimal.	+
-		+
-	===== CVEs =====	+
-		+
-	CVE handling procedures TBD.	+
-		+
-	Some useful info:	+
-		+
-	Request a CVE Identifier - https://cve.mitre.org/cve/request_id.html	+
-		+
-	Introduction to CVE Identifier Reservation	+
-	The basic process is:	+
-	- There is a request for one or more CVE-ID number(s).	+
-	- MITRE reserves the CVE-ID number(s) and provides the number(s) to the requester, and creates "blank," content-free CVE(s) on the CVE Web site.	+
-	- The requester shares the CVE-ID number(s) with all parties involved in the disclosure.	+
-	- The requester includes the CVE-ID number(s) in the vulnerability advisory.	+
-	- The requester makes the CVE-ID(s) public and notifies MITRE.	+
-	- MITRE updates the CVE-ID(s) on the CVE Web site to provide the details.	+

		+	* [[https://github.com/php/php-src/blob/master/SECURITY.md\|php-src/SECURITY.md]]
		+	* [[https://github.com/php/policies/blob/main/security-classification.rst\|policies/security-classification.md]]
		+	* Other documentation on triage can be found in the policy docs or in the PHP Security Team's internal documentation

		+	If you have any questions, please contact the PHP Security Team.

query_params

kocsismate (kocsismate@undisclosed.example.com) — 2026-07-28T20:36:39+00:00

2026/07/28 19:57		current
Line 115:		Line 115:

	public function sort(): static {}		public function sort(): static {}
		+
		+	public function withArray(array $queryParams): static {}

	public function toArray(int $maxNestingLevel = 64): array {}		public function toArray(int $maxNestingLevel = 64): array {}
Line 482:		Line 484:
	=== Array API ===		=== Array API ===

-	In order to better support arrays (again, which is a purely PHP-specific feature), the current RFC proposes a dedicated API.	+	The original proposal included a dedicated set of methods for working with PHP-style bracket-syntax arrays directly on the ''QueryParams'' object (''getArray()'', ''appendArray()'', ''setArray()''). After implementation experience and discussion, this approach was abandoned in favor of a significantly simpler design.

-	In order to instantiate ''QueryParams'' containing arrays, one can use the ''fromArray()'' factory method:	+	The core problem with the original approach was that it required ''QueryParams'' to reimplement PHP's native array operations internally. For example, ''QueryParams::getArray("foo[bar][baz]")'' would have needed to parse the array dimensions at runtime and navigate a nested structure, and ''appendArray()'' / ''setArray()'' would have required equivalent complexity for writes. Beyond the implementation burden, the resulting API surface was too large, the method names were confusable (e.g. ''getArray()''
		+	vs. ''getAll()''), and the behavior around bracket parsing in method arguments was difficult to define precisely and consistently.
		+
		+	The simplified Array API consists of three methods:
		+
		+	* ''QueryParams::fromArray()'': Creates a new ''QueryParams'' instance from a PHP array, using the bracket-syntax encoding rules described in the "Supported types" section to convert nested arrays into flat key-value pairs.
		+	* ''QueryParams::toArray()'': Converts the ''QueryParams'' instance back into a PHP array, inverting the encoding done by ''fromArray()''. The bracket-syntax in stored key names is interpreted to reconstruct nested arrays, following similar rules as ''$_GET''.
		+	* ''QueryParams::withArray()'': Similar to ''fromArray()'', but clones and then updates the current instance rather than creating a completely new one.
		+
		+	The intended workflow for array-based modifications is:

	<code php>		<code php>
-	$params = Uri\QueryParams::fromArray(	+	$params = Uri\QueryParams::parseRfc3986("page=1&debug=false");
-	[	+
-	"empty" => []	+	// Convert to a native PHP array, modify using native PHP operations
-	"list" => ["a", "b", "c"],	+	// then convert back to a QueryParams instance.
-	"map" => ["a" => 0, "b" => 1, "c" => 2],	+	$array = $params->toArray();
-	]	+	$array["page"] = 2;
-	);	+	unset($array["debug"]);
		+
		+	$params = Uri\QueryParams::fromArray($array);
	</code>		</code>

-	In order to convert all query parameters to an array, the ''toArray()'' method can be used. This behaves similarly to the ''getAll()'' method, but it actually retrieves all query params.	+	This design deliberately delegates array manipulation to PHP's native array functions rather than reimplementing them inside ''QueryParams''. The result is a smaller API surface, predictable behavior, and better composability with existing PHP code.
		+
		+	It is important to note that ''toArray()'' is the only method that interprets bracket-syntax in parameter names. All other methods
		+	(''getFirst()'', ''getAll()'', ''has()'', etc.) treat parameter names as opaque strings and do not parse brackets:

	<code php>		<code php>
-	$params = Uri\QueryParams::fromArray(	+	$params = Uri\QueryParams::parseRfc3986("foo%5B%5D=1&foo%5B%5D=2");
-	[	+	// Internally: [["foo[]", "1"], ["foo[]", "2"]]
-	"empty" => []	+
-	"list" => ["a", "b", "c"],	+
-	"map" => ["a" => 0, "b" => 1, "c" => 2],	+
-	]	+
-	);	+

-	/*	+	echo $params->getAll("foo[]"); // ["1", "2"]
-	Internally, this results in the the following array:	+	echo $params->getAll("foo"); // []

-	array(4) {	+	$array = $params->toArray();
-	["list"]=>	+	// ["foo" => ["1", "2"]] — brackets interpreted here
-	array(3) {	+	</code>
-	[0]=>	+
-	string(1) "a"	+
-	[1]=>	+
-	string(1) "b"	+
-	[2]=>	+
-	string(1) "c"	+
-	}	+
-	["map"]=>	+
-	array(3) {	+
-	["a"]=>	+
-	string(1) "0"	+
-	["b"]=>	+
-	string(1) "1"	+
-	["c"]=>	+
-	string(1) "2"	+
-	}	+
-	}	+
-	*/	+

-	echo $params->getFirst("empty"); // null	+	The ''toArray()'' method interprets bracket-syntax in parameter names to reconstruct nested arrays. Several edge cases require explicit behavior decision, since ''$_GET'' either handles them silently in surprising ways or treats them inconsistently:
-	echo $params->getAll("empty"); // []	+
-	echo $params->getArray("empty"); // []	+

-	echo $params->getFirst("list"); // "a"	+	Mixed scalar and array keys: If the same root key appears both as a plain parameter and with bracket notation (e.g. ''k=1&k[]=2''), ''$_GET'' silently discards the scalar value and retains only the array: the scalar ''k=1'' is stored first, then ''k[]=2'' converts ''k'' to an array, losing the original ''1''. The intended behavior of ''toArray()'' in this case is TBD — the options are to follow ''$_GET'''s silent last-write-wins behavior, or to throw an exception.
-	echo $params->getAll("list"); // []	+
-	echo $params->getAll("list[]"); // ["a", "b", "c"]	+
-	echo $params->getArray("list"); // ["a", "b", "c"]	+

-	echo $params->getFirst("map"); // 0	+	Unclosed bracket (e.g. ''k[=1''): ''$_GET'' replaces the ''['' with ''_'' (the same mangling applied to spaces and dots), storing the value under ''k_'' as a plain (non-array) key. Since ''toArray()'' does not apply key mangling, the recommended behavior is to treat the entire key as a literal string and not attempt bracket interpretation.
-	echo $params->getAll("map"); // []	+
-	echo $params->getArray("map"); // ["a" => "0", "b" => "1", "c" => "2"]	+	Extra closing bracket (e.g. ''foo[]]''): ''$_GET'' silently ignores the trailing '']'', treating the key as ''foo[]''. ''toArray()'' could do the same, or treat the key as a literal string without bracket interpretation.
-	</code>	+
		+	Unbalanced opening bracket (e.g. ''foo[[a]''): ''$_GET'' includes the extra ''['' as part of the subkey, producing ''foo["[a"]''. This behavior is clearly accidental and ''toArray()'' should instead treat such keys as literal strings.

	=== Class signature ===		=== Class signature ===

pipe_assignment_operator

cdwhite3 (cdwhite3@undisclosed.example.com) — 2026-07-28T04:31:19+00:00

2026/07/28 04:21		current
Line 8:		Line 8:
	* Implementation: https://github.com/php/php-src/pull/22633		* Implementation: https://github.com/php/php-src/pull/22633
	* Discussion thread: https://news-web.php.net/php.internals/131849		* Discussion thread: https://news-web.php.net/php.internals/131849
-	* Voting thread: tbd	+	* Voting thread: https://news-web.php.net/php.internals/132117

	===== Introduction =====		===== Introduction =====

preg_throw_on_error - Add discussion thread URL

aldemeery (aldemeery@undisclosed.example.com) — 2026-07-28T01:26:40+00:00

2026/07/28 00:57		current
Line 6:		Line 6:
	* Status: Under Discussion		* Status: Under Discussion
	* Implementation: https://github.com/php/php-src/pull/22797		* Implementation: https://github.com/php/php-src/pull/22797
-	* Discussion thread: https://news-web.php.net/php.internals/...	+	* Discussion thread: https://news-web.php.net/php.internals/132115
	* Voting thread: tbd		* Voting thread: tbd
	* First Published at: https://wiki.php.net/rfc/preg_throw_on_error		* First Published at: https://wiki.php.net/rfc/preg_throw_on_error

deprecations_php_8_6 - Fixi voting widget for one proposal

girgias (girgias@undisclosed.example.com) — 2026-07-27T10:26:07+00:00

2026/07/27 16:38		current
Line 566:		Line 566:
	</blockquote>		</blockquote>

-	And if an object is encountered during traversal the following deprecatioin will be emitted:	+	And if an object is encountered during traversal the following deprecation will be emitted:
	<blockquote>		<blockquote>
	Deprecated: object values within argument #1 $data to http_build_query() being interpreted as arrays is deprecated, instead the $data argument should be preprocessed with get_object_vars()		Deprecated: object values within argument #1 $data to http_build_query() being interpreted as arrays is deprecated, instead the $data argument should be preprocessed with get_object_vars()

const_object_property_write - open voting

khaledalamxyz (khaledalamxyz@undisclosed.example.com) — 2026-07-25T13:44:49+00:00

2026/07/25 13:46		current
Line 206:		Line 206:
	* Yes		* Yes
	* No		* No
		+	* Abstain
	</doodle>		</doodle>

serializable_closures

nicolasgrekas (nicolasgrekas@undisclosed.example.com) — 2026-07-24T21:29:50+00:00

2026/07/18 09:50		current
Line 117:		Line 117:
	running the same source computes the same reference, with or without opcache.		running the same source computes the same reference, with or without opcache.

-	''site'' names the declaring element: ''""'' for the class, a constant or enum-case name, ''$prop''	+	''site'' names the class member that declares the closure: a constant or enum-case name, ''$prop''
-	for a property, ''$prop::get()'' / ''$prop::set()'' for a hook, ''name()'' for a method. ''key'' is	+	for a property, ''$prop::get()'' / ''$prop::set()'' for a hook, ''name()'' for a method. When the
-	the closure's position in that element (an integer) for an anonymous closure, or the callable's name	+	declaration is on the class itself (a class attribute), there is no member and ''site'' is the empty
-	for a first-class callable. Because the reference belongs to one element, editing one element never	+	string. ''key'' is the closure's position in that element (an integer) for an anonymous closure, or
-	changes the numbering of another, and resolution walks only the named element.	+	the callable's name for a first-class callable. Because the reference belongs to one element,
		+	editing one element never changes the numbering of another, and resolution walks only the named
		+	element.

	''hash'' guards an anonymous position: a hash of the closure's code computed at compile time (it		''hash'' guards an anonymous position: a hash of the closure's code computed at compile time (it
Line 150:		Line 152:
	declared closure for another: the same kind of risk as an unserialized enum-case name, and much		declared closure for another: the same kind of risk as an unserialized enum-case name, and much
	less than what ''unserialize()'' already allows when it rebuilds objects and runs their		less than what ''unserialize()'' already allows when it rebuilds objects and runs their
-	''%%__wakeup()%%''. ''allowed_classes'' gates it at both ends: without <php>Closure</php> in the	+	''%%__wakeup()%%''. When ''unserialize()'' is called with ''allowed_classes'', the filter applies
-	list the payload becomes <php>__PHP_Incomplete_Class</php>, and resolving a reference takes a	+	twice. First to <php>Closure</php> itself: if it is not in the list, a Closure payload degrades to
-	closure from its declaring class, which must be listed too.	+	<php>__PHP_Incomplete_Class</php> like any other filtered object, so a consumer that filters and
		+	expects closures must list <php>Closure</php> explicitly. Second to the declaring class named in
		+	the reference: resolving takes a closure out of that class (autoloading it if needed), so it must
		+	be in the list too, exactly as if an instance of it were being unserialized.

	This limit is the reason first-class callables serialize only when declared in a constant		This limit is the reason first-class callables serialize only when declared in a constant

readonly_property_defaults

nicksdot (nicksdot@undisclosed.example.com) — 2026-07-24T05:15:21+00:00

2026/07/24 05:38		current
Line 12:		Line 12:
	===== Introduction =====		===== Introduction =====

-	This RFC seeks to allow default values for instance readonly properties. Historically, default values on readonly properties were not disallowed for technical reasons, but because they were considered “not particularly useful”. With interfaces properties, introduced in PHP 8.4, this changed. Allowing default values on readonly class properties enables creating a strict contract for implementation property values that will not change at runtime -- as in, constant-like behaviour with contract.	+	This RFC seeks to allow default values for instance readonly properties. Historically, default values on readonly properties were not disallowed for technical reasons, but because they were considered “not particularly useful”. With interface properties, introduced in PHP 8.4, this changed. Allowing default values on readonly class properties enables creating a strict contract for implementation property values that will not change at runtime -- as in, constant-like behaviour with contract.

	<PHP>		<PHP>
Line 47:		Line 47:
	<blockquote>As the default value counts as an initialising assignment, a readonly property with a default value is essentially the same as a constant, and thus not particularly useful. The notion could become more useful in the future if new expressions are allowed as property default values.</blockquote>		<blockquote>As the default value counts as an initialising assignment, a readonly property with a default value is essentially the same as a constant, and thus not particularly useful. The notion could become more useful in the future if new expressions are allowed as property default values.</blockquote>

-	This means the original RFC actively highlighted to look out for future language additions as a reason that would make allowing readonly property default values worthwhile. The in PHP 8.4 landed interface properties are such a reason.	+	This means the original RFC actively highlighted to look out for future language additions as a reason that would make allowing readonly property default values worthwhile. The interface properties landed in PHP 8.4 are such a reason.

	==== General ====		==== General ====

surface3d.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-19T13:48:10+00:00

	current

scaled_on_load_rotate.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-17T06:47:24+00:00

	current

watermarked.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-17T03:57:25+00:00

	current

scale_entropy_visual_check.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-14T03:12:03+00:00

	current

textcurve.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-10T14:08:53+00:00

1783692513	current

gradient_art.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:32:24+00:00

	current

tiger.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:32:03+00:00

	current

gradient_operators.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:31:36+00:00

	current

2026/07/30 14:45		current
Line 15:		Line 15:
	* [[rfc:pipe_assignment_operator\|Pipe Assignment Operator]] (created 2026-07-09, discussion started 2026-07-09, voting started 2026-07-28)		* [[rfc:pipe_assignment_operator\|Pipe Assignment Operator]] (created 2026-07-09, discussion started 2026-07-09, voting started 2026-07-28)
	* [[rfc:deprecations_php_8_6\|Deprecations for PHP 8.6]] (Created 2025-07-02, Discussion started 2026-06-22)		* [[rfc:deprecations_php_8_6\|Deprecations for PHP 8.6]] (Created 2025-07-02, Discussion started 2026-06-22)
-	* [[rfc:min_supported_versions_php_8_6\|Minimum supported versions for PHP 8.6]] (created 2026-05-03, discussion started 2026-07-02, voting started 2026-07-16)
	* [[rfc:duration_class\|Duration class]] (created 2026-06-16)		* [[rfc:duration_class\|Duration class]] (created 2026-06-16)
	* [[rfc:readonly_property_defaults\|Readonly Property Defaults]] (created 2026-07-04, Discussion started 2026-07-04)		* [[rfc:readonly_property_defaults\|Readonly Property Defaults]] (created 2026-07-04, Discussion started 2026-07-04)
Line 146:		Line 145:
	==== Pending Implementation / Landing ====		==== Pending Implementation / Landing ====

		+	* [[rfc:min_supported_versions_php_8_6\|Minimum supported versions for PHP 8.6]] (created 2026-05-03, discussion started 2026-07-02, voting started 2026-07-16, voting ended 2026-07-30)
	* [[rfc:limit-maximum-number-of-filter-chains\|Limit maximum number of filter chains]] (created 2026-05-05)		* [[rfc:limit-maximum-number-of-filter-chains\|Limit maximum number of filter chains]] (created 2026-05-05)
	* [[rfc:stream_errors\|Stream Error Handling Improvements]] (Created 2025-11-18)		* [[rfc:stream_errors\|Stream Error Handling Improvements]] (Created 2025-11-18)