PHP Wiki

working_groups

ramsey (ramsey@undisclosed.example.com) — 2026-05-26T17:02:27+00:00

2026/05/26 16:22		current
Line 303:		Line 303:

	* The first version of this document specified an automatic duration of 1 year for all working groups, unless specified. This required rechartering of each working group every year, or defining the specific duration for a longer period within the charter. Indefinite working groups were not allowed. After off-list discussion with others, it was decided this was cumbersome and would likely lead to confusion, so I have revised the RFC to allow indefinite durations and to explicitly require "duration" as a component of the working group charter.		* The first version of this document specified an automatic duration of 1 year for all working groups, unless specified. This required rechartering of each working group every year, or defining the specific duration for a longer period within the charter. Indefinite working groups were not allowed. After off-list discussion with others, it was decided this was cumbersome and would likely lead to confusion, so I have revised the RFC to allow indefinite durations and to explicitly require "duration" as a component of the working group charter.
		+
		+	==== Changelog ====
		+
		+	* 2025-02-17: Initial draft published on wiki
		+	* 2025-11-26: RFC moved to "Withdrawn" after external discussions
		+	* 2026-05-25: RFC moved back to "Draft" and updated to specify duration as required, allow "indefinite" durations, include an example charter, among minor edits for style
		+	* 2026-05-26: RFC moved to "Under Discussion"

rfc

ramsey (ramsey@undisclosed.example.com) — 2026-05-26T16:18:18+00:00

2026/05/26 16:15		current
Line 22:		Line 22:
	This section is for RFCs that have been announced on the PHP "internals" mail list.		This section is for RFCs that have been announced on the PHP "internals" mail list.

-	* [[rfc:working_groups\|Working Groups]] (Created 2025-02-17)	+	* [[rfc:working_groups\|Working Groups]] (Created 2025-02-17, discussion started 2026-05-26)
	* [[rfc:getdisplaykeyword_and_getdisplaykeywordvalue\|Add Locale::getDisplayKeyword and Locale::getDisplayKeywordValue functions]] (created 2026-05-22)		* [[rfc:getdisplaykeyword_and_getdisplaykeywordvalue\|Add Locale::getDisplayKeyword and Locale::getDisplayKeywordValue functions]] (created 2026-05-22)
	* [[rfc:opcache_static_cache\|OPcache Static Cache]] (created 2026-05-15, discussion started 2026-05-17)		* [[rfc:opcache_static_cache\|OPcache Static Cache]] (created 2026-05-15, discussion started 2026-05-17)

opcache_static_cache - close open issues

zeriyoshi (zeriyoshi@undisclosed.example.com) — 2026-05-26T02:20:44+00:00

2026/05/19 12:20		current
Line 1:		Line 1:
	====== PHP RFC: OPcache Static Cache ======		====== PHP RFC: OPcache Static Cache ======
-	* Version: 1.2.1	+	* Version: 1.3.0
-	* Date: 2026-05-19	+	* Date: 2026-05-26
	* Author: Go Kudo <g-kudo@colopl.co.jp> <zeriyoshi@php.net>		* Author: Go Kudo <g-kudo@colopl.co.jp> <zeriyoshi@php.net>
	* Status: Under Discussion		* Status: Under Discussion
Line 415:		Line 415:
	===== Security and Trust Model =====		===== Security and Trust Model =====

-	OPcache Static Cache is shared memory for one PHP runtime instance. The trust boundary is the OPcache static-cache shared-memory segment established at SAPI startup. Workers that inherit or attach to the same segment share the same explicit key/value namespace and the same attribute-backed static-state namespace. This is not a tenant-isolation boundary. In FPM, the configured static-cache segments are initialized before workers start and are inherited by workers, so multiple pools under the same FPM master share the same cache namespace.	+	OPcache Static Cache is shared memory associated with one PHP runtime instance. The trust boundary is the OPcache static-cache shared-memory segment established at SAPI startup. Workers that inherit or attach to the same segment share both the explicit key/value namespace and the attribute-backed static-state namespace. The static-cache segment should not be treated as a tenant-isolation boundary. In FPM, the configured static-cache segments are initialized before worker processes are started and are inherited by those workers; consequently, multiple pools under the same FPM master process share the same cache namespace.

-	Administrators should leave these directives enabled only when every worker that can access the same OPcache static-cache segment belongs to the same trust domain, for example one application, one tenant, or mutually trusted applications that already coordinate their cache keys. Shared-hosting deployments that run mutually untrusted pools, vhosts, Unix users, chroots, or customers under one PHP master should disable the backends for that master by setting both size directives to <php>0</php>, or run those tenants under separate PHP/FPM master processes, containers, or equivalent OS-level isolation that gives each trust domain its own OPcache and static-cache shared memory. Setting these directives in an individual FPM pool does not create a per-pool static-cache segment once OPcache has been set up.	+	Administrators should enable these backends only when every worker that can access the same OPcache static-cache segment belongs to the same trust domain, such as a single application, a single tenant, or mutually trusted applications that already coordinate their cache keys. Shared-hosting deployments that run mutually untrusted pools, virtual hosts, Unix users, chroots, or customers under a single PHP master process should disable these backends for that master by setting both size directives to <php>0</php>, or should run those tenants under separate PHP/FPM master processes, containers, virtual machines, or equivalent operating-system isolation that gives each trust domain its own OPcache and static-cache shared memory. Setting these directives in pool-specific FPM configuration does not create a per-pool static-cache segment after OPcache has been initialized.

-	The existing <php>opcache.validate_permission</php> and <php>opcache.validate_root</php> directives mitigate script-cache access and chroot key-collision issues by revalidating file access or varying script-cache hashes by root. They do not isolate OPcache Static Cache entries, because explicit cache keys and attribute-backed static-state keys are application data rather than script filenames. This is similar to local shared user caches such as APCu: applications should still namespace keys for correctness, but user-controlled key prefixes are not a security boundary when untrusted code can choose keys or call cache mutation APIs.	+	This RFC does not attempt to make the legacy deployment model of a single PHP master process serving mutually untrusted tenants safe on its own. That model is no longer the common case in modern PHP hosting, where tenant isolation is typically provided by separate FPM masters, containers, virtual machines, or equivalent operating-system boundaries. Hosting providers that still run mutually untrusted tenants under a single OPcache static-cache shared-memory segment should disable these backends in the master-level configuration, in the same way that they would restrict or disable <php>opcache_get_status()</php> when exposing OPcache state would cross a tenant boundary.
		+
		+	This is a deployment configuration responsibility, not a reason to add an application-level namespace or pool primitive to this RFC. The required mitigation is explicit and mechanical: set <php>opcache.static_cache.volatile_size_mb=0</php> and <php>opcache.static_cache.pinned_size_mb=0</php> for PHP master processes that host mutually untrusted tenants, or move those tenants to separate OPcache static-cache shared-memory segments. As with other OPcache configuration changes that affect shared-hosting behavior, documenting the change and announcing it to affected operators is sufficient.
		+
		+	The existing <php>opcache.validate_permission</php> and <php>opcache.validate_root</php> directives mitigate script-cache access and chroot key-collision issues by revalidating file access or varying script-cache hashes by root. They do not isolate OPcache Static Cache entries, because explicit cache keys and attribute-backed static-state keys are application data rather than script filenames. This is similar to local shared-memory user caches such as APCu: applications should still namespace keys for correctness, but user-controlled key prefixes are not a security boundary when untrusted code can choose keys or call cache-mutation APIs.

	===== Implementation Notes =====		===== Implementation Notes =====
Line 498:		Line 502:

	FPM must initialize the configured static-cache shared-memory segments before workers start. If a backend would be initialized too late, the implementation reports the cache as unavailable instead of creating worker-local state.		FPM must initialize the configured static-cache shared-memory segments before workers start. If a backend would be initialized too late, the implementation reports the cache as unavailable instead of creating worker-local state.
-
-	===== Open Issues =====
-
-	* Whether multi-library key-collision concerns should be addressed by an explicit pool/namespace primitive in a future RFC. Class-name and exact-key deletion already cover most "rebuild my library's keys" patterns within a single trust domain, but a separate namespacing mechanism would help when several independent libraries are deployed together and want clear ownership boundaries.

	===== Future Scope =====		===== Future Scope =====
Line 507:		Line 507:
	Possible future directions that this RFC does not commit to but does not prevent:		Possible future directions that this RFC does not commit to but does not prevent:

-	* SAPI-provided trust-domain or pool identity, exposed to OPcache static-cache key resolution, for deployments that want one PHP master to serve mutually untrusted tenants under separate static-cache namespaces.
	* A higher-level attribute over function return values, memoize-style, layered on top of the same static-cache backends and kept distinct from the static-storage semantics that <php>PinnedStatic</php> and <php>VolatileStatic</php> describe.		* A higher-level attribute over function return values, memoize-style, layered on top of the same static-cache backends and kept distinct from the static-storage semantics that <php>PinnedStatic</php> and <php>VolatileStatic</php> describe.
		+	* SAPI-provided trust-domain or pool identity, exposed to OPcache static-cache key resolution, for deployments that intentionally want multiple trusted applications under one PHP master to use separate static-cache namespaces. This is not a security boundary for mutually untrusted tenants; those deployments should use separate OPcache static-cache shared-memory segments or disable the static-cache backends.

	===== Voting Choices =====		===== Voting Choices =====
Line 755:		Line 755:
	===== Changelog =====		===== Changelog =====

		+	* 2026-05-26
		+	* Bumped the RFC document version to 1.3.0 and updated the RFC date to 2026-05-26.
		+	* Removed the Open Issues section. The former pool/namespace item is now covered by the Security and Trust Model and narrowed to Future Scope.
		+	* This does not change the proposed API, INI directives, default values, implementation semantics, or voting choices.
	* 2026-05-19		* 2026-05-19
	* Bumped the RFC document version to 1.2.1.		* Bumped the RFC document version to 1.2.1.
Line 810:		Line 814:
	* Added PHPT coverage for loaded-class attribute deletion, documented exact-key attribute deletion, manual unlock, post-shutdown lock leases, stricter key validation, <php>StaticCacheInfo</php>, and pinned atomic decrement creation.		* Added PHPT coverage for loaded-class attribute deletion, documented exact-key attribute deletion, manual unlock, post-shutdown lock leases, stricter key validation, <php>StaticCacheInfo</php>, and pinned atomic decrement creation.
	* Updated existing PHPT coverage to use <php>StaticCacheInfo</php> object properties instead of array offsets.		* Updated existing PHPT coverage to use <php>StaticCacheInfo</php> object properties instead of array offsets.
-	* benchmark harness from the RFC.	+	* Moved the benchmark harness out of the RFC text and linked it from the Patches and Tests section.
	* Reran the benchmark matrix from clean current NTS FPM, current NTS/ZTS CLI, current ZTS FrankenPHP, and clean <php>43b56c96af5c373a0539bca49bdc568b01a3163c</php> CLI builds, then updated the performance tables and benchmark takeaways.		* Reran the benchmark matrix from clean current NTS FPM, current NTS/ZTS CLI, current ZTS FrankenPHP, and clean <php>43b56c96af5c373a0539bca49bdc568b01a3163c</php> CLI builds, then updated the performance tables and benchmark takeaways.
	* Removed the boilerplate Future Scope text and added an open issue about possible <php>Memoize</php>-style naming.		* Removed the boilerplate Future Scope text and added an open issue about possible <php>Memoize</php>-style naming.

bound_erased_generic_types - Runtime enforcement of substituted contracts tightened; document type-argument erasure as a limitation (v0.22)

azjezz (azjezz@undisclosed.example.com) — 2026-05-24T06:02:11+00:00

2026/05/24 06:02		current
Line 2137:		Line 2137:
	* 2026-05-13: ''ReflectionGenericVariance'' is now a unit enum (v0.20).		* 2026-05-13: ''ReflectionGenericVariance'' is now a unit enum (v0.20).
	* 2026-05-14: ''getGenericArgumentsForParentInterface()'' returns ''list<list<ReflectionType>>'' (v0.21).		* 2026-05-14: ''getGenericArgumentsForParentInterface()'' returns ''list<list<ReflectionType>>'' (v0.21).
-	* 2026-05-14: Runtime enforcement of substituted contracts tightened; document type-argument erasure as a limitation (v0.22).	+	* 2026-05-24: Runtime enforcement of substituted contracts tightened; document type-argument erasure as a limitation (v0.22).

override_constants - vote was successful

daniels (daniels@undisclosed.example.com) — 2026-05-24T04:47:45+00:00

2026/05/08 02:03		current
Line 3:		Line 3:
	* Date: 2026-03-13		* Date: 2026-03-13
	* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com		* Author: Daniel Scherzer, daniel.e.scherzer@gmail.com
-	* Status: Voting	+	* Status: Pending implementation / landing
	* Implementation: https://github.com/php/php-src/pull/20478		* Implementation: https://github.com/php/php-src/pull/20478
	* Discussion thread: https://news-web.php.net/php.internals/130505		* Discussion thread: https://news-web.php.net/php.internals/130505

template - Add discussion thread link “template” and voting thread entry

timwolla (timwolla@undisclosed.example.com) — 2026-05-23T11:22:22+00:00

2026/05/10 16:29		current
Line 5:		Line 5:
	* Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")		* Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")
	* Implementation: https://github.com/...		* Implementation: https://github.com/...
-	* Discussion thread:	+	* Discussion thread: https://news-web.php.net/php.internals/… (The email should appear on https://news-web.php.net/php.internals/ a few minutes after sending it)
		+	* Voting thread: tbd

	This is the suggested template for PHP Request for Comments (RFCs). Change this template to suit your RFC. Not all RFCs need all the sections below.		This is the suggested template for PHP Request for Comments (RFCs). Change this template to suit your RFC. Not all RFCs need all the sections below.

partial_function_application_optional_placeholder - Accepted

timwolla (timwolla@undisclosed.example.com) — 2026-05-23T10:33:43+00:00

2026/05/06 14:22		current
Line 3:		Line 3:
	* Date: 2026-04-20		* Date: 2026-04-20
	* Author: Tim Düsterhus (timwolla@php.net), Arnaud Le Blanc (arnaud.lb@gmail.com), Larry Garfield (larry@garfieldtech.com)		* Author: Tim Düsterhus (timwolla@php.net), Arnaud Le Blanc (arnaud.lb@gmail.com), Larry Garfield (larry@garfieldtech.com)
-	* Status: Voting	+	* Status: Accepted
	* Implementation: https://github.com/...		* Implementation: https://github.com/...

Line 122:		Line 122:
	Primary Vote requiring a 2/3 majority to accept the RFC:		Primary Vote requiring a 2/3 majority to accept the RFC:

-	<doodle title="Make all ? placeholders in PFA required parameters?" voteType="single" closed="false" closeon="2026-05-20T10:30:00Z">	+	<doodle title="Make all ? placeholders in PFA required parameters?" voteType="single" closed="true" closeon="2026-05-20T10:30:00Z">
	* Yes		* Yes
	* No		* No

limit-maximum-number-of-filter-chains - Change limit through stream context option

sjoerd (sjoerd@undisclosed.example.com) — 2026-05-22T12:02:31+00:00

2026/05/21 13:10		current
Line 28:		Line 28:
	The proposal seeks to limit the number of individual filter components allowed in a single `php:%%//%%filter` string. This limit applies specifically to the parsing of php:%%//%%filter URLs (e.g., via fopen, include, file_get_contents). When the limit is exceeded, PHP should give a deprecation warning, and later an error.		The proposal seeks to limit the number of individual filter components allowed in a single `php:%%//%%filter` string. This limit applies specifically to the parsing of php:%%//%%filter URLs (e.g., via fopen, include, file_get_contents). When the limit is exceeded, PHP should give a deprecation warning, and later an error.

-	The limit will be harcoded to 16. There will not be a PHP INI setting for this. The limit is sufficiently high that legitimate users are unlikely to run into this limit.	+	The limit will default to 16, and can be changed using the stream context option ''filter.max_filter_count''. There will not be a PHP INI setting for this. The limit is sufficiently high that legitimate users are unlikely to run into this limit.

	Using many filters will still be possible using stream_filter_append / prepend.		Using many filters will still be possible using stream_filter_append / prepend.
Line 41:		Line 41:
	</PHP>		</PHP>

-	Fails:	+	Deprecation warning:
		+
		+	<PHP>
		+	file_get_contents("php://filter/convert.iconv.UTF8.CSISO2022KR\|convert.base64-encode\|...[48 more].../resource=php://temp");
		+	// Deprecated: Using more than 16 filters in a php://filter URL is deprecated, set this limit using the stream context option max_filter_count, or use stream_filter_append in ...
		+	</PHP>
		+
		+	Error (when ''filter.max_filter_count'' is set, or in later PHP version):

	<PHP>		<PHP>
	var_dump(file_get_contents("php://filter/convert.iconv.UTF8.CSISO2022KR\|convert.base64-encode\|...[48 more].../resource=php://temp"));		var_dump(file_get_contents("php://filter/convert.iconv.UTF8.CSISO2022KR\|convert.base64-encode\|...[48 more].../resource=php://temp"));
-	// Warning: file_get_contents(...): filter chain depth of 50 exceeds the limit of 32	+	// Warning: file_get_contents(...): Failed to open stream: too many filters in ...
	// bool(false)		// bool(false)
	</PHP>		</PHP>
Line 68:		Line 75:
	This is a backward incompatible change for any application that legitimately chains more filters than the defined limit.		This is a backward incompatible change for any application that legitimately chains more filters than the defined limit.

-	There is a clear upgrade path for users who want to use many filters on a stream: use stream_filter_append / prepend.	+	There is a clear upgrade path for users who want to use many filters on a stream: configure the stream context option ''filter.max_filter_count'', or use stream_filter_append / prepend.

	===== Proposed PHP Version(s) =====		===== Proposed PHP Version(s) =====

-	* PHP 8.6: deprecation warning when using more than 16 filters.	+	* PHP 8.6: deprecation warning when using more than 16 filters, error when stream context option ''filter.max_filter_count'' is set.
	* PHP 8.7: error as described in [[stream_errors\|PHP RFC: Stream Error Handling Improvements]]		* PHP 8.7: error as described in [[stream_errors\|PHP RFC: Stream Error Handling Improvements]]

Line 88:		Line 95:

	* Exact Limit: Should the default be 10, 16, 32? 16 seems like a good trade-off between security and allowing legitimate use.		* Exact Limit: Should the default be 10, 16, 32? 16 seems like a good trade-off between security and allowing legitimate use.
-	* Hardcode the limit or add a PHP INI setting? What should the INI name be? filter.max_chain_length? With a high limit it is unlikely that anyone needs to change this.	+	* Hardcode the limit or add a PHP INI setting? What should the INI name be? filter.max_chain_length? Jakub Zelenka suggested a stream context option, which seems well suited for this.
	* How should this be introduced and tightened? E.g. start with high hard limit, or low limit and give a deprecation warning instead of an error? With a deprecation warning, as this is technically a backwards incompatible change.		* How should this be introduced and tightened? E.g. start with high hard limit, or low limit and give a deprecation warning instead of an error? With a deprecation warning, as this is technically a backwards incompatible change.
	* Should exceeding the limit throw a ValueError (consistent with modern PHP 8 APIs) or a Warning (consistent with legacy stream handling)? First a deprecation warning, then as described in the [[stream_errors\|PHP RFC: Stream Error Handling Improvements]]		* Should exceeding the limit throw a ValueError (consistent with modern PHP 8 APIs) or a Warning (consistent with legacy stream handling)? First a deprecation warning, then as described in the [[stream_errors\|PHP RFC: Stream Error Handling Improvements]]
Line 108:		Line 115:
	* Julien Voisin [[https://github.com/php/php-src/pull/16699\|suggested]] a limit of 3 or 5.		* Julien Voisin [[https://github.com/php/php-src/pull/16699\|suggested]] a limit of 3 or 5.
	* Derick Rethans objected to this but thinks a limit of 16 [[https://news-web.php.net/php.internals/130863\|is acceptable]].		* Derick Rethans objected to this but thinks a limit of 16 [[https://news-web.php.net/php.internals/130863\|is acceptable]].
		+	* Jakub Zelenka suggested using a stream context option to make the limit configurable.

	What should happen when the limit is reached?		What should happen when the limit is reached?
Line 113:		Line 121:
	* Derick Rethans and PR 16699 suggest throwing an exception, but Jakub Zelenka correctly [[https://github.com/php/php-src/pull/16699#issuecomment-2462435265\|points out]] that this "inconsistent with current stream error handling".		* Derick Rethans and PR 16699 suggest throwing an exception, but Jakub Zelenka correctly [[https://github.com/php/php-src/pull/16699#issuecomment-2462435265\|points out]] that this "inconsistent with current stream error handling".
	* Since this is technically a BC break, it may be worth it to generate a warning before setting a hard limit.		* Since this is technically a BC break, it may be worth it to generate a warning before setting a hard limit.
		+	* Jakub Zelenka has done work on a constistent [[stream_errors\|streams error API]], which takes away the dilemma between warnings and exceptions.

	===== Voting Choices =====		===== Voting Choices =====
Line 168:		Line 177:
	* 1.2 2026-05-19 Make clear that stream_filter_append is unaffected		* 1.2 2026-05-19 Make clear that stream_filter_append is unaffected
	* 1.3 2026-05-21 New PR, more firm suggestions		* 1.3 2026-05-21 New PR, more firm suggestions
		+	* 1.4 2026-05-22 Change limit through stream context option

getdisplaykeyword_and_getdisplaykeywordvalue - created

lamentxu (lamentxu@undisclosed.example.com) — 2026-05-22T09:43:33+00:00

2026/05/26 22:11	current
Line 1:	Line 1:
	+	====== PHP RFC: Add Locale::getDisplayKeyword() and Locale::getDisplayKeywordValue() ======
	+	* Version: 1.0
	+	* Date: 2026-05-22
	+	* Author: Weilin Du, lamentxu@163.com
	+	* Status: Under Discussion
	+	* Implementation: TBD
	+	* Discussion thread:

	+	===== Introduction =====
	+
	+	This RFC proposes adding ''%%Locale::getDisplayKeyword()%%'' and ''%%Locale::getDisplayKeywordValue()%%'' to ''%%ext/intl%%'', also with their procedural aliases. These APIs expose ICU’s ''%%uloc_getDisplayKeyword()%%'' and ''%%uloc_getDisplayKeywordValue()%%'' to PHP userland.
	+
	+	PHP already exposes a family of locale display helpers such as ''%%Locale::getDisplayLanguage()%%'', ''%%Locale::getDisplayRegion()%%'', ''%%Locale::getDisplayVariant()%%'', and ''%%Locale::getDisplayName()%%''. PHP also exposes ''%%Locale::getKeywords()%%'', which allows code to extract locale keyword pairs. What is currently missing is a way to localize the keyword names themselves and the display labels for their values. This proposal fills that gap in a way that is consistent with the existing ''%%Locale%%'' API surface.
	+
	+	===== Proposal =====
	+
	+	Add two new procedural functions and two new ''%%Locale%%'' static methods:
	+
	+	<PHP>
	+	function locale_get_display_keyword(
	+	string $keyword,
	+	?string $displayLocale = null
	+	): string\|false {}
	+
	+	function locale_get_display_keyword_value(
	+	string $locale,
	+	string $keyword,
	+	?string $displayLocale = null
	+	): string\|false {}
	+
	+	class Locale
	+	{
	+	public static function getDisplayKeyword(
	+	string $keyword,
	+	?string $displayLocale = null
	+	): string\|false {}
	+
	+	public static function getDisplayKeywordValue(
	+	string $locale,
	+	string $keyword,
	+	?string $displayLocale = null
	+	): string\|false {}
	+	}
	+	</PHP>
	+
	+	The proposed methods intentionally follow the existing ''%%Locale::getDisplay*()%%'' naming pattern.
	+
	+	The new APIs should follow the behavior of the existing display-oriented ''%%Locale%%'' methods:
	+
	+	* If ''%%$displayLocale%%'' is ''%%null%%'', the current default locale is used.
	+	* On ICU failure, the function returns ''%%false%%'' and reports the error through the existing intl error mechanism.
	+	* Embedded NUL bytes in string parameters should continue to throw ''%%ValueError%%'', consistent with current locale input handling.
	+	* Invalid locale strings should continue to follow existing ICU-backed ''%%ext/intl%%'' behavior.
	+
	+	==== Motivation ====
	+
	+	This proposal brings practical value because it completes an already existing workflow in ''%%ext/intl%%'':
	+
	+	* Parse or receive a locale identifier.
	+	* Extract keyword/value pairs via ''%%Locale::getKeywords()%%''.
	+	* Render those keywords and values for humans in a chosen display locale.
	+
	+	Without these APIs, userland code must maintain its own mapping layer for keyword labels and keyword values, even though ICU already contains the data and PHP already exposes adjacent display APIs.
	+
	+	Another important motivation is: as mentioned, php already has a family of Locale::getDisplay* functions, each matching with a corresponding ICU internal API. Now, every ICU internal API in the getDisplay* family has a php interface without ''%%uloc_getDisplayKeyword()%%'' and ''%%uloc_getDisplayKeywordValue()%%''. This change fills the little gap between ICU and php's userland interface.
	+
	+	In the past, similar changes have been done without a RFC. The locale::isRightToLeft function is added without a RFC procedure since it is a direct exposure to a ICU API that php didn't cover. See: https://github.com/php/php-src/issues/18345. This is also true in Locale::addLikelySubtags/Locale::minimizeSubtags. However, with further discussion with the current maintainer of the extension it is decided to go through a RFC process of this change.
	+
	+	==== API Details ====
	+
	+	=== locale_get_display_keyword() / Locale::getDisplayKeyword() ===
	+
	+	Returns a localized display label for a locale keyword, such as ''%%collation%%'' or ''%%calendar%%''.
	+
	+	The first parameter indicates the keyword to be displayed. The second parameter determines the display locale, if it is null, the display locale should be the current default locale.
	+
	+	Example intent:
	+
	+	<PHP>
	+	Locale::getDisplayKeyword('collation', 'en'); // should return the English display label for the ''%%collation%%'' keyword.
	+	Locale::getDisplayKeyword('currency', 'fr'); // should return the French display label for the ''%%calendar%%'' keyword.
	+	</PHP>
	+
	+	Procedural alias of ''%%Locale::getDisplayKeyword()%%'' is ''%%locale_get_display_keyword()%%''.
	+
	+	=== locale_get_display_keyword_value() / Locale::getDisplayKeywordValue() ===
	+
	+	Returns a localized display label for the value of a given locale keyword.
	+
	+	The first parameter is the locale string that carries the keyword value. The second parameter identifies which keyword should be resolved from that locale. Similar to the above function, the third parameter determines the display locale, if it is null, the display locale should be the current default locale.
	+
	+	Example intent:
	+
	+	<PHP>
	+	Locale::getDisplayKeywordValue(
	+	'de_DE@collation=phonebook',
	+	'collation',
	+	'en'
	+	); // should return the English display label for the ''%%phonebook%%'' collation value, which is "Phonebook Sort Order"
	+	</PHP>
	+
	+	Procedural alias of ''%%Locale::getDisplayKeywordValue()%%'' is ''%%locale_get_display_keyword_value()%%''.
	+
	+	===== Backward Incompatible Changes =====
	+
	+	There are no intentional backward incompatible changes to existing behavior.
	+
	+	(Unless a PHP application declares its own function with an identical name.)
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	PHP 8.6
	+
	+	===== RFC Impact =====
	+
	+	==== To the Ecosystem ====
	+
	+	This is a straightforward API addition. IDEs, LSPs, static analyzers, and documentation generators would need updated stubs so the new functions and methods are recognized.
	+
	+	Userland internationalization libraries and admin UIs may simplify their own locale metadata mapping code if they choose to adopt these APIs.
	+
	+	==== To Existing Extensions ====
	+
	+	No existing extension behavior should change.
	+
	+	==== To SAPIs ====
	+
	+	No SAPI-specific impact is expected.
	+
	+	===== Voting Choices =====
	+
	+	Starting at 5th June if no further discussion emerged
	+
	+	===== Patches and Tests =====
	+
	+	TBD
	+
	+	===== Implementation =====
	+
	+	TBD
	+
	+	===== References =====
	+
	+	* ICU ''%%uloc_getDisplayKeyword()%%'' and ''%%uloc_getDisplayKeywordValue()%%'': https:%%//%%unicode-org.github.io/icu-docs/apidoc/released/icu4c/uloc_8h.html
	+
	+	===== Rejected Features =====
	+
	+	None
	+
	+	===== Changelog =====
	+
	+	* 2026-05-22: Initial wiki-format draft created..

poll_api

bukka (bukka@undisclosed.example.com) — 2026-05-20T21:34:14+00:00

2026/05/20 21:33		current
Line 1034:		Line 1034:
	===== Patches and Tests =====		===== Patches and Tests =====

-	A working implementation is under development and will be available at https://github.com/php/php-src/pull/19572.	+	A working implementation is available at https://github.com/php/php-src/pull/19572.

	The implementation includes a complete test suite covering all backends and common use cases. The tests are designed		The implementation includes a complete test suite covering all backends and common use cases. The tests are designed

stream_errors - Close vote

bukka (bukka@undisclosed.example.com) — 2026-05-20T21:25:47+00:00

2026/05/06 10:05		current
Line 3:		Line 3:
	* Date: 2025-11-18		* Date: 2025-11-18
	* Author: Jakub Zelenka, bukka@php.net		* Author: Jakub Zelenka, bukka@php.net
-	* Status: Voting	+	* Status: Accepted

	===== Introduction =====		===== Introduction =====
Line 611:		Line 611:
	As per the voting RFC, a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.		As per the voting RFC, a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.

-	<doodle title="Should the Stream Error Handling Improvements be added to PHP core?" auth="bukka" voteType="single" closed="false" closeon="2026-05-18T22:00:00Z">	+	<doodle title="Should the Stream Error Handling Improvements be added to PHP core?" auth="bukka" voteType="single" closed="true" closeon="2026-05-18T22:00:00Z">
	* Yes		* Yes
	* No		* No
Line 617:		Line 617:
	</doodle>		</doodle>

-	The vote started on 2026-05-04 at 21:00 UTC and ends on 2026-05-18 at 22:00 UTC.	+	The vote started on 2026-05-04 at 21:00 UTC and ended on 2026-05-18 at 22:00 UTC.

	===== Patches and Tests =====		===== Patches and Tests =====

uri_followup

kocsismate (kocsismate@undisclosed.example.com) — 2026-05-20T05:11:03+00:00

2026/05/05 21:13		current
Line 3:		Line 3:
	* Date: 2025-10-17		* Date: 2025-10-17
	* Author: Máté Kocsis, kocsismate@php.net		* Author: Máté Kocsis, kocsismate@php.net
-	* Status: Voting	+	* Status: Accepted
	* Target version: next minor version (PHP 8.6)		* Target version: next minor version (PHP 8.6)
	* Implementation: https://github.com/kocsismate/php-src/pull/9		* Implementation: https://github.com/kocsismate/php-src/pull/9

array_get_and_array_has

barel (barel@undisclosed.example.com) — 2026-05-19T19:13:19+00:00

2026/05/18 19:56		current
Line 360:		Line 360:

	Discussion: https://news-web.php.net/php.internals/130559		Discussion: https://news-web.php.net/php.internals/130559
		+	Voting thread: https://news-web.php.net/php.internals/130947

	===== Changelog =====		===== Changelog =====

coroutine-lifecycle.svg - created

edmond (edmond@undisclosed.example.com) — 2025-04-16T07:24:46+00:00

	current

supervisor.svg - created

edmond (edmond@undisclosed.example.com) — 2025-03-16T08:38:59+00:00

	current

exception_flow.svg - created

edmond (edmond@undisclosed.example.com) — 2025-03-16T08:38:59+00:00

	current

resume_and_notifier.svg - created

edmond (edmond@undisclosed.example.com) — 2025-02-16T08:40:05+00:00

	current

basic.svg - created

edmond (edmond@undisclosed.example.com) — 2025-02-14T19:39:22+00:00

	current

speed.svg - created

divinity76 (divinity76@undisclosed.example.com) — 2025-01-24T09:50:19+00:00

	current

output_5_.png - created

divinity76 (divinity76@undisclosed.example.com) — 2025-01-24T09:47:20+00:00

	current