PHP Wiki

reflectionattribute-getcurrent - clarify table meaning

daniels (daniels@undisclosed.example.com) — 2026-05-04T02:44:14+00:00

2026/05/04 02:44		current
Line 172:		Line 172:
	* <php>ReflectionEnumBackedCase</php> is a subclass of <php>ReflectionEnumUnitCase</php> which is a subclass of <php>ReflectionClassConstant</php>		* <php>ReflectionEnumBackedCase</php> is a subclass of <php>ReflectionEnumUnitCase</php> which is a subclass of <php>ReflectionClassConstant</php>

-	To be clear, even when the <php>ReflectionAttribute</php> was retrieved from a different type, the return type will be the type listed in the table above. For example, using <php>ReflectionClassConstant</php> with an enum case works fine, but inside of any attribute constructors <php>ReflectionAttribute::getCurrent</php> will return the enum-specific subclass. Similarly, <php>ReflectionObject</php> can be used for classes and enums, but <php>ReflectionClass</php> or <php>ReflectionEnum</php> will be returne from <php>ReflectionAttribute::getCurrent()</php>	+	To be clear, even when the <php>ReflectionAttribute</php> was retrieved from a different type, the return type will be the type listed in the table above. For example, using <php>ReflectionClassConstant</php> with an enum case works fine, but inside of any attribute constructors <php>ReflectionAttribute::getCurrent()</php> will return the enum-specific subclass. Similarly, <php>ReflectionObject</php> can be used for classes and enums, but <php>ReflectionClass</php> or <php>ReflectionEnum</php> will be returne from <php>ReflectionAttribute::getCurrent()</php>

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====

session_security_defaults - Added abstain option to the voting

jorg_sowa (jorg_sowa@undisclosed.example.com) — 2026-05-03T16:48:35+00:00

2026/05/03 13:06		current
Line 109:		Line 109:
	* Yes		* Yes
	* No		* No
		+	* Abstain
	</doodle>		</doodle>

Line 116:		Line 117:
	* Yes		* Yes
	* No		* No
		+	* Abstain
	</doodle>		</doodle>

Line 123:		Line 125:
	* Yes		* Yes
	* No		* No
		+	* Abstain
	</doodle>		</doodle>

min_supported_versions_php_8_6 - created

enorris (enorris@undisclosed.example.com) — 2026-05-03T14:08:49+00:00

2026/05/04 11:46	current
Line 1:	Line 1:
	+	====== PHP RFC: Minimum supported versions for PHP 8.6 ======
	+	* Version: 0.1
	+	* Date: 2026-05-03
	+	* Author: Eric Norris, erictnorris@gmail.com
	+	* Status: Draft
	+
	+	===== Introduction =====
	+	This RFC proposes a slate of minimum supported software versions for PHP 8.6
	+
	+
	+	* MySQL 5.7.3 and MariaDB 10.2.4 for persistent connections, so we may use ''COM_RESET_CONNECTION''.
	+	* Autoconf 2.71 for builds from source, so we may use C11 standards.
	+
	+	===== Proposal =====
	+
	+	==== MySQL 5.7.3 and MariaDB 10.2.4 ====
	+
	+	MySQL 5.7.3 and MariaDB 10.2.4 introduced ''COM_RESET_CONNECTION'', a SQL command to reinitialize a connection's state without requiring reauthentication. This is important to be able to safely reuse connections across requests, i.e. persistent connections, without fear of being in an undesirable leftover state.
	+
	+	MySQL 5.7.3 was released on December 3rd, 2013 and reached its end-of-life alongside all 5.7 minor versions on October 25, 2023 (https://www.mysql.com/support/eol-notice.html).
	+
	+	MariaDB 10.2.4 was released on February 17th, 2017 and reached its end-of-life alongside all 10.2 minor versions on May 23rd, 2022 (https://endoflife.date/mariadb).
	+
	+	This RFC proposes that we use ''COM_RESET_CONNECTION'' in PDO and ''mysqlnd'' when reusing persistent connections. Users that are on MySQL or MariaDB databases from before this feature was implemented //may upgrade to PHP 8.6, but would not be able to use persistent connections//. This means that their software could continue to work, but they might lose a performance optimization.
	+
	+	===== Proposed PHP Version(s) =====
	+
	+	PHP 8.6
	+
	+	===== RFC Impact =====
	+
	+	==== To the Ecosystem ====
	+
	+	None expected.
	+
	+	==== To Existing Extensions ====
	+
	+	* PDO and ''mysqlnd'': users on versions of MySQL and MariaDB before ''COM_RESET_CONNECTION'' was implemented may not use persistent connections.
	+
	+	==== To SAPIs ====
	+
	+	===== Open Issues =====
	+
	+
	+	===== Future Scope =====
	+
	+
	+	===== Voting Choices =====
	+
	+	Each proposal is voted on separately and requires a 2/3 majority:
	+
	+	----
	+
	+	<doodle title="Implement COM_RESET_CONNECTION requirement as outlined in the RFC?" voteType="single" closed="true" closeon="2026-01-01T15:30:00Z">
	+	* Yes
	+	* No
	+	* Abstain
	+	</doodle>
	+
	+	===== Patches and Tests =====
	+
	+	* ''COM_RESET_CONNECTION'' https://github.com/php/php-src/pull/21857
	+
	+	===== Implementation =====
	+
	+	===== References =====
	+	Links to external references, discussions, or RFCs.
	+
	+	===== Rejected Features =====
	+
	+	===== Changelog =====

release_manager_selection_policy

timwolla (timwolla@undisclosed.example.com) — 2026-05-03T13:08:40+00:00

2026/03/27 18:21		current
Line 70:		Line 70:

	* 2026-03-27: Initial version		* 2026-03-27: Initial version
		+	* 2026-05-03: Various changes to clarify and streamline the terminology

rfc - moved Session security defaults to voting phase

jorg_sowa (jorg_sowa@undisclosed.example.com) — 2026-05-03T12:34:08+00:00

2026/05/01 15:14		current
Line 15:		Line 15:
	* [[rfc:snmp_improvements_2026\|SNMP Improvements]] (Created 2026-03-30; voting started 2026-04-21, ends 2026-05-08)		* [[rfc:snmp_improvements_2026\|SNMP Improvements]] (Created 2026-03-30; voting started 2026-04-21, ends 2026-05-08)
	* [[rfc:display_error_function_args \| Display Function Arguments in Errors]] (Created 2026-03-09; voting started 2026-05-01, ends 2026-05-15)		* [[rfc:display_error_function_args \| Display Function Arguments in Errors]] (Created 2026-03-09; voting started 2026-05-01, ends 2026-05-15)
		+	* [[rfc:session_security_defaults\|Session security defaults]] (Created 2026-04-04)

	===== Under Discussion =====		===== Under Discussion =====
Line 25:		Line 26:
	* [[rfc:remove-link-to-x-from-php-net\|Remove the links to X.com from PHP.net]] (Created 2026-04-12)		* [[rfc:remove-link-to-x-from-php-net\|Remove the links to X.com from PHP.net]] (Created 2026-04-12)
	* [[rfc:mariadb_rfc\|Add MariaDB specific features to mysqlnd and mysqli]] (Created 2026-04-06)		* [[rfc:mariadb_rfc\|Add MariaDB specific features to mysqlnd and mysqli]] (Created 2026-04-06)
-	* [[rfc:session_security_defaults\|Session security defaults]] (Created 2026-04-04)
	* [[rfc:array_get_and_array_has\|array_path_get and array_path_exists functions]] (Created 2026-04-04)		* [[rfc:array_get_and_array_has\|array_path_get and array_path_exists functions]] (Created 2026-04-04)
	* [[rfc:override_constants\|#[\Override] for class constants]] (created 2026-03-13)		* [[rfc:override_constants\|#[\Override] for class constants]] (created 2026-03-13)

exists-magic-method

nicolasgrekas (nicolasgrekas@undisclosed.example.com) — 2026-05-02T20:15:09+00:00

2026/05/02 20:03		current
Line 133:		Line 133:
	==== Sequencing ====		==== Sequencing ====

-	The rules below apply only when a class defines <php>__exists()</php>. When it does not, the engine's	+	The rules below apply only when a class defines <php>__exists()</php>. Classes that do not define
-	behaviour is unchanged from previous versions: ''isset()''/''empty()''/''??'' fall through to	+	it observe the engine's existing behaviour unchanged; that behaviour is laid out in full under
-	the usual <php>__isset()</php> and <php>__get()</php> sequencing.	+	[[#existing_sequencing\|Existing sequencing]] near the end of this RFC.

	For ''$obj->prop ?? $y'':		For ''$obj->prop ?? $y'':
Line 502:		Line 502:
	Discussed in the Rationale section: it is a plausible long-term direction but uncommitted, and		Discussed in the Rationale section: it is a plausible long-term direction but uncommitted, and
	deliberately left for a future RFC.		deliberately left for a future RFC.
		+
		+	===== Existing sequencing =====
		+
		+	For completeness and to make the migration story concrete, here is the engine's behaviour today
		+	when a class does not define <php>__exists()</php>. Adding <php>__exists()</php> to a class swaps the rules
		+	under [[#sequencing\|Sequencing]] above into use; classes that do not opt in observe the rules
		+	below unchanged.
		+
		+	==== With __isset() defined (with or without __get()) ====
		+
		+	For ''$obj->prop ?? $y'':
		+
		+	- Call <php>__isset($prop)</php>.
		+	- If it returns ''false'', ''??'' evaluates ''$y''. <php>__get()</php> is not called.
		+	- If it returns ''true'', <php>__get($prop)</php> is called (when defined) and ''??'' applies its usual ''null'' check on top of the return value. <php>__get()</php> is called even when <php>__isset()</php> just wrote into the property table; this is the GH-12695 sequencing issue described in the Problem Statement.
		+
		+	For ''isset($obj->prop)'':
		+
		+	- Call <php>__isset($prop)</php>. Its return (cast to ''bool'') is the result. <php>__get()</php> is not called, even when the underlying value is in fact ''null''. This is the divergence from ''??'' described in the Problem Statement: ''isset()'' trusts the bool, ''??'' applies a ''null'' check on top of <php>__get()</php>.
		+
		+	For ''empty($obj->prop)'':
		+
		+	- Call <php>__isset($prop)</php>.
		+	- If it returns ''false'', ''empty()'' returns ''true''. <php>__get()</php> is not called.
		+	- If it returns ''true'', <php>__get($prop)</php> is called (when defined) and ''empty()'' returns whether its return value is falsy. When <php>__get()</php> is not defined, ''empty()'' returns ''true''.
		+
		+	==== With only __get() defined (no __isset()) ====
		+
		+	* ''$obj->prop ?? $y'': <php>__get($prop)</php> is called and ''??'' applies its usual ''null'' check on top.
		+	* ''isset($obj->prop)'': always returns ''false''. <php>__get()</php> is not called.
		+	* ''empty($obj->prop)'': always returns ''true''. <php>__get()</php> is not called.
		+
		+	This is one source of the "broken `isset()` on magic properties" reputation: a class with only
		+	<php>__get()</php> sees ''isset()'' return ''false'' even when <php>__get()</php> would happily produce a non-null
		+	value. Defining <php>__exists()</php> (even one that always returns ''true'') fixes this without forcing
		+	the class to also implement <php>__isset()</php>.
		+
		+	==== With neither __isset() nor __exists() (and no __get()) ====
		+
		+	The standard "undefined property" path applies: ''$obj->prop ?? $y'' returns ''$y'' silently
		+	(after a notice on direct read), ''isset($obj->prop)'' returns ''false'', ''empty($obj->prop)''
		+	returns ''true''.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====

display_error_function_args

calvinb (calvinb@undisclosed.example.com) — 2026-05-02T18:09:56+00:00

2026/05/01 15:14		current
Line 147:		Line 147:
	This vote requires a simple majority, and determines if error_include_args is set for tests, and to update all tests in the php-src repository that feature errors with function parameters. If there's a tie, this will default to "0":		This vote requires a simple majority, and determines if error_include_args is set for tests, and to update all tests in the php-src repository that feature errors with function parameters. If there's a tie, this will default to "0":

-	<doodle title="If error_include_args defaults to 1, default value in run-tests.php" voteType="single closeon="2026-05-15T21:00:00Z">	+	<doodle title="If error_include_args defaults to 1, default value in run-tests.php" voteType="single" closeon="2026-05-15T21:00:00Z">
	* "1"		* "1"
	* "0"		* "0"

array_get_and_array_has

barel (barel@undisclosed.example.com) — 2026-05-02T07:27:12+00:00

2026/04/25 19:34		current
Line 1:		Line 1:
	====== PHP RFC: array_path_get and array_path_exists functions ======		====== PHP RFC: array_path_get and array_path_exists functions ======
-	* Version: 0.7	+	* Version: 0.8
-	* Date: 2026-04-25	+	* Date: 2026-05-02
	* Author: Carlos Granados, barel.barelon@gmail.com		* Author: Carlos Granados, barel.barelon@gmail.com
	* Status: Under discussion		* Status: Under discussion
Line 166:		Line 166:
	foreach ($path as $segment) {		foreach ($path as $segment) {
	if (!is_string($segment) && !is_int($segment)) {		if (!is_string($segment) && !is_int($segment)) {
-	throw new \TypeError('Path segment must be of type string\|int');	+	throw new TypeError('array_path_get(): Argument #2 ($path) must only contain keys of type string or int');
	}		}
		+	}

		+	foreach ($path as $segment) {
	if (!is_array($array) \|\| !array_key_exists($segment, $array)) {		if (!is_array($array) \|\| !array_key_exists($segment, $array)) {
	return $default;		return $default;
Line 191:		Line 193:
	foreach ($path as $segment) {		foreach ($path as $segment) {
	if (!is_string($segment) && !is_int($segment)) {		if (!is_string($segment) && !is_int($segment)) {
-	throw new \TypeError('Path segment must be of type string\|int');	+	throw new TypeError('array_path_exists(): Argument #2 ($path) must only contain keys of type string or int');
	}		}
		+	}

		+	foreach ($path as $segment) {
	if (!is_array($array) \|\| !array_key_exists($segment, $array)) {		if (!is_array($array) \|\| !array_key_exists($segment, $array)) {
	return false;		return false;
Line 202:		Line 206:

	return true;		return true;
-	}</PHP>	+	}
		+	</PHP>

	* Each path segment is applied sequentially		* Each path segment is applied sequentially
Line 366:		Line 371:
	* 2026-04-18: Modify function names to array_path_get and array_path_exists		* 2026-04-18: Modify function names to array_path_get and array_path_exists
	* 2026-04-25: Clarify the behaviour when any part of the path is not a valid key		* 2026-04-25: Clarify the behaviour when any part of the path is not a valid key
		+	* 2026-05-02: Update the sample functions to match the described behaviour when any of the path keys is not a valid key

remove-link-to-x-from-php-net - Add additional clarification about why

jimw (jimw@undisclosed.example.com) — 2026-05-02T01:39:13+00:00

2026/04/12 18:37		current
Line 8:		Line 8:
	===== Proposal =====		===== Proposal =====

-	The PHP project has not posted to its account on X (formerly known as Twitter) since 2023 and due to to the current nature of the site, there is no reason for the project to have a presence there and the links to the now-dormant account should be removed from PHP.net.	+	The PHP project has not posted to its account on X (formerly known as Twitter) since 2023. Due to to the current nature of the site as a political project of a transphobic and white supremacist owner, there is no reason for the PHP project to have a presence there and the links to the now-dormant account should be removed from PHP.net.

	===== RFC Impact =====		===== RFC Impact =====
Line 32:		Line 32:
	===== References =====		===== References =====

-	[[https://www.eff.org/deeplinks/2026/04/eff-leaving-x\|The EFF's post about leaving X.]]	+	* [[https://www.eff.org/deeplinks/2026/04/eff-leaving-x\|The EFF's post about leaving X.]]
		+	* [[https://www.wired.com/story/musk-trump-support-x/\|Wired article about the political nature of Twitter]]

	Discussion: https://news-web.php.net/php.internals/130610		Discussion: https://news-web.php.net/php.internals/130610
Line 40:		Line 41:
	* 2026-04-12: Initial version.		* 2026-04-12: Initial version.
	* 2026-04-12: Clarified that the account is dormant, not outside of project control		* 2026-04-12: Clarified that the account is dormant, not outside of project control
		+	* 2026-05-01: Clarified what was meant by the current nature of the site

uri_followup

kocsismate (kocsismate@undisclosed.example.com) — 2026-05-01T07:06:03+00:00

2026/04/30 18:57		current
Line 649:		Line 649:

	<code php>		<code php>
-	$uri = new Uri\Rfc3986\Uri("https://example.com/?a=b%26c"); // The query is the percent-encoded form of "a=b&c=d"	+	$uri = new Uri\Rfc3986\Uri("https://example.com/?a=b%26c"); // The query is the percent-encoded form of "a=b&c"

	echo Uri\Rfc3986\uri_percent_decode(		echo Uri\Rfc3986\uri_percent_decode(

context-managers - Add more examples of when a CM would suppress exceptions

crell (crell@undisclosed.example.com) — 2026-04-30T18:21:35+00:00

2026/04/30 18:21		current
Line 630:		Line 630:
	}		}

-	public function enterContext(): void	+	// Nothing to do here.
-	{	+	public function enterContext(): void {}
-	// Nothing to do here.	+
-	}	+

	public function exitContext(?\Throwable $e = null): ?Throwable		public function exitContext(?\Throwable $e = null): ?Throwable
Line 666:		Line 664:
	}		}

-	public function enterContext(): void	+	// Nothing to do here.
-	{	+	public function enterContext(): void {}
-	// Nothing to do here.	+
-	}	+

	public function exitContext(?\Throwable $e = null): ?Throwable		public function exitContext(?\Throwable $e = null): ?Throwable

social-media-policy - created

pronskiy (pronskiy@undisclosed.example.com) — 2026-04-30T15:39:36+00:00

2026/05/04 11:46	current
Line 1:	Line 1:
	+	<!DOCTYPE markdown>
	+	# PHP RFC: Social Media and Marketing Communications Policy
	+
	+	* Version: 1.0
	+	* Date: 2026-04-30
	+	* Author: Roman Pronskiy (roman@pronskiy.com)
	+	* Status: Draft
	+	* First Published at: http://wiki.php.net/rfc/social-media-policy
	+
	+	## Introduction
	+
	+	PHP is one of the most widely used programming languages in the world. Despite this remarkable success, PHP has long been perceived by parts of the broader tech community as declining or "dead" – a narrative that is demonstrably false but nonetheless persists.
	+
	+	One significant factor contributing to this perception gap is PHP's lack of coordinated marketing and communications efforts. While individual community members, conferences, and the PHP Foundation actively promote PHP through various channels, the official PHP project itself has no formal policy governing its presence on social media or other communication platforms.
	+
	+	This RFC proposes establishing a formal policy for PHP's official social media presence and marketing communications, ensuring that the PHP project can effectively communicate with its community and the broader technology ecosystem.
	+
	+	## Problem Statement
	+
	+	### The Current Situation
	+
	+	PHP currently maintains several official social media accounts, most notably:
	+
	+	* Twitter/X ([@official\_php](https://twitter.com/official_php)): \~109,000 followers, last post: Jun 4, 2024. The account is silent not due to a project decision but because the individual credential holder ceased posting unilaterally. Multiple requests to share credentials, transfer custody, or enable automated posting (as is done for Mastodon) have not been accommodated. Under current practice, no formal mechanism exists to compel transfer or define succession.
	+	* Mastodon ([@php@fosstodon.org](https://fosstodon.org/@php)): \~5,000 followers, automated release announcements
	+	* LinkedIn ([@phpnet](https://www.linkedin.com/company/phpnet/)) : \~225,000 followers, semi-actively updated by Kalle / The PHP Foundation members
	+
	+	The disparity is stark. The Twitter account, with over 100,000 followers – a substantial audience for any programming language – has been silent for nearly two years. Meanwhile, the Mastodon account operates with automated posting, demonstrating that minimal-effort communication is both technically feasible and operationally sustainable.
	+
	+	### Engagement
	+
	+	Apart from followers, we can use PHP’s analytics data as a proxy metric to estimate engagement acquired from different social media.
	+
	+	For April 2026, the data looks as follows:
	+
	+	\| Social Network \| Visits \| Share \|
	+	\|----------------\|-------:\|-------:\|
	+	\| YouTube \| 5,373 \| 33.66% \|
	+	\| Reddit \| 2,915 \| 18.26% \|
	+	\| X/Twitter \| 2,102 \| 13.17% \|
	+	\| StackOverflow \| 2,068 \| 12.96% \|
	+	\| Facebook \| 2,048 \| 12.83% \|
	+	\| LinkedIn \| 675 \| 4.23% \|
	+	\| Telegram \| 205 \| 1.28% \|
	+	\| Hacker News \| 166 \| 1.04% \|
	+	\| Vkontakte \| 154 \| 0.96% \|
	+	\| Sourceforge \| 98 \| 0.61% \|
	+	\| Instagram \| 58 \| 0.36% \|
	+	\| Mastodon \| 37 \| 0.23% \|
	+	\| Workplace \| 16 \| 0.10% \|
	+	\| V2EX \| 15 \| 0.09% \|
	+	\| Bluesky \| 14 \| 0.09% \|
	+	\| Threads \| 12 \| 0.08% \|
	+
	+	Among platforms in scope of this policy, X/Twitter accounts
	+	for 13.17% of social referral traffic, more than LinkedIn (4.23%)
	+	and Mastodon (0.23%) combined. This traffic is generated despite
	+	the X account being dormant since June 2024. An active automated
	+	account would expand reach.
	+
	+	### Why This Matters
	+
	+	1. Perception shapes reality: When developers research PHP, a dormant official Twitter account with the last activity from almost two years ago reinforces the "PHP is dead" narrative, regardless of the language's actual vitality and continued development.
	+
	+	2. Missed communication opportunities: PHP 8.5 was released in November 2025 with significant new features. The official Twitter account with its 109,000 followers said nothing. This represents a missed opportunity to reach developers who may have been unaware of PHP's continued evolution.
	+
	+	3. Community frustration: There have been repeated requests from the PHP community for better marketing and communication. This RFC responds to those requests with a concrete, actionable proposal.
	+
	+	4. Competitive disadvantage: Other programming languages actively maintain their social media presence. Python, TypeScript, and Go all have active official communications. PHP's silence is conspicuous by comparison.
	+
	+	### The Governance Gap
	+
	+	Currently, credentials for official PHP social media accounts are held by individual community members without clear governance policies. While these individuals have historically acted in good faith, the absence of formal policy creates several issues:
	+
	+	* No defined process for posting decisions
	+	* No mechanism for the community to request or approve communications
	+	* No succession planning if credential holders become unavailable
	+	* No accountability structure for the community at large
	+
	+	## Proposal
	+
	+	This RFC proposes adopting a formal Social Media and Marketing Communications Policy for the PHP project. The specific policy text will be submitted to https://github.com/php/policies after RFC approval.
	+
	+	### Core Principles
	+
	+	The policy is built on the following principles:
	+
	+	1. Representation: PHP should maintain an official presence on any platform with significant reach to developers.
	+
	+	2. Automation first: Where feasible, communications should be automated to minimize volunteer burden and ensure consistency.
	+
	+	3. Neutrality: Official PHP communications should focus on the language itself, releases, security advisories, and community events — not on platform politics or endorsements.
	+
	+	4. Shared stewardship: Credentials for official accounts should be held by multiple trusted community members, with clear succession policies.
	+
	+	5. Transparency: Policies governing official communications should be documented and publicly available.
	+
	+	### Governance Structure
	+
	+	This policy establishes clear roles and responsibilities for PHP's official communications:
	+
	+	#### Infrastructure Team: Account Custody
	+
	+	The PHP Infrastructure Team is responsible for:
	+
	+	* Holding credentials for all official PHP social media accounts
	+	* Maintaining secure credential storage with multiple authorized holders (minimum three)
	+	* Implementing and maintaining automation for cross-platform posting
	+	* Ensuring credential succession when holders step down
	+	* Technical operations: posting, account recovery, platform compliance
	+
	+	This is a purely technical and operational role. The Infrastructure Team executes communications but does not determine content strategy.
	+
	+	#### PHP Foundation: Content Authority
	+
	+	The PHP Foundation is designated as the decision-maker for PHP's official communications:
	+
	+	* Content decisions: The Foundation determines what gets posted on official channels, including messaging, timing, and tone
	+	* Strategic direction: The Foundation advises on platform presence, audience strategy, and communications priorities
	+	* Marketing initiatives: Any proactive marketing efforts beyond automated announcements are delegated to the Foundation
	+	* Consultation: The Foundation serves as consultant to the PHP project on all marketing and communications matters
	+
	+	This separation ensures that those with marketing expertise and organizational capacity (the Foundation) drive content decisions, while technical implementation remains with the Infrastructure Team.
	+
	+	#### Why This Division of Responsibilities?
	+
	+	1. Expertise alignment: The Foundation has staff experienced in developer relations and marketing. The Infrastructure Team has expertise in systems and automation.
	+
	+	2. Organizational capacity: Marketing requires sustained attention and strategic thinking. The Foundation, as an organization with staff, can provide this more reliably than individual volunteers.
	+
	+	3. Clear accountability: With defined roles, it's clear who is responsible for what. Content questions go to the Foundation; technical issues go to Infrastructure.
	+
	+	4. Separation of concerns: Account credentials and content
	+	decisions follow different operational logic. Custody belongs
	+	with infrastructure expertise; content belongs with
	+	communications expertise.
	+
	+	5. Scalability: As PHP's communications needs grow, the Foundation can scale its marketing efforts without requiring changes to account custody.
	+
	+	#### Alternative Considered: Joint Content Committee
	+
	+	An alternative considered was a joint committee composed of Foundation
	+	representatives and volunteer Internals contributors. This was rejected
	+	in favor of the current proposal for the following reasons:
	+
	+	- The Foundation already has accountability to the PHP community
	+	through its membership and governance.
	+	- Adding an elected internals component would create elections,
	+	terms, and replacement procedures that increase governance
	+	overhead disproportionate to the scope (which is operational
	+	communications, not project direction).
	+	- The Foundation's content decisions remain subject to community
	+	oversight via future RFCs that can amend this policy.
	+
	+	If the community prefers the joint-committee model, this RFC can be
	+	amended during discussion to incorporate it.
	+
	+	### Platforms and Scope
	+
	+	#### Text-Based Platforms (In Scope)
	+
	+	The following platforms have significant developer audiences and can be served with automated or low-effort text-based communications:
	+
	+	\| Platform \| Audience Size \| Status \| Proposed Action \|
	+	\|:----------\|:-----------------\|:-----------------------\|:------------------------------------\|
	+	\| Twitter/X \| \~109K followers \| Dormant since Jun 2024 \| Reactivate with automation \|
	+	\| Mastodon \| \~5K followers \| Active (automated) \| Continue current approach \|
	+	\| LinkedIn \| \~225K followers \| Active (not automated) \| Automate, continue current approach \|
	+
	+	#### Video Platforms (Out of Scope)
	+
	+	Platforms such as YouTube, TikTok, and Instagram require significant resources for video content creation that the PHP project does not currently have. These platforms are explicitly out of scope for this RFC but may be addressed in future proposals if resources become available.
	+
	+	### Content Types and Authority
	+
	+	#### Automated Content (No Approval Required)
	+
	+	The following content types are suitable for fully automated cross-platform posting, requiring no per-post approval:
	+
	+	* Release announcements (major, minor, patch versions)
	+	* Security advisories and CVE announcements
	+	* RFC voting results
	+	* Conference and event announcements
	+
	+	These are triggered automatically by project events (release announcements, security commits, vote closures).
	+
	+	#### Curated Content (Foundation Authority)
	+
	+	The following content types require Foundation approval before posting:
	+
	+	* Milestone announcements
	+	* Anniversary and celebration posts
	+	* Blog post promotions
	+	* Any other non-automated content
	+
	+	#### Marketing Initiatives (Foundation Led)
	+
	+	Any proactive marketing efforts beyond the above categories are delegated to the PHP Foundation:
	+
	+	* Coordinated campaigns
	+	* Responses to industry narratives
	+	* Developer outreach initiatives
	+	* Cross-promotion with ecosystem projects
	+
	+	The Foundation may pursue such initiatives at its discretion, coordinating with the Infrastructure Team for technical execution.
	+
	+	### Implementation
	+
	+	#### Technical Approach
	+
	+	The Mastodon account already mostly operates under the model proposed by this RFC: automated posting via GitHub Actions for releases, no per-post overhead. It demonstrates that the proposed model is technically feasible and operationally sustainable.
	+
	+	Following the Mastodon model, automated posting will be implemented via GitHub Actions and Pull Requests where possible.
	+
	+	#### Credential Management
	+
	+	* Minimum three (3) Infrastructure Team members shall hold credentials for each official account
	+	* Credentials shall be stored securely with documented access procedures
	+	* When a credential holder steps down, replacement shall be coordinated within 30 days
	+	* Emergency access procedures shall be documented and tested
	+
	+	#### Transition Plan
	+
	+	Upon adoption of this RFC:
	+
	+	1. The Infrastructure Team will inventory all accounts currently
	+	representing PHP officially across platforms.
	+	2. Current credential holders will be requested to transfer
	+	credentials to Infrastructure Team secure storage within 60
	+	days.
	+	3. If a credential holder declines or does not respond within 60
	+	days, the Foundation and Infrastructure Team will jointly
	+	determine whether to:
	+	a. Petition the platform for account recovery (where supported);
	+	b. Establish a new official account on that platform;
	+	c. Mark the original account as non-official on PHP.net.
	+	4. For platforms where no current account exists (e.g., Bluesky),
	+	the Foundation may direct creation of an official account once
	+	this policy is in effect.
	+
	+	#### If This RFC Does Not Pass
	+
	+	If this RFC fails, the project will continue without formal
	+	governance over communications. In that case, individual platform
	+	decisions (including the pending X/Twitter link removal) should
	+	each go through their own RFC, with the understanding that each
	+	such decision creates ad-hoc precedent rather than systematic
	+	policy.
	+
	+	## Addressing Platform Concerns
	+
	+	### On the Pending Link Removal
	+
	+	A separate RFC and PR propose removing the X/Twitter link from PHP.net on
	+	the basis that the account is dormant. This RFC takes the position that
	+	the link should not be removed at this time, on procedural rather than
	+	substantive grounds:
	+
	+	1. The dormancy resulted from a unilateral action by one credential
	+	holder, not from a project decision. Removing the link ratifies that
	+	outcome retroactively and treats the absence of governance as
	+	equivalent to a project consensus.
	+
	+	2. The link represents a project-level commitment. Allowing one
	+	individual to effectively undo it through inaction sets a precedent
	+	that any credential holder can force project-wide outcomes by
	+	becoming non-responsive.
	+
	+	3. Once governance is in place, the question of whether to maintain
	+	each platform becomes a content decision within a defined process.
	+	At that point, removing or keeping the link reflects an actual
	+	project decision and can be made on its merits.
	+
	+	This RFC therefore proposes that link-removal questions be deferred
	+	until the governance framework is adopted.
	+
	+	### On Twitter/X Ownership
	+
	+	The relevant question is not whether PHP endorses platform ownership
	+	— maintaining a presence on X/Twitter does not endorse X/Twitter's
	+	ownership any more than maintaining a GitHub presence endorses
	+	Microsoft's.
	+
	+	By maintaining presence across multiple platforms (X/Twitter, Mastodon, LinkedIn), PHP avoids dependence on any single platform and reaches developers wherever they prefer to be.
	+
	+	Major open-source projects and organisations (TypeScript, Golang, OpenJS Foundation, Python Software Foundation, Apache Foundation, Linux Foundation) maintain X/Twitter accounts.
	+
	+	That said, this RFC does not require PHP to maintain an X presence.
	+	It establishes a process. If the PHP Foundation, operating under the
	+	content authority defined here, determines that X is no longer an
	+	appropriate channel for PHP communications, the Foundation can pause
	+	or end posting. The decision becomes accountable, documented, and
	+	reversible — rather than the result of one person's inaction.
	+
	+	## Backward Compatibility
	+
	+	This RFC establishes a new policy and does not affect any existing PHP functionality or code.
	+
	+	## Impact on Existing Account Holders
	+
	+	Current holders of official PHP social media credentials will be asked to:
	+
	+	1. Transfer credentials to the Infrastructure Team's secure storage
	+	2. Participate in the new governance structure if willing and if they are Infrastructure Team members
	+	3. Acknowledge the Foundation's content authority going forward
	+
	+	No individual's contributions or historical stewardship are diminished by this policy. This RFC seeks to formalize and extend existing practices, not to criticize past volunteers.
	+
	+	## Frequently Asked Questions
	+
	+	### Why give content authority to the PHP Foundation?
	+
	+	The Foundation has the organizational structure, staff, and expertise to make consistent, strategic communications decisions. The Foundation's mission—supporting PHP—aligns perfectly with effective PHP marketing.
	+
	+	### What if the Foundation decides to discontinue posting on a platform like X?
	+
	+	The Foundation's content authority includes the discretion to pause
	+	or end official posting on any platform when it determines doing so
	+	serves PHP's communications goals or community interests. Such a
	+	decision would be documented and reversible. The point of this
	+	framework is that platform decisions become deliberate,
	+	accountable, and revisitable — not the result of inaction or
	+	unilateral choices by individual credential holders.
	+
	+	### Does the Foundation control the accounts?
	+
	+	No. The Infrastructure Team holds credentials and operates the accounts. The Foundation decides what content gets posted. This is similar to how a marketing department works with an IT department: marketing decides the message, IT manages the systems.
	+
	+	### What if the Infrastructure Team disagrees with Foundation content decisions?
	+
	+	The policy establishes the Foundation as the content authority. The Infrastructure Team's role is technical execution, not content approval. If significant concerns arise about specific content, they should be raised with the Foundation board directly.
	+
	+	### Can this arrangement be changed?
	+
	+	Yes. This policy can be amended by a future RFC with 2/3 majority approval. The community retains ultimate authority over PHP project policies.
	+
	+	### What about platform-specific content?
	+
	+	Automated posts will be adapted to platform conventions (e.g., character limits, hashtag practices) but will contain equivalent information across all platforms. Platform-specific strategies beyond basic adaptation are at the Foundation's discretion.
	+
	+	### Can individuals still post about PHP on their personal accounts?
	+
	+	Absolutely. This policy governs only official PHP project accounts. Community members, Foundation staff, and core developers are encouraged to continue personal advocacy for PHP.
	+
	+	### Doesn't the PHP Foundation already do marketing?
	+
	+	The Foundation markets itself and promotes PHP through its own channels. This RFC specifically addresses the official PHP project accounts (like @official\_php), which are distinct from the Foundation's accounts. This policy creates a formal relationship where the Foundation also guides the project's official communications.
	+
	+	### Does the Foundation have capacity for this?
	+
	+	The Foundation employs developers and engages staff and volunteers
	+	with experience in developer relations and communications. Most content
	+	under this policy is automated (releases, security, votes), with
	+	curated content and marketing initiatives within the Foundation's
	+	existing operational scope. The policy does not require the
	+	Foundation to expand staffing; it formalizes responsibilities the
	+	Foundation is already structurally suited to carry out.
	+
	+	## Proposed Voting Choices
	+
	+	A single yes-or-no vote on the policy as a whole, requiring 2/3 majority.
	+
	+	## References
	+
	+	* [RFC: PHP.net Analytics Collection](https://wiki.php.net/rfc/phpnet-analytics)
	+	* [RFC: Policy on 3rd party code](https://wiki.php.net/rfc/third-party-code)
	+	* [PHP Policies Repository](https://github.com/php/policies)
	+	* [The PHP Foundation](https://thephp.foundation/)
	+	* [@official\_php on Twitter/X](https://twitter.com/official_php)
	+	* [@php on Fosstodon](https://fosstodon.org/@php)
	+
	+	## Changelog
	+
	+	* 2026-04-30: Initial draft
	+
	+	---
	+
	+	## Appendix A: Proposed Policy Document
	+
	+	To be added to [https://github.com/php/policies](https://github.com/php/policies)
	+
	+	```
	+	# Social Media and Marketing Communications Policy
	+
	+	## Purpose
	+
	+	This policy governs the PHP project's official presence on social media and other
	+	communication platforms, establishing clear roles for account custody and content
	+	authority.
	+
	+	## Scope
	+
	+	This policy applies to all accounts officially representing the PHP project,
	+	including but not limited to:
	+	- Twitter/X (@official_php)
	+	- Mastodon (@php@fosstodon.org)
	+	- LinkedIn (@phpnet)
	+
	+	## Principles
	+
	+	1. Reach: PHP shall consider maintaining presence on all platforms with significant developer audiences.
	+	2. Automation: Communications shall be automated where feasible.
	+	3. Neutrality: Communications shall focus on PHP, not platform politics.
	+	4. Shared Stewardship: Multiple credential holders shall manage each account.
	+	5. Transparency: This policy shall be public and versioned.
	+
	+	## Roles and Responsibilities
	+
	+	### Infrastructure Team: Account Custody
	+
	+	The Infrastructure Team is responsible for:
	+	- Credential custody (minimum 3 holders per account)
	+	- Secure credential storage and succession
	+	- Automation implementation and maintenance
	+	- Technical posting operations
	+
	+	### PHP Foundation: Content Authority
	+
	+	The PHP Foundation is responsible for:
	+	- Content decisions (what, when, messaging, tone)
	+	- Strategic communications direction
	+	- Marketing initiatives beyond automated content
	+	- Consultation on communications matters
	+
	+	## Content Guidelines
	+
	+	### Automated Content (No Approval Required)
	+	- Release announcements
	+	- Security advisories
	+	- RFC voting results
	+
	+	### Curated Content (Foundation Approval Required)
	+	- Conference/event announcements
	+	- Documentation milestones
	+	- Celebrations and anniversaries
	+	- Blog post promotions
	+
	+	### Marketing Initiatives (Foundation Led)
	+	- Coordinated campaigns
	+	- Narrative responses
	+	- Developer outreach
	+	- Ecosystem cross-promotion
	+
	+	### Prohibited Content
	+	- Political statements unrelated to PHP
	+	- Commercial endorsements of products or services unrelated to PHP
	+	- Personal opinions presented as PHP's official position
	+	- Code of Conduct violations
	+	- Personal grievances or interpersonal disputes between contributors
	+
	+	## Implementation
	+
	+	Automated posting via GitHub Actions, extending the existing Mastodon model
	+	to all platforms.
	+
	+	## Amendments
	+
	+	This policy may be amended by RFC with 2/3 majority approval.
	+	```

eol-oniguruma - Implemented for deprecate mbregex

youkidearitai (youkidearitai@undisclosed.example.com) — 2026-04-28T02:08:12+00:00

2026/04/25 04:57		current
Line 3:		Line 3:
	* Date: 2025-08-21		* Date: 2025-08-21
	* Author: Yuya Hamada youkidearitai@gmail.com		* Author: Yuya Hamada youkidearitai@gmail.com
-	* Status: Accepted	+	* Status: Implemented
	* Implementation: https://github.com/php/php-src/pull/21490		* Implementation: https://github.com/php/php-src/pull/21490

deprecate-metaphone - add link to implementation

lamentxu (lamentxu@undisclosed.example.com) — 2026-04-27T14:41:26+00:00

2026/04/26 08:21		current
Line 4:		Line 4:
	* Author: Weilin Du, lamentxu@163.com		* Author: Weilin Du, lamentxu@163.com
	* Status: Under Discussion		* Status: Under Discussion
-	* Implementation: TBD	+	* Implementation: https://github.com/php/php-src/pull/21889

	===== Introduction =====		===== Introduction =====
Line 50:		Line 50:
	* Abstain		* Abstain
	</doodle>		</doodle>
-
-	===== Patches and Tests =====
-	TBD

	===== Implementation =====		===== Implementation =====
-	TBD	+	https://github.com/php/php-src/pull/21889

	===== Reference =====		===== Reference =====

scope-functions - created

edorian (edorian@undisclosed.example.com) — 2026-04-26T15:07:35+00:00

2026/04/26 15:07		current
Line 6:		Line 6:
	* Status: Draft		* Status: Draft
	* Target: PHP 8.6		* Target: PHP 8.6
		+	* Implementation: Draft at https://github.com/php/php-src/compare/master...bwoebi:php-src:scope_fn

	===== Introduction =====		===== Introduction =====
Line 241:		Line 242:
	</code>		</code>

-	* Recursion: All forms of recursion are all forbidden and raise an ''Error'' at the recursive call.	+	* Recursion: Recursive calls will raise an ''Error''.
		+	<code>
		+	Fatal error: Uncaught Error: Cannot recursively call scope function in %s:%d
		+	</code>

	* Cloning: ''clone $fn'' on a scope function raises an ''Error''. Two clones would share the same parent scope, interfering with each other's state.		* Cloning: ''clone $fn'' on a scope function raises an ''Error''. Two clones would share the same parent scope, interfering with each other's state.
Line 247:		Line 251:
	* Rebinding: ''Closure::bind()'' and ''Closure::bindTo()'' raise an ''Error''. The scope and ''$this'' come from the parent and cannot be rebound.		* Rebinding: ''Closure::bind()'' and ''Closure::bindTo()'' raise an ''Error''. The scope and ''$this'' come from the parent and cannot be rebound.

-	* Outliving the parent: A scope function may only be called while its defining function is still on the stack. Storing one in a property, a global, a static variable, or returning it from the parent will raise an ''Error'' when the parent returns.	+	* Outliving the parent: A scope function may only be called while its defining function is still on the stack. Storing one in a property, a global, a static variable, or returning it from the parent raises an ''Error'' when the parent returns.
		+	<code>
		+	Fatal error: Uncaught Error: Scope function closure must not outlive the declaring scope in %s:%d
		+	</code>
		+
		+	* Re-evaluation in the same frame: Re-evaluating the same scope function declaration in the same parent frame invalidates the previous instance rather than silently retargeting it to the new one.
		+	<code>
		+	Fatal error: Uncaught Error: Cannot call scope function: defining scope has exited in %s:%d
		+	</code>
		+	This avoids silently retargeting an old closure handle to a new instance.
		+
		+	* Generators: There are no restrictions on yield/yield from. Generators will be closed as the scoped function goes out of scope.
		+
		+	===== Alternatives Considered =====
		+
		+	Letting an older closure handle transparently resolve to the current instance when the same scope function declaration is re-evaluated:

-	* Generators: There are no restrictions on yied/yield from. Generators will be closed as the scoped function goes out of scope.	+	This was rejected because it makes closure identity unstable: A stored closure would silently change meaning after later execution of the parent frame.

	===== Reflection =====		===== Reflection =====

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

2026/05/01 15:14		current
Line 15:		Line 15:
	* [[rfc:snmp_improvements_2026\|SNMP Improvements]] (Created 2026-03-30; voting started 2026-04-21, ends 2026-05-08)		* [[rfc:snmp_improvements_2026\|SNMP Improvements]] (Created 2026-03-30; voting started 2026-04-21, ends 2026-05-08)
	* [[rfc:display_error_function_args \| Display Function Arguments in Errors]] (Created 2026-03-09; voting started 2026-05-01, ends 2026-05-15)		* [[rfc:display_error_function_args \| Display Function Arguments in Errors]] (Created 2026-03-09; voting started 2026-05-01, ends 2026-05-15)
		+	* [[rfc:session_security_defaults\|Session security defaults]] (Created 2026-04-04)

	===== Under Discussion =====		===== Under Discussion =====
Line 25:		Line 26:
	* [[rfc:remove-link-to-x-from-php-net\|Remove the links to X.com from PHP.net]] (Created 2026-04-12)		* [[rfc:remove-link-to-x-from-php-net\|Remove the links to X.com from PHP.net]] (Created 2026-04-12)
	* [[rfc:mariadb_rfc\|Add MariaDB specific features to mysqlnd and mysqli]] (Created 2026-04-06)		* [[rfc:mariadb_rfc\|Add MariaDB specific features to mysqlnd and mysqli]] (Created 2026-04-06)
-	* [[rfc:session_security_defaults\|Session security defaults]] (Created 2026-04-04)
	* [[rfc:array_get_and_array_has\|array_path_get and array_path_exists functions]] (Created 2026-04-04)		* [[rfc:array_get_and_array_has\|array_path_get and array_path_exists functions]] (Created 2026-04-04)
	* [[rfc:override_constants\|#[\Override] for class constants]] (created 2026-03-13)		* [[rfc:override_constants\|#[\Override] for class constants]] (created 2026-03-13)