PHP Wiki

mysqlnd_vs_libmysql

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/09/08 14:41		current
Line 28:		Line 28:


		+	Please make sure that you are using a PHP build with Zlib and OpenSSL support when switching from libmysql to mysqlnd. This will ensure that mysqlnd offers the same functionality as libmysql does.
	==== Major feature differences ====		==== Major feature differences ====

undocumented

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/01/08 21:11		current
Line 124:		Line 124:
	* ''Closures''		* ''Closures''
	===== PHP 5.x ====		===== PHP 5.x ====
		+	* SplObjectStorage::getHash
	* Type hints: ''self'', ''parent'' and interfaces.		* Type hints: ''self'', ''parent'' and interfaces.
	<code php>		<code php>

union_types_v2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	====== PHP RFC: Union Types 2.0 ======
	+
	+	* Date: 2019-09-02
	+	* Author: Nikita Popov <nikic@php.net>
	+	* Proposed Version: PHP 8.0
	+	* RFC PR: [[https://github.com/php/php-rfcs/pull/1\|php/php-rfcs#0001]]
	+	* Mailing list thread: https://externals.io/message/106844
	+	* Implementation: [[https://github.com/php/php-src/pull/4838\|php/php-src#4838]]
	+
	+	===== Introduction =====
	+
	+	A "union type" accepts values of multiple different types, rather than a single one. PHP already supports two special union types:
	+
	+	* ''Type'' or ''null'', using the special ''?Type'' syntax.
	+	* ''array'' or ''Traversable'', using the special ''iterable'' type.
	+
	+	However, arbitrary union types are currently not supported by the language. Instead, phpdoc annotations have to be used, such as in the following example:
	+
	+	<code php>
	+	class Number {
	+	/**
	+	* @var int\|float $number
	+	*/
	+	private $number;
	+
	+	/**
	+	* @param int\|float $number
	+	*/
	+	public function setNumber($number) {
	+	$this->number = $number;
	+	}
	+
	+	/**
	+	* @return int\|float
	+	*/
	+	public function getNumber() {
	+	return $this->number;
	+	}
	+	}
	+	</code>
	+
	+	The [[#statistics\|statistics section]] shows that the use of union types is indeed pervasive in the open-source ecosystem, as well as PHP's own standard library.
	+
	+	Supporting union types in the language allows us to move more type information from phpdoc into function signatures, with the usual advantages this brings:
	+
	+	* Types are actually enforced, so mistakes can be caught early.
	+	* Because they are enforced, type information is less likely to become outdated or miss edge-cases.
	+	* Types are checked during inheritance, enforcing the Liskov Substitution Principle.
	+	* Types are available through Reflection.
	+	* The syntax is a lot less boilerplate-y than phpdoc.
	+
	+	After generics, union types are currently the largest "hole" in our type declaration system.
	+
	+	===== Proposal =====
	+
	+	Union types are specified using the syntax ''T1\|T2\|...'' and can be used in all positions where types are currently accepted:
	+
	+	<code php>
	+	class Number {
	+	private int\|float $number;
	+
	+	public function setNumber(int\|float $number): void {
	+	$this->number = $number;
	+	}
	+
	+	public function getNumber(): int\|float {
	+	return $this->number;
	+	}
	+	}
	+	</code>
	+
	+	==== Supported Types ====
	+
	+	Union types support all types currently supported by PHP, with some caveats outlined in the following.
	+
	+	=== void type ===
	+
	+	The ''void'' type can never be part of a union. As such, types like ''T\|void'' are illegal in all positions, including return types.
	+
	+	The ''void'' type indicates that the function has no return value, and enforces that argument-less ''return;'' is used to return from the function. It is fundamentally incompatible with non-void return types.
	+
	+	What is likely intended instead is ''?T'', which allows returning either ''T'' or ''null''.
	+
	+	=== Nullable union types ===
	+
	+	The ''null'' type is supported as part of unions, such that ''T1\|T2\|null'' can be used to create a nullable union. The existing ''?T'' notation is considered a shorthand for the common case of ''T\|null''.
	+
	+	An earlier version of this RFC proposed to use ''?(T1\|T2)'' for nullable union types instead, to avoid having two ways of expressing nullability in PHP. However, this notation is both rather awkward syntactically, and differs from the well-established ''T1\|T2\|null'' syntax used by phpdoc comments. The discussion feedback was overwhelmingly in favor of supporting the ''T1\|T2\|null'' notation.
	+
	+	''?T'' remains valid syntax that denotes the same type as ''T\|null''. It is neither discouraged nor deprecated, and there are no plans to deprecate it in the future. It is merely a shorthand alias for a particularly common union type.
	+
	+	The ''null'' type is only allowed as part of a union, and can not be used as a standalone type. Allowing it as a standalone type would make both ''function foo(): void'' and ''function foo(): null'' legal function signatures, with similar but not identical semantics. This would negatively impact teachability for an unclear benefit.
	+
	+	Union types and the ''?T'' nullable type notation cannot be mixed. Writing ''?T1\|T2'', ''T1\|?T2'' or ''?(T1\|T2)'' is not supported and ''T1\|T2\|null'' needs to be used instead. I'm open to permitting the ''?(T1\|T2)'' syntax though, if this is considered desirable.
	+
	+	=== false pseudo-type ===
	+
	+	While we nowadays encourage the use of ''null'' over ''false'' as an error or absence return value, for historical reasons many internal functions continue to use ''false'' instead. As shown in the [[#statistics\|statistics section]], the vast majority of union return types for internal functions include ''false''.
	+
	+	A classical example is the ''strpos()'' family of functions, which returns ''int\|false''.
	+
	+	While it would be possible to model this less accurately as ''int\|bool'', this gives the false impression that the function can also return a ''true'' value, which makes this type information significantly less useful to humans and static analyzers both.
	+
	+	For this reason, support for the ''false'' pseudo-type is included in this proposal. A ''true'' pseudo-type is //not// part of the proposal, because similar historical reasons for its necessity do not exist.
	+
	+	The ''false'' pseudo-type cannot be used as a standalone type (including nullable standalone type). As such, all of ''false'', ''false\|null'' and ''?false'' are not permitted.
	+
	+	=== Duplicate and redundant types ===
	+
	+	To catch some simple bugs in union type declarations, redundant types that can be detected without performing class loading will result in a compile-time error. This includes:
	+
	+	* Each name-resolved type may only occur once. Types like ''int\|string\|INT'' result in an error.
	+	* If ''bool'' is used, ''false'' cannot be used additionally.
	+	* If ''object'' is used, class types cannot be used additionally.
	+	* If ''iterable'' is used, ''array'' and ''Traversable'' cannot be used additionally.
	+
	+	This does not guarantee that the type is "minimal", because doing so would require loading all used class types.
	+
	+	For example, if ''A'' and ''B'' are class aliases, then ''A\|B'' remains a legal union type, even though it could be reduced to either ''A'' or ''B''. Similarly, if ''class B extends A {}'', then ''A\|B'' is also a legal union type, even though it could be reduced to just ''A''.
	+
	+	<code php>
	+	function foo(): int\|INT {} // Disallowed
	+	function foo(): bool\|false {} // Disallowed
	+
	+	use A as B;
	+	function foo(): A\|B {} // Disallowed ("use" is part of name resolution)
	+
	+	class_alias('X', 'Y');
	+	function foo(): X\|Y {} // Allowed (redundancy is only known at runtime)
	+	</code>
	+
	+	=== Type grammar ===
	+
	+	Excluding the special ''void'' type, PHP's type syntax may now be described by the following grammar:
	+
	+	<code>
	+	type: simple_type
	+	\| "?" simple_type
	+	\| union_type
	+	;
	+
	+	union_type: simple_type "\|" simple_type
	+	\| union_type "\|" simple_type
	+	;
	+
	+	simple_type: "false" # only legal in unions
	+	\| "null" # only legal in unions
	+	\| "bool"
	+	\| "int"
	+	\| "float"
	+	\| "string"
	+	\| "array"
	+	\| "object"
	+	\| "iterable"
	+	\| "callable" # not legal in property types
	+	\| "self"
	+	\| "parent"
	+	\| namespaced_name
	+	;
	+	</code>
	+
	+	==== Variance ====
	+
	+	Union types follow the existing variance rules:
	+
	+	* Return types are covariant (child must be subtype).
	+	* Parameter types are contravariant (child must be supertype).
	+	* Property types are invariant (child must be subtype and supertype).
	+
	+	The only change is in how union types interact with subtyping, with three additional rules:
	+
	+	* A union ''U_1\|...\|U_n'' is a subtype of ''V_1\|...\|V_m'' if for each ''U_i'' there exists a ''V_j'' such that ''U_i'' is a subtype of ''V_j''.
	+	* The ''iterable'' type is considered to be the same (i.e. both subtype and supertype) as ''array\|Traversable''.
	+	* The ''false'' pseudo-type is considered a subtype of ''bool''.
	+
	+	In the following, some examples of what is allowed and what isn't are given.
	+
	+	=== Property types ===
	+
	+	Property types are invariant, which means that types must stay the same during inheritance. However, the "same" type may be expressed in different ways. Prior to union types, one such possibility was to have two aliased classes ''A'' and ''B'', in which case a property type may legally change from ''A'' to ''B'' or vice versa.
	+
	+	Union types expand the possibilities in this area: For example ''int\|string'' and ''string\|int'' represent the same type. The following example shows a more complex case:
	+
	+	<code php>
	+	class A {}
	+	class B extends A {}
	+
	+	class Test {
	+	public A\|B $prop;
	+	}
	+	class Test2 extends Test {
	+	public A $prop;
	+	}
	+	</code>
	+
	+	In this example, the union ''A\|B'' actually represents the same type as just ''A'', and this inheritance is legal, despite the type not being syntactically the same.
	+
	+	Formally, we arrive at this result as follows: First, ''A'' is a subtype of ''A\|B'', because it is a subtype of ''A''. Second, ''A\|B'' is a subtype of ''A'', because ''A'' is a subtype of ''A'' and ''B'' is a subtype of ''A''.
	+
	+	=== Adding and removing union types ===
	+
	+	It is legal to remove union types in return position and add union types in parameter position:
	+
	+	<code php>
	+	class Test {
	+	public function param1(int $param) {}
	+	public function param2(int\|float $param) {}
	+
	+	public function return1(): int\|float {}
	+	public function return2(): int {}
	+	}
	+
	+	class Test2 extends Test {
	+	public function param1(int\|float $param) {} // Allowed: Adding extra param type
	+	public function param2(int $param) {} // FORBIDDEN: Removing param type
	+
	+	public function return1(): int {} // Allowed: Removing return type
	+	public function return2(): int\|float {} // FORBIDDEN: Adding extra return type
	+	}
	+	</code>
	+
	+	=== Variance of individual union members ===
	+
	+	Similarly, it is possible to restrict a union member in return position, or widen a union member in parameter position:
	+
	+	<code php>
	+	class A {}
	+	class B extends A {}
	+
	+	class Test {
	+	public function param1(B\|string $param) {}
	+	public function param2(A\|string $param) {}
	+
	+	public function return1(): A\|string {}
	+	public function return2(): B\|string {}
	+	}
	+
	+	class Test2 extends Test {
	+	public function param1(A\|string $param) {} // Allowed: Widening union member B -> A
	+	public function param2(B\|string $param) {} // FORBIDDEN: Restricting union member A -> B
	+
	+	public function return1(): B\|string {} // Allowed: Restricting union member A -> B
	+	public function return2(): A\|string {} // FORBIDDEN: Widening union member B -> A
	+	}
	+	</code>
	+
	+	Of course, the same can also be done with multiple union members at a time, and be combined with the addition/removal of types mentioned previously.
	+
	+	==== Coercive typing mode ====
	+
	+	When ''strict_types'' is not enabled, scalar type declarations are subject to limited implicit type coercions. These are problematic in conjunction with union types, because it is not always obvious which type the input should be converted to. For example, when passing a boolean to an ''int\|string'' argument, both ''0'' and ''""'' would be viable coercion candidates.
	+
	+	If the exact type of the value is not part of the union, then the target type is chosen in the following order of preference:
	+
	+	- ''int''
	+	- ''float''
	+	- ''string''
	+	- ''bool''
	+
	+	If the type both exists in the union, and the value can be coerced to the type under PHPs existing type checking semantics, then the type is chosen. Otherwise the next type is tried.
	+
	+	As an exception, if the value is a string and both ''int'' and ''float'' are part of the union, the preferred type is determined by the existing "numeric string" semantics. For example, for ''"42"'' we choose ''int'', while for ''"42.0"'' we choose ''float''.
	+
	+	Types that are not part of the above preference list are not eligible targets for implicit coercion. In particular no implicit coercions to the ''null'' and ''false'' types occur.
	+
	+	=== Conversion Table ===
	+
	+	The following table shows how the above order of preference plays out for different input types, assuming that the exact type is not part of the union:
	+
	+	^Original type ^1st try ^2nd try ^3rd try ^
	+	\|bool \|int \|float \|string \|
	+	\|int \|float \|string \|bool \|
	+	\|float \|int \|string \|bool \|
	+	\|string \|int/float \|bool \| \|
	+	\|object \|string \| \| \|
	+
	+	=== Examples ===
	+
	+	<code php>
	+	// int\|string
	+	42 --> 42 // exact type
	+	"42" --> "42" // exact type
	+	new ObjectWithToString --> "Result of __toString()"
	+	// object never compatible with int, fall back to string
	+	42.0 --> 42 // float compatible with int
	+	42.1 --> 42 // float compatible with int
	+	1e100 --> "1.0E+100" // float too large for int type, fall back to string
	+	INF --> "INF" // float too large for int type, fall back to string
	+	true --> 1 // bool compatible with int
	+	[] --> TypeError // array not compatible with int or string
	+
	+	// int\|float\|bool
	+	"45" --> 45 // int numeric string
	+	"45.0" --> 45.0 // float numeric string
	+	"45X" --> 45 + Notice: Non well formed numeric string
	+	// int numeric string
	+	"" --> false // not numeric string, fall back to bool
	+	"X" --> true // not numeric string, fall back to bool
	+	[] --> TypeError // array not compatible with int, float or bool
	+	</code>
	+
	+	==== Alternatives ====
	+
	+	There are two main alternatives to the preference-based approach used by this proposal:
	+
	+	The first is to specify that union types //always// use strict typing, thus avoiding any complicated coercion semantics altogether. Apart from the inconsistency this introduces in the language, this has two main disadvantages: First going from a type like ''float'' to ''int\|float'' would actually //reduce// the number of valid inputs, which is highly unintuitive. Second, it breaks the variance model for union types, because we can no longer say that ''float'' is a subtype of ''int\|float''.
	+
	+	The second is to perform the coercions based on the order of types. This would mean that ''int\|string'' and ''string\|int'' are distinct types, where the former would favor integers and the latter strings. Depending on whether exact type matches are still prioritized, the string type would //always// be used for the latter case. Once again, this is unintuitive and has very unclear implications for the subtyping relationship on which variance is based.
	+
	+	==== Property types and references ====
	+
	+	References to typed properties with union types follow the semantics outlined in the [[rfc/typed_properties_v2#general_semantics\|typed properties RFC]]:
	+
	+	> If typed properties are part of the reference set, then the value is checked against each property type. If a type check fails, a TypeError is generated and the value of the reference remains unchanged.
	+	>
	+	> There is one additional caveat: If a type check requires a coercion of the assigned value, it may happen that all type checks succeed, but result in different coerced values. As a reference can only have a single value, this situation also leads to a TypeError.
	+
	+	The [[rfc/typed_properties_v2#future_interaction_with_union_types\|interaction with union types]] was already considered at the time, because it impacts the detailed reference semantics. Repeating the example given there:
	+
	+	<code php>
	+	class Test {
	+	public int\|string $x;
	+	public float\|string $y;
	+	}
	+	$test = new Test;
	+	$r = "foobar";
	+	$test->x =& $r;
	+	$test->y =& $r;
	+
	+	// Reference set: { $r, $test->x, $test->y }
	+	// Types: { mixed, int\|string, float\|string }
	+
	+	$r = 42; // TypeError
	+	</code>
	+
	+	The basic issue is that the final assigned value (after type coercions have been performed) must be compatible with all types that are part of the reference set. However, in this case the coerced value will be ''int(42)'' for property ''Test::$x'', while it will be ''float(42.0)'' for property ''Test::$y''. Because these values are not the same, this is considered illegal and a ''TypeError'' is thrown.
	+
	+	An alternative approach would be to cast the value to the only common type ''string'' instead, with the major disadvantage that this matches //neither// of the values you would get from a direct property assignment.
	+
	+	==== Reflection ====
	+
	+	To support union types, a new class ''ReflectionUnionType'' is added:
	+
	+	<code php>
	+	class ReflectionUnionType extends ReflectionType {
	+	/** @return ReflectionType[] */
	+	public function getTypes();
	+
	+	/* Inherited from ReflectionType */
	+	/** @return bool */
	+	public function allowsNull();
	+
	+	/* Inherited from ReflectionType */
	+	/** @return string */
	+	public function __toString();
	+	}
	+	</code>
	+
	+	The ''getTypes()'' method returns an array of ''ReflectionType''s that are part of the union. The types may be returned in an arbitrary order that does not match the original type declaration. The types may also be subject to equivalence transformations.
	+
	+	For example, the type ''int\|string'' may return types in the order ''["string", "int"]'' instead. The type ''iterable\|array\|string'' might be canonicalized to ''iterable\|string'' or ''Traversable\|array\|string''. The only requirement on the Reflection API is that the ultimately represented type is equivalent.
	+
	+	The ''allowsNull()'' method returns whether the union contains the type ''null''.
	+
	+	The ''%%__toString()%%'' method returns a string representation of the type that constitutes a valid code representation of the type in a non-namespaced context. It is not necessarily the same as what was used in the original code.
	+
	+	For backwards-compatibility reasons, union types that only include ''null'' and one other type (written as ''?T'', ''T\|null'', or through implicit parameter nullability), will instead use ''ReflectionNamedType''.
	+
	+	=== Examples ===
	+
	+	<code php>
	+	// This is one possible output, getTypes() and __toString() could
	+	// also provide the types in the reverse order instead.
	+	function test(): float\|int {}
	+	$rt = (new ReflectionFunction('test'))->getReturnType();
	+	var_dump(get_class($rt)); // "ReflectionUnionType"
	+	var_dump($rt->allowsNull()); // false
	+	var_dump($rt->getTypes()); // [ReflectionType("int"), ReflectionType("float")]
	+	var_dump((string) $rt); // "int\|float"
	+
	+	function test2(): float\|int\|null {}
	+	$rt = (new ReflectionFunction('test2'))->getReturnType();
	+	var_dump(get_class($rt)); // "ReflectionUnionType"
	+	var_dump($rt->allowsNull()); // true
	+	var_dump($rt->getTypes()); // [ReflectionType("int"), ReflectionType("float"),
	+	// ReflectionType("null")]
	+	var_dump((string) $rt); // "int\|float\|null"
	+
	+	function test3(): int\|null {}
	+	$rt = (new ReflectionFunction('test3'))->getReturnType();
	+	var_dump(get_class($rt)); // "ReflectionNamedType"
	+	var_dump($rt->allowsNull()); // true
	+	var_dump($rt->getName()); // "int"
	+	var_dump((string) $rt); // "?int"
	+	</code>
	+
	+	===== Backwards Incompatible Changes =====
	+
	+	This RFC does not contain any backwards incompatible changes. However, existing ReflectionType based code will have to be adjusted in order to support processing of code that uses union types.
	+
	+	===== Future Scope =====
	+
	+	The features discussed in the following are not part of this proposal.
	+
	+	==== Intersection Types ====
	+
	+	Intersection types are logically conjugated with union types. Instead of requiring that (at least) a single type constraints is satisfied, all of them must be.
	+
	+	For example ''Traversable\|Countable'' requires that the passed value is either ''Traversable'' or ''Countable'', while ''Traversable&Countable'' requires that it is both.
	+
	+	==== Mixed Type ====
	+
	+	The ''mixed'' type allows to explicitly annotate that any value is acceptable. While specifying no type has the same behavior on the surface, it does not make clear whether the type is simply missing (because nobody bothered adding it yet, or because it can't be added for backwards compatibility reasons), or whether genuinely any value is acceptable.
	+
	+	We've held off on adding a ''mixed'' type out of fear that it would be used in cases where a more specific union could have been specified. Once union types are supported, it would probably also make sense to add the ''mixed'' type.
	+
	+	==== Literal Types ====
	+
	+	The ''false'' pseudo-type introduced in this RFC is a special case of a "literal type", such as supported by [[https://www.typescriptlang.org/docs/handbook/advanced-types.html#string-literal-types\|TypeScript]]. They allow specifying enum-like types, which are limited to specific values.
	+
	+	<code php>
	+	type ArrayFilterFlags = 0\|ARRAY_FILTER_USE_KEY\|ARRAY_FILTER_USE_BOTH;
	+	array_filter(array $array, callable $callback, ArrayFilterFlags $flag): array;
	+
	+	</code>
	+	A benefit of using a union of literal types instead of an enum, is that it works directly with values of the underlying type, rather than an opaque enum value. As such, it is easier to retrofit without breaking backwards-compatibility.
	+
	+	This RFC intentionally supports the ''false'' type in a maximally restricted form, which is enough to model internal function return values, but avoids unnecessarily constraining a future proposal for introducing first-class literal types. In particular:
	+
	+	* No values implicitly coerce to ''false'', while it would also be possible to follow ''bool'' parameter coercion semantics, restricted to input values that coerce to ''false''. Both approaches have advantages, but we pick the conservative option, which permits future extension, here.
	+	* Only ''false'' is supported, but not ''true''. Once both are supported, the subtyping relationship between ''false\|true'' and ''bool'' needs to be defined (which is also tightly related to the question of implicit coercions).
	+
	+	==== Type Aliases ====
	+
	+	As types become increasingly complex, it may be worthwhile to allow reusing type declarations. There are two general ways in which this could work. One is a local alias, such as:
	+
	+	<code php>
	+	use int\|float as number;
	+
	+	function foo(number $x) {}
	+	</code>
	+
	+	In this case ''number'' is a symbol that is only visible locally and will be resolved to the original ''int\|float'' type during compilation.
	+
	+	The second possibility is an exported typedef:
	+
	+	<code php>
	+	namespace Foo;
	+	type number = int\|float;
	+
	+	// Usable as \Foo\number from elsewhere
	+	</code>
	+
	+	===== Proposed Voting Choices =====
	+
	+	Simple yes/no vote.
	+
	+	===== Statistics =====
	+
	+	To illustrate the use of union types in the wild, the use of union types in ''@param'' and ''@return'' annotations in phpdoc comments has been analyzed.
	+
	+	In the top two thousand composer packages there are:
	+
	+	* 25k parameter union types: [[https://gist.github.com/nikic/64ff90c5038522606643eac1259a9dae#file-param_union_types-json\|Full JSON data]]
	+	* 14k return union types: [[https://gist.github.com/nikic/64ff90c5038522606643eac1259a9dae#file-return_union_types-json\|Full JSON data]]
	+
	+	In the PHP stubs for internal functions (these are incomplete right now, so the actual numbers should be at least twice as large) there are:
	+
	+	* 336 union return types
	+	* of which 312 include ''false'' as a value
	+
	+	This illustrates that the ''false'' pseudo-type in unions is necessary to express the return type of many existing internal functions.
	+

logdownloads

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 43:		Line 43:

	=== Notes ===		=== Notes ===
-	It would be helpful to determine and document exactly how our download system works. For example, a 404 handler sees /get/ then ...	+	It would be helpful to determine and document exactly how our download system works. For example, a 404 handler sees /get/ then ... ?

per-release-all

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/06/20 03:41		current
Line 9:		Line 9:
	$ cd svn/phpdoc/trunk		$ cd svn/phpdoc/trunk
	$ xmllint --output tmp.xml --noent doc-base/install-unix.xml && phd -d ./tmp.xml -P PHP -f bigxhtml -o ./ && lynx -dump -nolist -justify -display_charset UTF-8 ./php-bigxhtml.html > INSTALL		$ xmllint --output tmp.xml --noent doc-base/install-unix.xml && phd -d ./tmp.xml -P PHP -f bigxhtml -o ./ && lynx -dump -nolist -justify -display_charset UTF-8 ./php-bigxhtml.html > INSTALL
-	$ xmllint --output tmp.xml --noent doc-base/install-windows.xml && phd -d ./tmp.xml -P PHP -f bigxhtml -o ./ && lynx -dump -nolist -justify -display_charset UTF-8 ./php-bigxhtml.html > install.txt	+	$ xmllint --output tmp.xml --noent doc-base/install-win.xml && phd -d ./tmp.xml -P PHP -f bigxhtml -o ./ && lynx -dump -nolist -justify -display_charset UTF-8 ./php-bigxhtml.html > install.txt
	</code>		</code>

per-release-minor

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	==== TODO for every minor (x.Y.0) release ====
	+
	+	== Migration guides ==
	+	Since PHP 5.1.0, every such release has included a migration appendix / upgrade guide. This involves the following:
	+
	+	* php-src/README.UPDATE_X_Y (Examples: [[http://cvs.php.net/viewvc.cgi/phpweb/README_UPGRADE_51.php?hideattic=0\|5.1]], [[http://cvs.php.net/viewvc.cgi/php-src/README.UPDATE_5_2?&pathrev=PHP_5_2\|5.2]])
	+	* phpdoc/appendix/migrationXY.xml (Examples: [[http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/migration51.xml?view=log\|5.2]], [[http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/migration52.xml?view=log\|5.2]])
	+
	+	Currently the internals team has created the README files, but this may change.
	+
	+	== Extension categories ==
	+	Some extensions may have been moved to PECL, became bundled, were re-categorized, etc. This information should be updated at this time, or at any time before:
	+	* The XML: [[http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/extensions.xml?view=log\|phpdoc/en/appendices/extensions.xml]]
	+	* The script that updates it: [[http://cvs.php.net/viewvc.cgi/phpdoc/scripts/extensions.xml.php?view=log\|phpdoc/scripts.extensions.xml.php]]
	+	NOTE: This information comes from the comments found within (on top of) every book.xml. Status, and Membership. The Purpose dictates how the extensions are categorized in the index/table of contents.

missingdocs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/04/01 05:09		current
Line 14:		Line 14:
	* Look over our old version of this from the [[http://www.phpdoc.info/meta/phpsrc-vs-phpdoc.php\|old site]]		* Look over our old version of this from the [[http://www.phpdoc.info/meta/phpsrc-vs-phpdoc.php\|old site]]
	* Look over scripts/ to see what other nuggets can be found to help this task		* Look over scripts/ to see what other nuggets can be found to help this task
		+
		+	=== Solutions ===
		+	* The [[http://svn.php.net/viewvc/phpdoc/doc-base/trunk/scripts/check-missing-docs.php\|check-missing-docs.php]] script is a start

peehaa

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	I've created this list to keep track of things I would like to see changed in the docs.

	+	=== Work in progress ===
	+
	+	I'm currently working on [[http://php.net/tut.php\|the tutorial]], because it its current state it really isn't that useful. There is still a lot of work that needs to be done, but progress can be tracked on [[https://github.com/PeeHaa/php-net-tutorial\|GitHub]]. Feel free to review / improve it.
	+
	+	=== todo ===
	+
	+	* Write tutorial
	+	* [[http://www.php.net/manual/en/language.variables.external.php\|External variables]], the note about escaping data to safely do data manipulation in databases is not up to standards.
	+	* [[http://php.net/manual/en/debugger.php\|Debugging]], it would be nice if it would contain some useful information about how to do some basic debugging in PHP applications.
	+	* [[http://php.net/manual/en/security.database.sql-injection.php\|SQL Injection]], don't even get me started about this one.
	+	* [[http://php.net/manual/en/language.variables.scope.php\|Variable scoping]], do we really need to promote the use of the `global` keyword or the `$_GLOBALS` superglobal without any warning?
	+	* [[http://www.php.net/manual/en/userlandnaming.tips.php\|Userland naming]], really nice tips going on here ;-)
	+	* [[http://php.net/manual/en/pdostatement.fetch.php\|PDOStatement::fetch examples]], make the example better readable when possible.

gitdocs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2020/02/04 12:53		current
Line 10:		Line 10:
	* Assigned: Peter		* Assigned: Peter
	- Grant force-push access to a user that can push the modified commits from svngit.php.net (can be me, can be a dedicated user)		- Grant force-push access to a user that can push the modified commits from svngit.php.net (can be me, can be a dedicated user)
-	* Status: TODO	+	* Create a new VCS account for the migration
-	* Assigned: Peter	+	* Status: TODO
		+	* Assigned: Peter
		+	* Force-push should be allowed by default (AFAIK (Peter) we only restrict force-push to a very small set of branches on a very small number of repos)
		+	* Status: to be verified
		+	* Assigned: Peter
	- Add the remotes to the respective repos on svngit.php.net and set up automated force push		- Add the remotes to the respective repos on svngit.php.net and set up automated force push
	* Status: TODO		* Status: TODO

philip

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/01/08 06:04		current
Line 5:		Line 5:
	* ext/mysql/migration should exist, with mysqli+PDO_MySQL examples		* ext/mysql/migration should exist, with mysqli+PDO_MySQL examples

		+	PHP.NET update:
		+	* mysql->mysqli migration, where appropriate. Begin with master.

	=== Notes about this TODO ===		=== Notes about this TODO ===

inicleanup

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 8:		Line 8:
	* php.ini files		* php.ini files
	* Each extension (has its own ini section)		* Each extension (has its own ini section)
-	* phpdoc/scripts/iniupdate	+	* phpdoc/scripts/iniupdate : this is no longer used, really, so we should make a final decision. Update it, or remove it.
		+	* There should be a single location that pulls in ALL ini information, from all extensions, so a person can easily ^f.

	=== Problems ===		=== Problems ===

phd

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/07/10 00:51		current
Line 16:		Line 16:
	* Add API to docs.php.net		* Add API to docs.php.net
	* Add PDF and other formats to [[http://doc.php.net/downloads]]		* Add PDF and other formats to [[http://doc.php.net/downloads]]
-	* Create QA tools based on PhD_IDE (e.g., find all 5.3.0+ changelog entries, find non-initialized optional params, find most common seealso links, php -l examples and create unit tests, find X, ...	+	* Create QA tools based on PhD_IDE (e.g., find all 5.3.0+ changelog entries, find non-initialized optional params, find most common seealso links, php -l examples and create unit tests, find X, ...)

	==== Big wishes ====		==== Big wishes ====

php5rewrite

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	=== Making PHP 5 a first class citizen rewrite ===
	+	This task rewords the manual in such a manner that PHP 5 becomes a first class citizen. This means we'll remove terms like:
	+
	+	* //As of PHP 5//
	+	* //Since PHP 5//
	+	* //Added in PHP 5//
	+
	+	Because those suggest that PHP 4 is the current PHP version, when in fact it's not.
	+
	+	The original proposal (and discussion that followed):
	+
	+	* http://markmail.org/message/vtxwpxutxtudhym7
	+
	+	This idea does not mean that we'd remove PHP 4 specific content. However, it does mean adding changelogs to various parts of the documentation.
	+
	+	=== Problems ===
	+
	+	=== TODO ===
	+	* Determine how this would work exactly
	+	* Determine how PHP 4 specific extensions, like the old domxml, would be handled

move_return_types_in_prototypes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/11/15 09:17		current
Line 3:		Line 3:
	* Date: 2017-11-15		* Date: 2017-11-15
	* Author: salathe		* Author: salathe
-	* Status: draft	+	* Status: DONE

	===== Motivation =====		===== Motivation =====

per-release-major

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	==== TODO for every major (X.0.0) PHP Release ====
	+
	+	== Check version information ==
	+	Since each major PHP version is stored in the version files, this is taken into account at this time.
	+
	+	== Consider removing old information ==
	+	For example, is PHP 3 still relevant? How about PHP 4? If using version specific tagging, does the build system need adjusting?
	+
	+	== Update PHP version specific info ==
	+	The following manual pages contain version specific information that needs updating:
	+	* [[http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/about.xml?view=log\|appendices/about.xml]]

translations

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/04/06 09:29		current
Line 12:		Line 12:
	==== Additional resources ====		==== Additional resources ====
	* The [[http://doc.php.net/revcheck.php\|revision check tools]]		* The [[http://doc.php.net/revcheck.php\|revision check tools]]
-	* The [[http://doc.php.net/dochowto/\|documentation HOWTO]]	+	* The [[http://doc.php.net/tutorial/\|documentation HOWTO]]

install

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	=== Installation section rewrite ===
	+	This task involves rewriting and restructuring the installation section of the PHP Manual. This is a large task so may be broken up into smaller parts.

	+	The section in question:
	+	* URL: http://php.net/install
	+	* Source: http://cvs.php.net/viewvc.cgi/phpdoc/en/install/
	+
	+	=== Problems ===
	+	This section has become outdated. For example, we highlight Apache 2.0.x and only include a few notes about Apache 2.2.x. There are a ton of user notes from confused users that should be addressed. The IIS/PWS section is outdated. The Mac section is outdated. Other parts, outdated.
	+
	+	=== TODO ===
	+	Start work on this one section at a time.

migrationguide

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/11/29 22:30		current
Line 197:		Line 197:
	* PCRE:		* PCRE:
	* Added `PREG_UNMATCHED_AS_NULL` flag to allow distinguish between unmatched subpatterns and empty matches by reporting NULL and "" (empty string), respectively.		* Added `PREG_UNMATCHED_AS_NULL` flag to allow distinguish between unmatched subpatterns and empty matches by reporting NULL and "" (empty string), respectively.
-	* Standard Library
-	* mail()/mb_send_mail() accept array $extra_header. Array parameter is checked against RFC 2822.


Line 206:		Line 204:
	* mb_check_encoding() accepts array parameter. Both key and value encodings are checked recursively.		* mb_check_encoding() accepts array parameter. Both key and value encodings are checked recursively.
	* mb_convert_encoding() accepts array parameter. Only value encodings are converted recursively.		* mb_convert_encoding() accepts array parameter. Only value encodings are converted recursively.
		+	* Standard Library
		+	* mail()/mb_send_mail() accept array $extra_header. Array parameter is checked against RFC 2822.
	* Windows		* Windows
	* Support for VT100 console mode on systems starting with Windows NT 10.0.10586 (Windows 10 (TH2)), cmd.exe supports ANSI escape sequences. The corresponding console mode is enabled by default on CLI on suitable systems. As well, the function sapi_windows_vt100_support() is provided, to control and query the corresponding information in the scripts.		* Support for VT100 console mode on systems starting with Windows NT 10.0.10586 (Windows 10 (TH2)), cmd.exe supports ANSI escape sequences. The corresponding console mode is enabled by default on CLI on suitable systems. As well, the function sapi_windows_vt100_support() is provided, to control and query the corresponding information in the scripts.

spldocs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/03/16 11:43		current
Line 10:		Line 10:
	Some example areas to consider:		Some example areas to consider:

-	* Common Iterator methods: current, key, next, rewind, valid	+	* Common Iterator methods: current, key, next, rewind, valid
-	* OuterIterator interface: getInnerIterator	+	* OuterIterator interface: getInnerIterator
-	* Classes implementing Countable, RecursiveIterator, SeekableIterator	+	* Classes implementing Countable, RecursiveIterator, SeekableIterator
-	* What about non-SPL interfaces (e.g. ArrayAccess, Serializable)	+	* What about non-SPL interfaces (e.g. ArrayAccess, Serializable)

	Much of the remaining 'skeleton' SPL docs fall into this category of common methods so it would be worth having a plan of action on this subject before ploughing ahead with those.		Much of the remaining 'skeleton' SPL docs fall into this category of common methods so it would be worth having a plan of action on this subject before ploughing ahead with those.

changelog

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	=== Changelog evaluation ===
	+	Each function/method has its own changelog. However, how they are written has introduced inconsistencies into the documentation.

	+	=== TODO ===
	+	Determine the official route for:
	+	* Order: Do newest PHP versions go on top or bottom?
	+	* Format: Is it PHP 5, 5, 5.0, or 5.0.0?
	+	* Information: Would the documentation make sense without the changelog entries? It should.
	+
	+	Next, evaluate each changelog and ensure it adheres to our official scheme.
	+
	+	And lastly, document this scheme within the HOWTO.

ross

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/11/01 20:40		current
Line 4:		Line 4:
	Working on further documenting the [[http://docs.php.net/datetime/\|datetime]] reference.		Working on further documenting the [[http://docs.php.net/datetime/\|datetime]] reference.

-	- [[http://uvshock.co.uk/DateTimeTodo.txt\|Todo List]]	+	- [[http://uvshock.co.uk/DateTimeTodo.txt\|Todo List]]

	=== Other Tasks ===		=== Other Tasks ===

yearly

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	==== TODO to begin each calendar year ====

	+	== License years ==
	+	The main update, important places to check:
	+	* phpdoc/scripts
	+	* phpdoc/
	+	* docweb/
	+	* phd/

include

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	=== Include() docs rewrite ===
	+	The documentation for include() is rather messy and needs simplification. This is perhaps the most common construct used in PHP and should be treated as such.

	+	=== Notes ===
	+	The require() and _once() documentation all refer to include(), and this is good.
	+
	+	=== TODO ===
	+	Evaluate the page, and rewrite.

installrole

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	=== Installation section rewrite ===
	+	Each extension has its own configuration and installation section, and these sections don't really follow a standard. We need a standard.
	+
	+	=== OS ===
	+	The main issue is Windows versus Unix. Currently this is done in many ways so it's rather confusing.
	+
	+	For details, see: http://markmail.org/message/c7hz3yycg4mvyje5
	+
	+	=== PECL ===
	+	Whether or not an extension is in PECL is another issue, as is worrying about if it moved to or from PHP core.
	+
	+	=== TODO ===
	+	Essentially this task involves three steps.
	+
	+	* Evaluate the current situation
	+	* Propose a format that each extension will use
	+	* Implement

rsync_doc_build_migration

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/09/01 07:02	current
Line 1:	Line 1:
	+	=== Move doc builds off the rsync machine ===
	+	This task involves moving the doc builds off of the rsync machine, and instead using docs.php.net to build, which are then pushed to rsync for mirror distribution.

	+	* Probably pushed weekly
	+	* Remember the sqlite index script
	+	* Consider phd stable vs phd trunk for builds
	+	* Be sure the build isn't broken before pushing to rsync
	+	* Be sure the appropriate files are pushed

refstruct-progress

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/03/21 20:36		current
Line 6:		Line 6:

	===== Progress =====		===== Progress =====
-	* ar (?)	+	* <del>ar</del>
	* <del>bg</del>		* <del>bg</del>
	* ca (?)		* ca (?)
Line 13:		Line 13:
	* <del>de</del>		* <del>de</del>
	* el		* el
-	* es	+	* <del>es</del>
	* fi		* fi
-	* fr	+	* <del>fr</del>
	* he		* he
	* hk		* hk
	* hu		* hu
	* <del>id</del>		* <del>id</del>
-	* it	+	* <del>it</del>
	* <del>ja</del>		* <del>ja</del>
	* kr		* kr
Line 26:		Line 26:
	* nl		* nl
	* no		* no
-	* pl	+	* <del>pl</del>
	* pt		* pt
	* <del>pt-br</del>		* <del>pt-br</del>
-	* ro	+	* <del>ro</del>
	* <del>ru</del>		* <del>ru</del>
	* sk		* sk