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>

git

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

2017/09/22 13:28		current
Line 63:		Line 63:
	''doc-en Wrapper Repository Example''		''doc-en Wrapper Repository Example''
	git init phpdoc-en		git init phpdoc-en
-	git submodule add phpdoc-en/doc-base git://github.com/php/phpdoc-base.git	+	git submodule add git://github.com/php/doc-base.git phpdoc-en/doc-base
-	git submodule add phpdoc-en/en git://github.com/php/phpdoc-en.git	+	git submodule add git://github.com/php/doc-en.git phpdoc-en/en

	== Attributes ==		== Attributes ==

benchmark

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

2009/08/14 10:58		current
Line 106:		Line 106:

	When the deploy.php script has finished, the servers are ready for installing the web applications (currently only phpBB).		When the deploy.php script has finished, the servers are ready for installing the web applications (currently only phpBB).
		+
		+	==Available files==
		+	* config.php
		+	Configuration before the deployment of the virtual machines
		+	* deploy.php START-IP
		+	Deployment script that deploys the three virtual machines to START-IP, START-IP + 1 and START-IP + 2.
		+	* functions.php
		+	Functions used for the deployment and upload/execution of commands.
		+	* installers/
		+	This is were the applications are stored
		+	* machines/
		+	This is were machine-specific files are stored, such as configuration-files and such.
		+	* roles/
		+	Here are the role-files places (files that choose which packages that are installed after the deployment)
		+	* setup.php
		+	This is a file that's included when all the servers has booted up in the deployment script and this performs configurations and additional setups.
		+	* shutdown.php
		+	This shutdowns (destroys) the virtual machines and removes the created files (ips.txt which contains the IP-adresses of the VM's) and the known_hosts file that is created when ssh and scp commands are executed.

	===phpBB3 benchmark===		===phpBB3 benchmark===

union_types_v2

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

2026/09/01 11:06	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.
	+

phd

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

2009/10/16 17:02		current
Line 52:		Line 52:
	This will create		This will create
	* "php" directory containing the "phpweb" files		* "php" directory containing the "phpweb" files
-	* "html" direcotry containing the "downloadable chunked html" files	+	* "xhtml" direcotry containing the "downloadable chunked html" files
-	* "bightml.html" file, which is the "downloadable bightml" file	+	* "bigxhtml" file, which is the "downloadable bightml" file

	See the "[[doc/phd/view\|Viewing the results]]" for various ways of viewing the rendered files.		See the "[[doc/phd/view\|Viewing the results]]" for various ways of viewing the rendered files.

updating-markup

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

2009/02/16 22:42		current
Line 1:		Line 1:
-	Updating PHP docs to the new markup	+	==== Updating PHP docs to the new markup ====

	Several PHP extensions have documentation for OO-style APIs which is written as if the documentation was a procedural API. A good example of this was ext/soap, but also ext/rar seems to be using the old markup too. So, I'm going to take this as my example. If you go to http://php.net/rar, and look over the methods of the Rar class, you can see they're documented just the same as the functions rar_close(), rar_entry_get(), etc. This isn't handy and makes the search less useful. There is a new variant of the DocBook markup which makes more sense for OO APIs, and it should be converted. This is basically a copy and paste job.		Several PHP extensions have documentation for OO-style APIs which is written as if the documentation was a procedural API. A good example of this was ext/soap, but also ext/rar seems to be using the old markup too. So, I'm going to take this as my example. If you go to http://php.net/rar, and look over the methods of the Rar class, you can see they're documented just the same as the functions rar_close(), rar_entry_get(), etc. This isn't handy and makes the search less useful. There is a new variant of the DocBook markup which makes more sense for OO APIs, and it should be converted. This is basically a copy and paste job.
Line 39:		Line 39:

	TODO: Describe fixing user notes.		TODO: Describe fixing user notes.
		+	TODO: Describe how to deal with old CVS history... links to old files should be in the commit message at least.

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>

phd_ide

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

2011/07/08 13:31		current
Line 49:		Line 49:
	=== SQLite 3 ===		=== SQLite 3 ===
	<code bash>		<code bash>
-	$ phd --docbook path/to/.manual.xml -- package IDE --format sqlite	+	$ phd --docbook path/to/.manual.xml --package IDE --format sqlite
	</code>		</code>
	==== Conclusion ====		==== Conclusion ====

	The PhD_IDE PhD package allows customizing the output of the PHP Manual. It takes DocBook XML and converts it to a PHP object containing all (most) of the functions documentation. The main purpose is to allow IDE's to build syntax files for code insight and PHP documentation, but its usage is flexible.		The PhD_IDE PhD package allows customizing the output of the PHP Manual. It takes DocBook XML and converts it to a PHP object containing all (most) of the functions documentation. The main purpose is to allow IDE's to build syntax files for code insight and PHP documentation, but its usage is flexible.

wheretohelp

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

2010/01/08 21:11		current
Line 1:		Line 1:
	===== Source Development =====		===== Source Development =====

-	The source code behind PHP is managed through the versioning system CVS. There are three active branches:	+	The source code behind PHP is managed through the versioning system SVN. There are three active branches:
-	* PHP 5.2 (Stable) is branched as PHP_5_2	+	* PHP 5.2 (Stable) is branched as [[http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/\|PHP_5_2]]
-	* PHP 5.3 (Development) is branched as PHP_5_3	+	* PHP 5.3 (Stable) is branched as [[http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/\|PHP_5_3]]
-	* PHP 6.0 (Alpha) is HEAD, so named php-src	+	* PHP 6.0 (Alpha) is [[http://svn.php.net/viewvc/php/php-src/trunk/\|trunk]]

-	In CVS, when checking out these modules it will also automagically include the TSRM, Zend and ZendEngine2 modules.	+	In SVN, when checking out these modules it will also automagically include the TSRM, Zend and ZendEngine2 modules.

	==== Getting the source code ====		==== Getting the source code ====
-	There are two main methods for getting the latest PHP source files, either directly from CVS or by downloading a Snapshot	+	There are two main methods for getting the latest PHP source files, either directly from SVN or by downloading a Snapshot

-	=== CVS ===	+	=== SVN ===
	This is where developers actively add/modify code. A few differences from snaps:		This is where developers actively add/modify code. A few differences from snaps:
-	* You can write patches or commit to CVS	+	* You can write patches or commit to SVN
	* You can test the build tools via buildconf		* You can test the build tools via buildconf
	* Should specify the branch when checking out		* Should specify the branch when checking out

	=== Snapshots ===		=== Snapshots ===
-	Each branch is built around four times a day, and the snapshots system runs a few scripts in order to lesson the burden of required tools for building. A few differences from CVS:	+	Each branch is built around four times a day, and the snapshots system runs a few scripts in order to lesson the burden of required tools for building. A few differences from SVN:
	* Snaps do not require all build tools like buildconf and flex		* Snaps do not require all build tools like buildconf and flex
	* It's easier to deal with		* It's easier to deal with
Line 38:		Line 38:
	* Internals docs		* Internals docs
	* Example extension		* Example extension
-	* All PECL extensions (CVS)	+	* All PECL extensions (SVN)

	=== Writing an extension ===		=== Writing an extension ===

pt_br_github

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

2015/11/03 15:09		current
Line 83:		Line 83:
	O roteiro acima, até amigável, é um procedimento EXPERIMENTAL que visa substituir essa deficiência.		O roteiro acima, até amigável, é um procedimento EXPERIMENTAL que visa substituir essa deficiência.

-	=== Eu quero traduzir novos ou lidar com os arquivos tem tags de revisão! ===	+	=== Eu quero traduzir novos ou lidar com os arquivos sem tags de revisão! ===

	A melhor maneira é mesmo adotando a linha de comando, seguindo os roteiros específicos do [[pt_br_svn\|SVN]] ou [[pt_br_git\|Git]].		A melhor maneira é mesmo adotando a linha de comando, seguindo os roteiros específicos do [[pt_br_svn\|SVN]] ou [[pt_br_git\|Git]].

checkout

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

2010/01/08 21:11		current
Line 1:		Line 1:
-	===== Checking out the PHP Manual sources from SVN =====	+	===== Checking out the PHP Manual sources from SVN =====

	==== Introduction ====		==== Introduction ====
Line 22:		Line 22:
	Several svn:externals already exist within phpdoc/modules and may be used. They are setup as doc-{lang} where {lang} is the language code for the desired language, and doc-all exists to include every language.		Several svn:externals already exist within phpdoc/modules and may be used. They are setup as doc-{lang} where {lang} is the language code for the desired language, and doc-all exists to include every language.

-	svn co http://svn.php.net/repository/phpdoc/modules/doc-en phpdoc	+	svn co https://svn.php.net/repository/phpdoc/modules/doc-en phpdoc

	So, that checks out via the svn:externals to a new local directory named phpdoc.		So, that checks out via the svn:externals to a new local directory named phpdoc.
Line 30:		Line 30:
	Sparse checkouts are another option.		Sparse checkouts are another option.

-	svn co http://svn.php.net/repository --depth empty phpdoc	+	svn co https://svn.php.net/repository --depth empty phpdoc
-	svn co http://svn.php.net/repository/phpdoc/en/trunk --depth infinity phpdoc/en	+	svn co https://svn.php.net/repository/phpdoc/en/trunk --depth infinity phpdoc/en
-	svn co http://svn.php.net/repository/phpdoc/doc-base/trunk --depth infinity phpdoc/doc-base	+	svn co https://svn.php.net/repository/phpdoc/doc-base/trunk --depth infinity phpdoc/doc-base

	==== Conclusion ====		==== Conclusion ====

install

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

2012/03/07 11:30		current
Line 37:		Line 37:
	$ pear install http://doc.php.net/get/PhD-1.1.0.tgz		$ pear install http://doc.php.net/get/PhD-1.1.0.tgz
	</code>		</code>
-	==== Using SVN ====	+	==== Using GIT ====
-	NOTE: Using PhD from SVN is not recommended.	+	NOTE: Using PhD from GIT is not recommended.


Line 51:		Line 51:


-	Install and run from SVN. There are several package_*.xml files, but in the very least you'll need:	+	Install and run from GIT. There are several package_*.xml files, but in the very least you'll need:
	<code>		<code>
	$ cd phd		$ cd phd
Line 62:		Line 62:
	</code>		</code>

-	Alternately you can run PhD directly from SVN, without needing to install it. The same holds true if using the tarball, because all the phd command really does is execute "php render.php" so:	+	Alternately you can run PhD directly from GIT, without needing to install it. The same holds true if using the tarball, because all the phd command really does is execute "php render.php" so:
	<code>		<code>
	$ cd phd		$ cd phd

per-release-minor

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

2026/09/01 11:06	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.

pecldocs

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

2009/03/24 17:14		current
Line 17:		Line 17:
	</code>		</code>

-	This will create a directory named 'tmp' for the extension named 'extname' which will be full of documentation skeletons. Reflection is used to make guesses about the extension, like for classes, methods, functions, constants, parameters, version information, etc. but this information will not be fully correct. Please go through and edit each XML file by updating this information and adding documentation.	+	This will create a directory named 'tmp' that will contain documentation skeletons for the 'pecl' extension named 'extname'. Reflection is used to make guesses about the extension, like for classes, methods, functions, constants, parameters, version information, etc. but this information will not be fully correct. Please go through and edit each XML file by updating this information and adding documentation.

	* Read the Validating Changes section of the [[doc:scratchpad:howto\|PHP Documentation HOWTO]].		* Read the Validating Changes section of the [[doc:scratchpad:howto\|PHP Documentation HOWTO]].

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

writing-tests

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

2008/04/10 22:27		current
Line 1:		Line 1:
	Part of an upcoming php.net article titled "How can you help PHP.NET today?" with this part focusing on writing tests. It's essentially in a FAQ format:		Part of an upcoming php.net article titled "How can you help PHP.NET today?" with this part focusing on writing tests. It's essentially in a FAQ format:

-	* Why should I write a test?	+	===== Why should I write a test? =====
	Code coverage is important for the success of any project including PHP. When code coverage reaches 100%, it'll mean that every piece of code within the PHP sources will be executed while running the tests. This helps determine if behaviour changes so essentially it helps prevent bugs from being introduced into PHP.		Code coverage is important for the success of any project including PHP. When code coverage reaches 100%, it'll mean that every piece of code within the PHP sources will be executed while running the tests. This helps determine if behaviour changes so essentially it helps prevent bugs from being introduced into PHP.

-	* What kind of setup do I need to write good tests?	+	===== What kind of setup do I need to write good tests? =====
	gcc >= 3.4 with gcov.		gcc >= 3.4 with gcov.
	Your local setup should also include lcov that is available here:		Your local setup should also include lcov that is available here:
Line 23:		Line 21:
	In summary: Install lcov, compile PHP with --enable-gcov, and now you're ready.		In summary: Install lcov, compile PHP with --enable-gcov, and now you're ready.

-	* How do I find what needs a test?	+	===== How do I find what needs a test? =====
	* Go to gcov.php.net		* Go to gcov.php.net
	* Choose a branch, then 'coverage'		* Choose a branch, then 'coverage'
	* Will go into some detail on what it means		* Will go into some detail on what it means

-	* How do I create a test?	+	===== How do I create a test? =====
	* Go to http://qa.php.net/...		* Go to http://qa.php.net/...

-	* Do you have a good example of a test and what it covers?	+	===== Do you have a good example of a test and what it covers? =====
	* Yes...		* Yes...

-	* How do I cover uncovered code?	+	===== How do I cover uncovered code? =====
	* Locate a file with a percentage < 100%		* Locate a file with a percentage < 100%
	* Use the legend to determine uncovered code		* Use the legend to determine uncovered code
	* Write code that will execute it		* Write code that will execute it
-	*

-	* How do I determine if the desired code gets executed?	+	===== How do I determine if the desired code gets executed? =====
	* make lcov		* make lcov
	* view lcov_html/index.html		* view lcov_html/index.html
Line 48:		Line 45:
	* Note: The TESTS var is to speed-up the process, as it will only run the specific test(s)		* Note: The TESTS var is to speed-up the process, as it will only run the specific test(s)

-	* How and where do I submit my test?	+	===== How and where do I submit my test? =====
	You can submit tests to the development mailing list @ internals@lists.php.net		You can submit tests to the development mailing list @ internals@lists.php.net

-	* What is open-box and black-box testing and why do I care?	+	===== What is open-box and black-box testing and why do I care? =====

-	* Do I need valgrind? When and why might I use it?	+	===== Do I need valgrind? When and why might I use it? =====
	Short answer: You don't.		Short answer: You don't.
	Long answer: valgrind can be used to detect if some test triggers a memory-related bug in PHP. Although running the test suite with valgrind is a plus, but it takes ages. You can submit tests without running valgrind, because the http://gcov.php.net project will do that for you.		Long answer: valgrind can be used to detect if some test triggers a memory-related bug in PHP. Although running the test suite with valgrind is a plus, but it takes ages. You can submit tests without running valgrind, because the http://gcov.php.net project will do that for you.

-	* How do I install lcov on Linux, Mac, and/or Windows? What part of the package do I need?	+	===== How do I install lcov on Linux, Mac, and/or Windows? What part of the package do I need? =====
-		+	Just untar it and run make install.
-	just untar it and run make install.	+

peehaa

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

2026/09/01 11:06	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.

faq

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

2026/09/01 11:06	current
Line 1:	Line 1:
	+	==== So, How exactly do I get the source files for the PHP Manual? ====
	+	Simple. The PHP Project uses CVS to manage its sources, so to retrieve the sources for the PHP Manual you will checkout (download) these sources from CVS. An anonymous CVS user named //cvsread// exists (password: //phpfi//) that anybody in the world may use to make checkouts. For example:
	+
	+	<code>
	+	$ cvs -d :pserver:cvsread@cvs.php.net:/repository login
	+	$ cvs -d :pserver:cvsread@cvs.php.net:/repository checkout phpdoc
	+	</code>
	+
	+	The above assumes you have CVS installed. Odds are if you're using Linux or Mac that this is already installed, but Windows users aren't so lucky (or unlucky, depending on your feelings towards CVS!) The simplest method for Windows users is TortoiseCVS, see the FAQ for that.
	+
	+	There will now exist a directory named //phpdoc// that houses all sources files for the PHP Manual.
	+
	+	==== I use Windows, and heard something about TortoirseCVS... should I use it? ====
	+	Sure, it's simple and offers a friendly GUI so if you're into that then go for it! And besides, it also installs the cvs command so it may be used in your Terminal too. The steps include:
	+
	+	* Install [[http://www.tortoisecvs.org/\|TortoirseCVS]]
	+	* Open a new explorer window and go to the folder you wish to do a checkout in (store CVS files)
	+	* Right click anywhere in the blank area to spawn the context menu, select "CVS Checkout"
	+	* A new window will popup and ask for details about the checkout; these values will be remembered so will be entered just once
	+	* Enter the following:
	+	* CVSROOT: ":pserver:cvsread@cvs.php.net:/repository"
	+	* Module field: "phpdoc"
	+	* Press OK to begin the checkout. If you're prompted to enter a password while checking out, then type in "phpfi" and OK
	+	* When the checkout is complete, then it should have created a directory called "phpdoc" where the english php documentation source tree will be
	+
	+	==== I was told to create a patch, how do I do that? ====
	+	== New Files ==
	+	== Current Files ==
	+
	+	==== How do I know if my changes are good and valid? ====
	+	* Whitespace
	+	* Read diff
	+	* php configure.php
	+	* Describe when editing manual.xml.in is needed
	+	* PhD
	+
	+	==== Is there an online editor? ====
	+	* Yes and No

builds

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

2012/01/27 23:27		current
Line 16:		Line 16:
	=== Additional notes ===		=== Additional notes ===
	* If a manual does not validate on Friday, it will not be pushed to the mirrors until hopefully the upcoming Friday.		* If a manual does not validate on Friday, it will not be pushed to the mirrors until hopefully the upcoming Friday.
-	* Only active translations are selectable/downloadable, and this is managed in [[http://svn.php.net/viewvc/web/php/trunk/include/languages.inc\|phpweb/includes/languages.inc]]	+	* Only active translations are selectable/downloadable, and this is managed in [[http://git.php.net/?p=web/php.git;a=blob;f=include/languages.inc\|phpweb/includes/languages.inc]]

	=== The humans who manage these ===		=== The humans who manage these ===
	If there is a problem with the synced builds, it's wise to contact Derick or Hannes. If a problem exists on the developmental server (docs.php.net), then contact the documentation team.		If there is a problem with the synced builds, it's wise to contact Derick or Hannes. If a problem exists on the developmental server (docs.php.net), then contact the documentation team.

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

faq

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

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

	=== Download: ===		=== Download: ===
-	* View source: http://svn.php.net/viewvc/phd/trunk	+	* View source: https://svn.php.net/viewvc/phd/trunk
-	* SVN Repo: http://svn.php.net/repository/phd/trunk	+	* SVN Repo: https://svn.php.net/repository/phd/trunk
	* http://php.net/svn.php		* http://php.net/svn.php
	<code shell>		<code shell>
	$ cd /my/svn/dir		$ cd /my/svn/dir
-	$ svn co http://svn.php.net/repository/phd/trunk phd	+	$ svn co https://svn.php.net/repository/phd/trunk phd
	$ cd phd		$ cd phd
	$ ls		$ ls
Line 54:		Line 54:
	==== How do I use PhD with non-php.net centric projects? ====		==== How do I use PhD with non-php.net centric projects? ====
	* Short answer: Create a theme, and build.		* Short answer: Create a theme, and build.
-	* Long answer: It's not yet friendly for this but two close examples of smaller projects that use PhD are: The [[http://svn.php.net/viewvc/phpdoc/doc-base/trunk/howto/\|PHP documentation howto]] and [[http://svn.php.net/viewvc/phd/trunk/docs/phd-guide/\|PhD guide]].	+	* Long answer: It's not yet friendly for this but two close examples of smaller projects that use PhD are: The [[https://svn.php.net/viewvc/phpdoc/doc-base/trunk/howto/\|PHP documentation howto]] and [[https://svn.php.net/viewvc/phd/trunk/docs/phd-guide/\|PhD guide]].

view

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

2008/03/19 11:00		current
Line 1:		Line 1:
	====== Viewing the results ======		====== Viewing the results ======
-	After [[doc:phd\|building the docs]] you probably want to view them now.	+	After [[doc:phd\|building the docs]] it's time to view them. There are a few choices:
-	You have a few choices:	+
-	* See how it would be online (the php/ folder)	+
-	* Just quickly see the results (the html/ folder)	+
-	* Test how long it takes for your browser to render 20mb xhtml file (the bightml.html file)	+

		+	* View how it would look online (the php/ folder, which uses the theme used by www.php.net)
		+	* View the plain html (the html/ folder)
		+	* View the single file plain html, which is around 20mb (the bightml.html file)
		+	* And other formats that require additional setup to the build environment: chm, pdf and *nix man pages

	===== Viewing the php/ folder =====		===== Viewing the php/ folder =====
-	These files are tightly integrated into www.php.net, so to view them you need a ''phpweb'' mirror.	+	These files are tightly integrated into www.php.net, so to simplest way to view them is to
-	This method is currently the only "supported" method as the online manual is the most important one.	+	setup a ''phpweb'' mirror.

-	(Note; On Windows you are pretty much out of luck regarding instructions on setting up a ''phpweb'' mirror, you may try the following instructions but I have no idea if it would work.)	+	Note: These instructions likely don't work on Windows, but may, feel free to update them to do so (rsync alternative?)
		+
		+	So, the mirrors use the rsync command. The following will work and it disables downloading parts of the mirror (like all the distributed php source files):

	<code bash>		<code bash>
Line 21:		Line 22:
	</code>		</code>

-	Now locate your webserver configuration file and add a new virtual host.	+	Notes:
-	For an example virtual host configuration, see [[http://www.php.net/mirroring.php#settings]].	+	* Change /path/to/your/webroot/phpweb
-	Now restart your webserver. Tada!	+	* The 'ln -s' creates a symlink from your build directory to this location in the docroot
		+	* The docroot will likely be setup as a new virtual host via the web server configuration file
		+	* See also an example virtual host configuration here: [[http://www.php.net/mirroring.php#settings]].
		+	* Once the changes are made, restart the web server.

	===== Viewing the html/ folder =====		===== Viewing the html/ folder =====

	Do //not// place the contents of the html/ folder onto your webserver. Especially not if you are running apache2.		Do //not// place the contents of the html/ folder onto your webserver. Especially not if you are running apache2.
-	Just browse to the folder in your faviorite file manager and open the "index.html" file (or any page you are interested in viewing).	+	Just browse to the folder in your favorite file manager and open the "index.html" file (or any page you are interested in viewing).

	===== Viewing the bightml.html file =====		===== Viewing the bightml.html file =====

-	Double click it.	+	Is that really wise?

debian

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

2010/01/08 21:11		current
Line 26:		Line 26:
	make: *** [install-sapi] Error 1		make: *** [install-sapi] Error 1

		+	== Original Solution ==
	See [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231134\|Debian bug #231134]]		See [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231134\|Debian bug #231134]]

-	== Solution ==
	Edit /etc/apache2/httpd.conf and add		Edit /etc/apache2/httpd.conf and add
	#LoadModule dummy_module /usr/lib/apache2/modules/mod_dummy.so		#LoadModule dummy_module /usr/lib/apache2/modules/mod_dummy.so

		+	== Current Solution on Ubuntu ==
		+	This issue is in the process of being fixed ([[https://bugs.launchpad.net/bugs/500703\|Ubuntu bug #500703]]). Until then, add the configuration files manually and force the install to continue.
		+
		+	Edit /etc/apache2/mods-available/php5.load and add:
		+	LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
		+
		+	Edit /etc/apache2/mods-available/php5.conf and put in:
		+	<IfModule mod_php5.c>
		+	AddType application/x-httpd-php .php
		+	AddType application/x-httpd-php-source .phps
		+	</IfModule>
		+
		+	During the make install step, use the -k flag. The -k flag means "keep going when some targets can't be made." The output will still show the apxs error, but the installation should work. Do keep an eye out for other compile errors.
		+	make install -k
		+
		+	Then enable the php5 module and restart Apache:
		+	a2enmod php5
		+	/etc/init.d/apache2 restart

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 ===

namespacefaq

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

2008/10/28 11:51		current
Line 9:		Line 9:

	Q: Would removing constants/functions from namespaces make it possible to stick with "::" for namespaces?		Q: Would removing constants/functions from namespaces make it possible to stick with "::" for namespaces?
		+
		+	A: Yes, but at a cost. Functions and constants within namespaced files would throw a fatal error. [Reference needed]

	Q: Was the "::" separator was dropped because of limitations on the Zend Engine?		Q: Was the "::" separator was dropped because of limitations on the Zend Engine?

	Q: Was the fact that the "\" character is harder to type on various international keyboards considered and if so why was this character still chosen?		Q: Was the fact that the "\" character is harder to type on various international keyboards considered and if so why was this character still chosen?
		+
		+	A: Yes, it was considered. However the fact that "\" is already used in PHP means that nobody has a keyboard that actually lacks that character. There are also workarounds for those facing difficulties. [References needed]

	Q: Why was character combination XYZ (":::", "@" etc.) not chosen?		Q: Why was character combination XYZ (":::", "@" etc.) not chosen?
		+
		+	A: There have been long and intensive public discussions over the choice of namespace separator in the past, and everyone at the internals meeting was familiar with the arguments against a wide range of potential characters. The possibilities were therefore very limited, as documented on the wiki page about this decision. [Link to Lukas' entry]

	Q: Why was "\" chosen given that it makes it impossible to write something like "spl_autoload_register(array("myNamespace\theLoader", "load"));" because the \t would be interpreted as a tab?		Q: Why was "\" chosen given that it makes it impossible to write something like "spl_autoload_register(array("myNamespace\theLoader", "load"));" because the \t would be interpreted as a tab?
		+
		+	A: It is already impossible to write Windows paths in PHP in the same way, ergo at least half the PHP community is already familiar with the idea that they need to either use single quotation marks or escape the backslash ("\\").

	Q: Why do the PHP internals developer think that "\" is not prone to cause issues when typos are made?		Q: Why do the PHP internals developer think that "\" is not prone to cause issues when typos are made?
Line 22:		Line 30:
	Q: Don't the PHP internals developer think that the fact that "\" is widely used as the escape character will be cause for confusion?		Q: Don't the PHP internals developer think that the fact that "\" is widely used as the escape character will be cause for confusion?

-	Q: C++ uses "::" for namespaces, why did the PHP internals developer feel they needed to solve the ambiguity issues rather than leaving it to each developer to prevent ambiguity between namespace names and other identifiers?	+	A: No, because the usage context is completely different.
		+
		+	Q: C++ uses "::" for namespaces, why did the PHP internals developers feel they needed to solve the ambiguity issues rather than leaving it to each developer to prevent ambiguity between namespace names and other identifiers?
		+
		+	A: Ambiguity is an edge case, meaning that developers wouldn't necessarily be aware of the potential for it through their own past experience, and debugging would be extremely difficult. Further, there was no way to provide a PHP error message on ambiguity without impacting performance in all cases. [Reference needed]

	Q: Why wasn't the proposal chosen to just require "use namespace" and "use class" chosen?		Q: Why wasn't the proposal chosen to just require "use namespace" and "use class" chosen?

	Q: Do I have to prefix all my internal function names with \ now?		Q: Do I have to prefix all my internal function names with \ now?

feeds

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

2026/09/01 11:06	current
Line 1:	Line 1:
	+	==== Discussion List ====
	+	{{rss>http://news.php.net/group.php?group=php.doc&format=rss 10 6h}}
	+
	+	==== Commits ====
	+	{{rss>http://news.php.net/group.php?group=php.doc.cvs&format=rss 10 6h}}
	+
	+	==== Bugs ====
	+	{{rss>http://news.php.net/group.php?group=php.doc.bugs&format=rss 10 6h}}

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 11:06	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

newtranslation

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

2008/05/11 00:50		current
Line 8:		Line 8:
	* Update CVSROOT/modules		* Update CVSROOT/modules
	* Update CVSROOT/loginfo		* Update CVSROOT/loginfo
		+	* Update CVSROOT/avail (in a couple places)
	* Add {lang} to docweb for revcheck		* Add {lang} to docweb for revcheck
	* Add {lang} to phpweb/includes/languages.inc as INACTIVE		* Add {lang} to phpweb/includes/languages.inc as INACTIVE
	* Add the new {lang} mailing list to our super secret gmail doc account (user php.doc.lists)		* Add the new {lang} mailing list to our super secret gmail doc account (user php.doc.lists)

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 =====

53

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

2009/06/26 02:29		current
Line 1:		Line 1:
	====== PHP 5.3 upgrading notes ======		====== PHP 5.3 upgrading notes ======
	* This document has been removed in favor of [[http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?view=markup&pathrev=PHP_5_3\|UPGRADING]] and will eventually live in the PHP Manual (see below)		* This document has been removed in favor of [[http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?view=markup&pathrev=PHP_5_3\|UPGRADING]] and will eventually live in the PHP Manual (see below)
-	* The 5.3.0 upgrade guide can be seen here: [[http://php.net/migration53]]	+	* The 5.3.0 upgrade guide can be seen here: [[http://docs.php.net/migration53]]
-	* The 5.2.0 upgrade guide can be seen here: [[http://php.net/migration52]]	+	* The 5.2.0 upgrade guide can be seen here: [[http://docs.php.net/migration52]]
-	* The 5.1.0 upgrade guide can be seen here: [[http://php.net/migration51]]	+	* The 5.1.0 upgrade guide can be seen here: [[http://docs.php.net/migration51]]

ide-function

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

2026/09/01 11:06	current
Line 1:	Line 1:
	+	<code xml>
	+	<!--
	+	RFC: Skeleton for php-doc-function.xml
	+	Version: 0.2
	+	State: Alpha
	+	Author: Philip Olson
	+
	+	TODO:
	+	- Think other parts like class, method, predefined variables, constants, etc.
	+	- Discuss with multiple IDE developers, and ensure we include all desired information
	+	- Discuss handling of extensions with both OO and Procedural (ex: mysqli)
	+	- Discuss removing or adding elements, ex: add 'description' which might be the first paragraph of role=description?
	+	- Create a theme/format for PhD to generate this
	+	- Think about ways this could help find inconsistencies in the manual
	+	- Have methods for conversion into other forms like a sqlite db, funcindex.xml, quickref, ...
	+	- Discuss license issues for various uses like IDE integration
	+	- This deals with: http://bugs.php.net/bug.php?id=47651
	+	NOTES:
	+	- The current version (0.2) should not be taken too seriously -- it's a proof of concept
	+	Its intention is to maximize the available information by adding options for users. For
	+	example, it's likely an IDE developer will not want all of this information so they'll
	+	pull (and format) their desired elements accordingly.
	+	-->

	+	<function>
	+	<name>foobar</name>
	+	<version>PHP 3, 4, 5</version>
	+	<purpose>Checks the foo of a bar</purpose>
	+	<!-- Before going live, let's evaluate our current manual IDs and realize:
	+	- They should work forever
	+	- They are consistent
	+	- We like them
	+	- Note: some are not lowercase, problem?
	+	Typically the following url works: php.net/manualid so php.net/function.foobar
	+	-->
	+	<manualid>function.foobar</manualid>
	+
	+	<!-- This information comes from both the methodsynopsis and parameters role -->
	+	<params>
	+	<param>
	+	<name>foo</name>
	+	<type>string</type>
	+	<description>Used for this and that</description>
	+	<optional>false</optional>
	+	</param>
	+	<param>
	+	<name>bar</name>
	+	<type>integer</type>
	+	<description>Used for this and that</description>
	+	<optional>true</optional>
	+	<initializer>42</initializer>
	+	</param>
	+	</params>
	+
	+	<!-- Type from methodsynopsis, description from return role -->
	+	<return>
	+	<type>string</type>
	+	<description>This and that</description>
	+	</return>
	+
	+	<changelog>
	+	<entry>
	+	<version>4</version>
	+	<change>this and that changed</change>
	+	</entry>
	+	<entry>
	+	<version>5</version>
	+	<change>another change</change>
	+	</entry>
	+	</changelog>
	+
	+	<!-- Discuss: we may or may not want to add examples.
	+	We don't always have a return, but sometimes via screen.
	+	-->
	+	<example>
	+	<title>foo() example</title>
	+	<language>PHP</language>
	+	<code>Not sure if we want this</code>
	+	<return>42</return>
	+	</example>
	+
	+	<!-- Most documents do not have this, but some do -->
	+	<errors>
	+	<description>Other error conditions</description>
	+	</errors>
	+
	+	<!-- There are several different types of notes, discuss -->
	+	<notes>
	+	<note>
	+	<type>note</note>
	+	<description>This is needed</description>
	+	</note>
	+	<note>
	+	<type>caution</note>
	+	<description>be careful about</description>
	+	</note>
	+	<note>
	+	<type>warning</note>
	+	<description>watch out!</description>
	+	</note>
	+	</notes>
	+
	+	<!-- Determine the handling of our different type of see also links.
	+	External:
	+	- Typically contain a link and descriptive text
	+	Internal:
	+	- Typically are a single element, ex: <function>foo</function>
	+	- Sometimes include descriptive text, ex: the <link linkend="bar">bar chapter</link>
	+	- The 'purpose' of these are available in phd
	+	-->
	+	<seealso>
	+	<entry>
	+	<type>function</type>
	+	<name>baz</name>
	+	<description>purpose of baz</description>
	+	</entry>
	+	<entry>
	+	<type>unknown</type>
	+	<name>stuff within first link</name>
	+	<description>the entire text</description>
	+	</entry>
	+	</seealso>
	+
	+	</function>
	+	</code>

per-release-major

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

2026/09/01 11:06	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]]

todo

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

2017/11/15 16:05		current
Line 1:		Line 1:
	==== Existing TODO files ====		==== Existing TODO files ====
		+
		+	== Priority Tasks ==
		+	* [[doc:todo:migrationguide\|Things that needs to be documented before the next big release (PHP 7.2.0)]]

	== General tasks ==		== General tasks ==

translations

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

2008/12/23 05:31		current
Line 46:		Line 46:
	=== When we should know ===		=== When we should know ===
	The SVN conversion will be completed sometime in the first quarter of 2009, let's say March 1. We should have our system essentially in place by that time. A sequential move is possible too (Start using SVN numbers, then later gettext) but that wouldn't be ideal. However, given the size of our manual, it may be required.		The SVN conversion will be completed sometime in the first quarter of 2009, let's say March 1. We should have our system essentially in place by that time. A sequential move is possible too (Start using SVN numbers, then later gettext) but that wouldn't be ideal. However, given the size of our manual, it may be required.
		+
		+	=== Status update: May 20, 2009 ===
		+	So far I've (philip) am having success converting translations to po files using po4a. After additional tweaking the plan is to setup pootle and see what happens. We may use transifex instead so we'll see but the key is getting the po files going. The main alternative to po4a is xml2po but so far I like po4a so don't see a need to investigate xml2po much further.
		+
		+	* po4a manual: http://po4a.alioth.debian.org/man/man7/po4a.7.php
		+	* Command: po4a-gettextize -f docbook -m en/reference/strings/functions/strlen.xml -p strlen.po (creates a po file)
		+	* Command: po4a-translate -f docbook -m en/reference/strings/functions/strlen.xml -p foo.po (creates docbook file)
		+	* Command: po4a-gettextize -f docbook -m en/reference/strings/functions/strlen.xml -l ja/reference/strings/functions/strlen.xml -p foo.po (converts translation to po file)
		+
		+	So, the current plan:
		+	* Convert current translations to po files (progressing)
		+	* Setup pootle at translate.php.net
		+	* Profit

function

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

2010/01/08 21:11		current
Line 164:		Line 164:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

ini

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

2010/01/08 21:11		current
Line 86:		Line 86:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

structure

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

2010/01/08 21:11		current
Line 125:		Line 125:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

install

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

2026/09/01 11:06	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.

upgrade

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

2008/05/14 17:22		current
Line 1:		Line 1:
	===== Upgrade and Migration information =====		===== Upgrade and Migration information =====
-	Information found here will one day live within the migration section of the PHP Manual. See the manual pages for [[http://php.net/migration51\|5.2]] and [[http://php.net/migration52\|5.2]] for example manual pages.	+	Information found here will one day live within the migration section of the PHP Manual. See the manual pages for [[http://php.net/migration51\|5.1]] and [[http://php.net/migration52\|5.2]] for example manual pages.

	* [[doc:scratchpad:upgrade:53\|5.3.0]]		* [[doc:scratchpad:upgrade:53\|5.3.0]]

examples

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

2010/01/08 21:11		current
Line 39:		Line 39:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

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.

editor

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

2017/09/22 13:28		current
Line 1:		Line 1:
	====== Getting started ======		====== Getting started ======
-	Currently all documentation pages at php.net have link to the online editor, which allow anyone (anonymous or not) to edit manual pages. Link is placed under language select.	+	Currently all documentation pages at php.net have a link to the online editor, which allow anyone (anonymous or not) to edit manual pages. The link is placed under language select.

	The editor may also be accessed from here: https://edit.php.net/		The editor may also be accessed from here: https://edit.php.net/
Line 21:		Line 21:
	* your [[https://www.instagram.com\|Instagram]] account		* your [[https://www.instagram.com\|Instagram]] account

-	With a Facebook/Github/Google/Lindekin/Stackoverflow/Instagram account, we can better identify user who submit a patch.	+	With a Facebook/Github/Google/Lindekin/Stackoverflow/Instagram account, we can better identify the user who submitted a patch.

-	An anonymous user can edit any page and save the work as patch. While saving, an email may be entered that'll then be notified when the patch is approved or deleted. And all users may view patches under the "Pending Patch" tab.	+	An anonymous user can edit any page and save the work as a patch. While saving, an email may be entered that'll then be notified when the patch is approved or deleted. And all users may view patches under the "Pending Patch" tab.

	===== SVN users =====		===== SVN users =====
Line 34:		Line 34:

	====== All modules ======		====== All modules ======
-	All module are available for all languages except English, because translation related modules (like graphs displaying the translation percentage) don't make sense for English.	+	All modules are available for all languages except English, because translation related modules (like graphs displaying the translation percentage) don't make sense for English.

	===== Files Needing Translation =====		===== Files Needing Translation =====
Line 53:		Line 53:
	{{ :doc:phdoe_need_update.png?500\|}}		{{ :doc:phdoe_need_update.png?500\|}}

-	Based on the Revcheck tag, this module lists all files which have been modified in English but not yet synchronized in the chosen language. All files are sorted by folder and then filename.	+	Based on the Revcheck tag, this module lists all files which have been modified in English but not yet synchronized in the chosen language. All files are sorted by folder and their filename.

	<code><!-- EN-Revision: 288721 Maintainer: felipe Status: ready --></code>		<code><!-- EN-Revision: 288721 Maintainer: felipe Status: ready --></code>

-	Don't forget to update manually the EN-Revision number to the revision number in English from witch you update the given file.	+	Don't forget to update manually the EN-Revision number to the revision number in English from which you update the given file.

	You may simply double-click on a file to start editing them into a new tab.		You may simply double-click on a file to start editing them into a new tab.
Line 66:		Line 66:
	* On the top, the diff presents all modification made to the English language.		* On the top, the diff presents all modification made to the English language.
	* On the right, you can display the SVN log for this file, both as the chosen language and English.		* On the right, you can display the SVN log for this file, both as the chosen language and English.
-	* On the center you have 2 panels:	+	* On the center, you have 2 panels:
	* One for the LANG file		* One for the LANG file
	* One for the EN file		* One for the EN file
Line 77:		Line 77:
	{{ :doc:phdoe_file_error.png?500\|}}		{{ :doc:phdoe_file_error.png?500\|}}

-	This module present all files in error.	+	This module presents all files in error.
-	When the data is updated, there is a lot of checks done once each files.	+	When the data is updated, there is a lot of checks done once each file.
-	You can view all checks done by right-click on a file and chose the sub-menu "About error type". This action display all error type into a new tab.	+	You can view all checks done by right-click on a file and chose the sub-menu "About error type". This action displays all error type into a new tab.

	One you double-click into a file of this module, a new tab is open, similar to a "need update" tab.		One you double-click into a file of this module, a new tab is open, similar to a "need update" tab.
Line 85:		Line 85:
	* On the top, the error type for this file.		* On the top, the error type for this file.
	* On the right, you can display all SVN log for this file, into the chosen language, and into English.		* On the right, you can display all SVN log for this file, into the chosen language, and into English.
-	* On the center you have 2 panels :	+	* On the center, you have 2 panels :
	* One for the lang file		* One for the lang file
	* One for the EN file		* One for the EN file
Line 105:		Line 105:

	* On the right, you can display the SVN log for this file, both from the chosen language, and English.		* On the right, you can display the SVN log for this file, both from the chosen language, and English.
-	* On the center you have 2 panels:	+	* On the center, you have 2 panels:
	* One for the LANG file		* One for the LANG file
	* One for the EN file		* One for the EN file
Line 113:		Line 113:
	Your modification appears respectively in the 'Pending Commit' or the 'Pending Patch' module.		Your modification appears respectively in the 'Pending Commit' or the 'Pending Patch' module.

-	<code>The context menu allow you to open all files for the current extension. So, you can review all files for a given extension and be more consistent with your work.</code>	+	<code>The context menu allows you to open all files for the current extension. So, you can review all files for a given extension and be more consistent with your work.</code>

	===== Not in EN =====		===== Not in EN =====
Line 121:		Line 121:
	Usually, this happens when a file is deleted from EN tree but not yet synced in the chosen language.		Usually, this happens when a file is deleted from EN tree but not yet synced in the chosen language.

-	After double-clicking, a new tab will open and you can view the files contents. It cannot be edited here.	+	After double-clicking, a new tab will open and you can view the file's contents. It cannot be edited here.

	Right-click on it and choose "Remove this file" to add it to Pending Commit module.		Right-click on it and choose "Remove this file" to add it to Pending Commit module.
Line 143:		Line 143:
	This module lists all files which have been modified by you, or by other peoples (authenticated or not) for English files, and for the chosen language.		This module lists all files which have been modified by you, or by other peoples (authenticated or not) for English files, and for the chosen language.

-	All action (and sub-menus) depend on where the file have been modified.	+	All action (and sub-menus) depend on where the file has been modified.

	== File modified from "Need Translate" module ==		== File modified from "Need Translate" module ==
Line 186:		Line 186:
	The context-menu is identical to the context-menu of a file modified from "Need Update" module.		The context-menu is identical to the context-menu of a file modified from "Need Update" module.

-	==== Commiting changes ====	+	==== Committing changes ====
	From all of this, there is a default sub-menu "Commit..." which allows you to:		From all of this, there is a default sub-menu "Commit..." which allows you to:

installation

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

2026/09/01 11:06	current
Line 1:	Line 1:
	+	====== Installing PHP from source on different Linux distributions ======
	+	* [[doc:installation:debian\|Installing PHP from source on Debian]]

localdocsetup

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

2011/06/14 05:55		current
Line 1:		Line 1:
-	====== Checking out, building, and viewing the PHP documentation on an unofficial php.net mirror ======	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/local-setup.php\|new guide]]
-		+
-	Viewing results as a php.net mirror isn't a simple process, but it can be done. The following is one route, and it assumes:	+
-		+
-	* PHP 5.3+ is available	+
-	* A web server, specifically (in this example) Apache	+
-	* The rsync tool is available	+
-	* A basic level of shell/terminal usage, or know that shell commands follow a $ below	+
-	* A desire to build and display the documentation locally	+
-	* Your PHP Documentation path will be: /tmp/svn/doc-en (change this no doubt)	+
-	* Your local mirror path will be: /home/sites/myphpnet/ (change this no doubt)	+
-	* Your local hostname will be: http://mydocs.site/ (change this no doubt)	+
-	* You are using Linux or a Mac (@todo Make this guide Windows friendly)	+
-		+
-	If you're interested in simply setting up a local PHP mirror (and NOT build the documentation) then simply follow the [[http://php.net/mirroring\|php.net mirroring guidelines]] and ignore this document.	+
-		+
-	===== Checkout the php documentation from SVN =====	+
-		+
-	Assumptions: This assumes using /tmp as the root directory, and checkout of the English language. Adjust accordingly.	+
-		+
-	==== Option #1 : Traditional ====	+
-	<code shell>	+
-	$ mkdir /tmp/svn	+
-	$ cd /tmp/svn	+
-	$ svn co https://svn.php.net/repository/phpdoc/modules/doc-en doc-en	+
-	$ cd /tmp/svn/doc-en	+
-	</code>	+
-	==== Option #2 : Automated ====	+
-	<code shell>	+
-	$ cd /tmp	+
-	$ wget https://svn.php.net/repository/phpdoc/doc-base/trunk/scripts/create-phpdoc-setup.php	+
-	$ php create-phpdoc-setup.php -h	+
-	$ php create-phpdoc-setup.php -b /tmp/svn -l en	+
-	$ cd /tmp/svn/doc-en	+
-	</code>	+
-	===== Validate the PHP Documentation XML =====	+
-	<code shell>	+
-	$ cd /tmp/svn/doc-en	+
-	$ php doc-base/configure.php	+
-	</code>	+
-	===== Build the documentation =====	+
-		+
-	We use PhD to build the documentation. It takes the source that configure.php generates, and builds and formats the PHP documentation. PhD offers several formats including HTML (multiple or single page), PDF, Man, Epub, and others, including PHP which is what we use at php.net.	+
-		+
-	==== Install PhD ====	+
-		+
-	=== Option #1 : Traditional ===	+
-		+
-	Requirements: PEAR, and an SSL enabled PHP version greater than 5.3.0.	+
-	<code shell>	+
-	$ pear install phpdocs/PhD	+
-	$ pear install phpdocs/PhD_Generic phpdocs/PhD_PHP	+
-	$ phd --help	+
-	</code>	+
-	=== Option #2 : Automated ===	+
-		+
-	The create-phpdoc-setup.php installs PhD.	+
-		+
-	==== Use PhD to build the documentation ====	+
-	<code shell>	+
-	$ cd /tmp/svn/doc-en	+
-	$ php doc-base/configure.php	+
-	$ phd --docbook /tmp/svn/doc-en/doc-base/.manual.xml --package PHP --format php --output mydocs	+
-	$ cd /tmp/svn/doc-en/mydocs/php-web/	+
-	$ ls	+
-	</code>	+
-	Note: This builds the php.net version of the documentation, but does not contain the files and includes used to run php.net. In other words, files like the php.net headers and footers are not built by PhD and are instead stored in a separate SVN module (web/php).	+
-		+
-	Alternative: The XHTML format is simple and does not require mirroring the php.net website. The following builds manual pages as plain HTML files:	+
-	<code shell>	+
-	$ cd /tmp/svn/doc-en	+
-	$ phd --docbook /tmp/svn/doc-en/doc-base/.manual.xml --package PHP --format xhtml --output mydocs	+
-	$ cd /tmp/svn/doc-en/mydocs/php-chunked-xhtml/	+
-	$ open function.strlen.html	+
-	</code>	+
-	===== Setup a local php.net mirror =====	+
-		+
-	==== Setup an Apache virtual host ====	+
-		+
-	The official PHP mirroring documentation contains a detailed example for doing this, but here's a simpler example:	+
-		+
-	==== Download (rsync) the php.net files ====	+
-		+
-	<code shell>	+
-	$ rsync -avzC --timeout=600 --delete --delete-after --exclude='manual/' --exclude='distributions/' --exclude='extra/' --exclude='backend/notes/' rsync.php.net::phpweb /home/sites/myphpnet/	+
-	</code>	+
-		+
-	==== Symlink (or move) the generated PHP documentation to your local php.net sources ====	+
-		+
-	<code shell>	+
-	$ ln -s /tmp/svn/doc-en/mydocs/php-web /home/sites/myphpnet/manual/en	+
-	</code>	+
-		+
-	==== Configure Apache ====	+
-		+
-	* Open the apache configuration file (e.g., apache.conf, httpd.conf, apache/conf.d/virtualhosts/myphp.site, ...)	+
-	* Add the virtual host:	+
-		+
-	<code>	+
-	*<VirtualHost >**	+
-	<Directory /home/sites/myphpnet>	+
-	Options -Indexes -MultiViews	+
-	</Directory>	+
-		+
-	ServerName myphp.site	+
-	DocumentRoot /home/sites/myphpnet/	+
-		+
-	# Set directory index	+
-	DirectoryIndex index.php index.html	+
-		+
-	# Handle errors with local error handler script	+
-	ErrorDocument 401 /error.php	+
-	ErrorDocument 403 /error.php	+
-	ErrorDocument 404 /error.php	+
-		+
-	# Add types not specified by Apache by default	+
-	AddType application/octet-stream .chm .bz2 .tgz .msi	+
-	AddType application/x-pilot .prc .pdb	+
-		+
-	# Set mirror's preferred language here	+
-	SetEnv MIRROR_LANGUAGE "en"	+
-		+
-	RemoveHandler var	+
-		+
-	# Turn spelling support off (which would break URL shortcuts)	+
-	<IfModule mod_speling.c>	+
-	CheckSpelling Off	+
-	</IfModule>	+
-	</VirtualHost>	+
-	</code>	+
-		+
-	* Adjust /etc/hosts by adding the following:	+
-	<code>	+
-	127.0.0.1 myphp.site	+
-	</code>	+
-	* Restart Apache	+
-	<code shell>	+
-	$ sudo apachectl restart	+
-	</code>	+
-	===== View the new site =====	+
-		+
-	* http://myphp.site/manual/en/	+

nomenclature

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

2012/01/10 01:17		current
Line 1:		Line 1:
-	====phpdoc Nomenclature and Style Guide====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/style.php\|new guide]]
-		+
-	==Purpose==	+
-	This document exists to clarify the nomenclature and grammatical style of the PHP Manual.	+
-		+
-	==Reference==	+
-	As a general rule, American English (and not British/International English) should be used. Various resources are available at http://dict.org/.	+
-	Various grammar rules, like for affect vs. effect, there vs their, can be found here: http://owl.english.purdue.edu/handouts/grammar/	+
-		+
-	* note: I (Sean) don't care if we choose International English over American (I _am_ Canadian, after all). I just think we should choose one or the other, and stick to it	+
-	* note: I (Aidan) think American english sucks, I'd prefer International.	+
-	* note: I (Techtonik) also think International is better, because it is the language learned in many countries as foreign.	+
-	* note: I (Tularis) agree that International would be better fitting. There's a reason why it's often called International after all. As Techtonik noted above, the International version is what is taught in schools here aswell (Netherlands), though people often use a combination of both American English and International English.	+
-		+
-	==Examples==	+
-	* color, not colour	+
-	* favorite, not favourite	+
-		+
-	===Punctuation===	+
-	Punctuation in the PHP Manual follows regular grammatical rules. When writing flowing sentences, such as in function descriptions, normal punctuation should be used. Lists, titles, and sentence fragments should not be punctuated with a period. Sentences need not have two spaces between them. Commas and apostrophes should be used appropriately.	+
-		+
-	===Personalization===	+
-	The PHP Manual is a technical document, and should be written so. The use of "you" is rampant in the manual, and presents an unprofessional image.	+
-		+
-	===Exceptions===	+
-	The only exceptions to the personalization rule are:	+
-	* The PHP Tutorial	+
-	* FAQs	+
-		+
-	==Examples==	+
-	(from strip_tags	+
-		+
-	"You can use the optional second parameter to specify tags which should not be stripped."	+
-		+
-	should be:	+
-		+
-	"The optional second parameter may be used to specify tags which should not be stripped."	+
-		+
-	===Quantifiers===	+
-	The use of "less" vs. "fewer" can be confusing. As a general rule, "less" is used when the subject	+
-	cannot be precisely quantified.	+
-		+
-	==Examples==	+
-	* "The new version is less buggy" is correct.	+
-	* "There are less bugs in the new version" should be "There are fewer bugs in the new version."	+
-		+
-	===Chronology===	+
-	When referring to a specific version of PHP, "since" should not be used. "As of" should be used in this case.	+
-	Although the new style will not have this structure (a CHANGELOG instead), it's still good to know :)	+
-		+
-	==Example==	+
-	As of PHP 5, the return value is an array, not bool.	+
-		+
-	===General Grammar===	+
-	The PHP Manual should be written with particular attention to general English grammar. Contractions should	+
-	be used appropriately. Special attention should be applied to sentence construction when using prepositions	+
-	(ie, sentences should not end in prepositions).	+
-		+
-	===PHP Manual Terms===	+
-	Various non-english, technical terms are used throughout the PHP Manual, without clear indication of their	+
-	appropriate spelling. The following list clears up this issue:	+
-		+
-	^Appropriate Use ^ Inappropriate Use(s) ^	+
-	\|any way\|anyway, anyways\|	+
-	\|appendices\|appendixes\|	+
-	\|built-in\|built in, builtin\|	+
-	\|command line\|commandline, CLI\|	+
-	\|email\|e-mail\|	+
-	\|[[http://pear.php.net/manual/en/standards.exampleurls.php\|example.com]]\|php.net,google.com\|	+
-	*\|Linux\|linux, nx, nix, nux, etc\|*	+
-	\|PHP 4\| PHP4, PHP-4\|	+
-	\|PHP 5\| PHP5, PHP-5\|	+
-	\|PHP 4.3.0 \| PHP 4.3, PHP 4.3.0RC2, PHP 5.0.0BETA, PHP 4.3.0PL1\|	+
-	\|superglobals\|super globals, autoglobals\|	+
-	\|web server\|webserver\|	+
-	\|extension\|module\|	+
-	\|Windows\|windows (when referring to Microsoft Windows)\|	+
-	\|Unix\|UNIX, UNIX is a registered trademark\|	+
-	*\|the foo page [[http://www.w3.org/QA/Tips/noClickHere\|]]\|click here,go here\|**	+
-		+
-	!!TODO: Alphabetize this, add more!!	+

whitespace

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

2011/04/06 10:59		current
Line 1:		Line 1:
-	====== Why we care about whitespace ======	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/whitespace.php\|new guide]]
-	I just wanted to post a little reminder about why we care so much about whitespace. Over the years this topic has come up in many forms, usually via a whitespace unfriendly commit that is immediately followed by a fellow team members complaint. And soon after, a fix is made. There are reasons we as a group (especially all past and present editors) have been strict and anal about this topic and here's why:	+
-		+
-	==== Consistent look to the documentation ====	+
-	All the documentation ends up looking the same within all editors. The indention here is one space, no tabs, and only PHP code itself is four spaces as per our coding standards. This is a beautiful and consistent feature of the PHP manual sources.	+
-		+
-	==== Pretty diffs ====	+
-	Peer review is critical to the success of any Open Source project, including the PHP Manual. Fellow members of the team follow and read the commits so a diff should focus on changed content and not mix in whitespace manipulations. If something doesn't fit or look right, our eyes focus on it... this wastes time. Translators also rely on pretty diffs.	+
-		+
-	==== Diff === Artistic Masterpiece ====	+
-	Each diff can be seen as a piece of art. Look it over... is this something you might send your lover? Professor? Potential employer? Remember that every commit we make goes on record forever and represents the author. Making them pretty and useful means we will be pretty and useful, both individually and as a group.	+
-		+
-	==== A Diff should be perfect ====	+
-	Sometimes we want to quickly commit something and if needed update it again later. This is no good and instead we should wait until later before making the commit. There is no need to spam the mailing list with "I didn't have time and was going to fix it later" commits... there is no rush, the manual has existed for 10 years without the information and can wait another hour/day... simply save the file and attend to it later. The perfect diff meets all of the above descriptions.	+
-		+
-	====== How to create pretty whitespace =====	+
-	Unified diffs make this easy. Before any commit is made, the author should look over a diff of the edited file(s). This allows said author to find errors (like typos) as well as accidental whitespace changes. After making another change, check it again. Once the diff is as intended then commit it (after make test of course!) and move on.	+
-		+
-	I hope this helps explain why we are so strict about whitespace.	+

editing

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

2011/04/17 20:03		current
Line 1:		Line 1:
-	==== Editing existing documentation ====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/editing.php\|new guide]]
-	Simply open the files and edit them. Remember to follow the "coding standard" described in the documentation howto. And after it validates, commit.	+
-	<code>	+
-	$ vim phpdoc/en/trunk/reference/strings/strlen.xml	+
-	$ php configure.php	+
-	$ svn commit -m "Added SeeAlso strpos()" phpdoc/en/trunk/reference/strings/strlen.xml	+
-	</code>	+
-		+
-	==== Adding new documentation ====	+
-		+
-	When adding new functions or methods, there are a couple of options. Either way, the generated (or copied) files will need to be filled out.	+
-		+
-	== Option A: Copy skeleton files ==	+
-	This involves copying the skeleton files into the correct location:	+
-		+
-	<code>	+
-	cp /phpdoc/RFC/skeletons/method.xml classname/methodname.xml (for new methods)	+
-	cp /phpdoc/RFC/skeletons/function.xml functions/functionname.xml (for new functions)	+
-	</code>	+
-		+
-	* Note: "classname" is the lowercased name of the class, not a literal file name.	+
-	* Note: "methodname" is the lowercased name of the method name, not a literal file name.	+
-	* Note: "functionname" is the lowercased name of the function name, not a literal file name.	+
-		+
-	== Option B: Generating files using docgen ==	+
-	The docgen script is found within the php documentation (phpdoc/scripts/docgen/) and uses Reflection to generate documentation (DocBook) files. See the [[doc:scratchpad:pecldocs\|PECL Docs]] section for details.	+
-		+
-	==== Testing the changes ====	+
-		+
-	Methods and functions are automagically included into the hierarchy so you don't have to "configure" anything, just run "//php configure.php//" to build the .manual.xml and validate the changes. If no error occur it means you changes validated.	+
-		+
-	<code>	+
-	$ cd phpdoc	+
-	$ php configure.php	+
-	</code>	+
-		+
-	When the above outputs something like "All good. Saving .manual.xml... done." then you know it validates. Now its time to optionally check the rendering:	+
-		+
-	<code>	+
-	$ phd -d .manual.xml -P PHP -f xhtml	+
-	</code>	+
-		+
-	This will create a "html/" directory in your current working directory. Open up the files you just added in your browser and make sure everything is fine (the filenames are taken from the "xml:id" attribute on the root element of the XML file).	+
-		+
-	If everything is looking good, its time to post the changes.	+
-	==== Committing the changes ====	+
-		+
-	== Creating patches ==	+
-		+
-	If you edited existing documentation you will have to create a patch. The following will iterate recursively over the directory and push all changes into the changes.patch file:	+
-		+
-	<code>	+
-	$ svn diff > changes.patch	+
-	</code>	+
-		+
-	If you added new files you will have to create an archive of the new files you added (tar -cf changes.tar file1.xml file2.xml file3.xml). On Windows you may use an external utility to create an archive such as [[http://www.rarsoft.com/\|WinRAR]].	+
-		+
-	Then upload the archive (or patch file) to http somewhere and post the link to phpdoc@lists.php.net including a short summary of what you did.	+
-		+
-	And later committing them yourself	+
-		+
-	== Committing patches ==	+
-		+
-	If you have SVN karma then there is no need to create patches... just commit!	+

faq

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

2013/01/24 03:35		current
Line 1:		Line 1:
-	===== Questions related to writing documentation =====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/faq.php\|new guide]]
-		+
-	//If a <refentry> should not emit versioning information, what should I do?//	+
-	* Add the role="noversion" to its <refentry>	+
-	* Example: %%<refentry xml:id="reserved.variables.argc" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" role="noversion//">%%	+
-		+
-	//How do I add a link to a method?//	+
-	* Use %%<methodname>Class::Method</methodname>%%	+
-	* Note that the case does not matter when adding a link.	+
-		+
-	//How do I add an external link to the documentation?//	+
-	* All external links are added to doc-base/entities/global.ent	+
-	* Add the link there (to global.ent)	+
-	* The global.ent markup might look like: %%<!ENTITY spec.google "http://www.google.com/">%%	+
-	* Add the link to the documentation (foo.xml)	+
-	* The markup might look like: %%<link xlink:href="&spec.google;">google spec</link>%%	+
-	* Be sure the file understands the namespace with %%xmlns:xlink="http://www.w3.org/1999/xlink"%% in the root element	+
-		+
-	//I made a change to a file but want to revert this change, how?//	+
-	* To merge a file to the previous state: svn merge -rHEAD:PREV filename.xml	+
-	* Then, to commit it: svn commit filename.xml -m "reverted previous commit"	+
-		+
-	//I'm about to document a new PHP extension... how should I start?//	+
-	* Use the script found within phpdoc/doc-base/scripts/docgen/*	+
-	* Example: $ php docgen.php -h	+
-	* Example: $ php docgen.php -e simplexml -o outdir	+
-	* It creates the skeletons that you edit then commit	+
-		+
-	//I created skeletons that contain a bunch of default text, should I commit it?//	+
-	* No, edit the files before commit.	+
-	* Reason 1: Translators	+
-	* Reason 2: Temporary often becomes permanent, and bogus text is not good	+
-		+
-	//I documented an extension but it's not building. Why?//	+
-	* Likely because it has not yet been added to doc-base/manual.xml.in	+
-	* So, add the book to the appropriate reference location there. Open file for examples.	+
-	* Or, configure.php is failing... the error should help	+
-		+
-	//I want to contribute to the PHP Manual, how?//	+
-	* First, read the [[doc:HOWTO]]	+
-	* Check out the sources: $ svn checkout http://svn.php.net/repository/phpdoc/modules/doc-en	+
-	* For a translation, change the checkout to phpdoc/modules/doc-{lang} where {lang} is the language code	+
-	* ...	+
-		+
-	//How do I build and/or test the manual locally?//	+
-	* Use phpdoc/configure.php to validate and then [[doc:phd]] to build	+
-	* To validate en: $ php configure.php****	+
-	* To validate fr: $ php configure.php %%--with-lang=fr%% (Change fr to your given language code)	+
-	* To build: $ phd -d .manual.xml****	+
-	* Note: Building is not required, all you must do is check the diff and be sure it validates	+
-		+
-	//Running configure.php ends up Segfaulting, what is up?//	+
-	* There are bugs with certain versions of libxml that cause this, so hacks exist to get around it	+
-	* To execute the hack, pass in: $ php configure.php %%--disable-segfault-error%%****	+
-	* Note: This disables some error checking and beautification but raw errors will be shown	+
-	* Note: Usually the problem is a major XML syntax issue	+
-		+
-	//In the changelog, which order do the PHP versions go?//	+
-	* Newest PHP versions go above the older ones	+
-		+
-	//In the changelog, a change happened in two PHP versions. How do I enter this?//	+
-	* Multiple versions are separated by a comma, with the lesser version first. Example: %%<entry>5.2.11, 5.3.1</entry>%%	+
-		+
-	//How do I add markup for a configure option?//	+
-	* Example: %%<option role="configure">--enable-debug</option>%%	+
-		+
-	//When adding a <note>, should I add a <title>?//	+
-	* Typically titles are useful for notes, but it's not required.	+
-	* Syntax: %%<note><title>foo</title><para>note contents</para></note>%%	+
-		+
-	//A feature became available in PHP X.Y.Z, how do I document that?//	+
-	* Version information for functions is stored inside versions.xml within each extension: phpdoc/en/extname/version.xml	+
-	* Changes to functions, like added parameters, are documented within changelogs for each page	+
-	* Example Text: Feature X has been available since PHP X.Y.Z	+
-	* TODO: Research other ways, and the best way, to write this text (including dealing with code examples)	+
-		+
-	//Why does everyone care so much about whitespace?//	+
-	* See the following article: [[doc:articles:whitespace]]	+
-	* XML is one space, PHP example code is four, and max width is ~78 characters	+
-	* Exceptions: <refpurpose> is on one line, ...	+
-		+
-	//A parameter is optional, how is it documented?//	+
-	* Like normal, except methodparam receives the choice="opt" attribute, and the <initializer> tag is used to signify the default value.	+
-	* Example: %%<methodparam choice="opt"><type>bool</type><parameter>httponly</parameter><initializer>false</initializer></methodparam>%%	+
-		+
-	*//Do I need to edit these entities files?//**	+
-	* No, these are auto-generated by the configure process	+
-	* Examples: entities/file-entities.ent and en/reference/foo/entities.bar.xml	+
-	* Also, do not commit them	+
-		+
-	// How do I create a patch? //	+
-	* In the command-line, go to the SVN directory:	+
-	* cd /path/to/phpdoc/svn	+
-	* To diff the entire repository: svn diff****	+
-	* To diff a single file: svn diff foo.xml****	+
-	* Consider piping the diff to a file, so: svn diff foo.xml > mypatch.txt****	+
-		+
-	// How do I apply a patch? //	+
-	* Assuming the file with the patch is named apatch.txt	+
-	* Go to the directory with the files to be patched	+
-	* And run this command: patch -p0 < apatch.txt****	+
-		+
-	// Is there an online editor? //	+
-	* Yes and No.	+
-	* Yes one exists in SVN and is being worked on.	+
-	* No it's not yet in use.	+
-	* Demo: https://edit.php.net/	+
-		+
-	// How often is the documentation built? //	+
-	* Weekly on mirrors, several times daily on the doc server	+
-	* For specifics, see the [[doc:builds\|doc builds]] article	+
-		+
-	// I see example.outputs and example.outputs.similar entities, what's the difference? //	+
-	* The example.outputs.similar entity is used when the output may differ between executions or machines	+
-	* The example.outputs entity output will always, under all conditions, be the same	+
-		+
-	// I need to add a piece of text to three or more pages, how? //	+
-	* Add the snippet to en/language-snippets.ent as an entity	+
-	* Link to the entity within the desired pages	+
-	* This is done so translators can update one version of this text	+
-		+
-	// How do I find missing documentation? Or undocumented (proto only) documentation? //	+
-		+
-	Missing functions (no associated XML files) can be found like so (assuming a doc checkout, and PhD is installed):	+
-	<code shell>	+
-	php doc-base/configure.php	+
-	phd --docbook doc-base/.manual.xml --package PHP --format php	+
-	php doc-base/scripts/check-missing-docs.php -d output/index.sqlite	+
-	</code>	+
-	Undocumented documentation (skeletons exist, but only prototypes and basic information) can be found here: http://doc.php.net/php/undoc_functions.php	+
-		+
-	// What .subversion/config settings should I have set? //	+
-		+
-	<code>	+
-	*.xml = svn:eol-style=native;svn:keywords=Id Rev Revision Date LastChangedDate LastChangedRevision Author LastChangedBy HeadURL URL	+
-	</code>	+

structure

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

2011/04/06 10:59		current
Line 1:		Line 1:
-	==== Knowing the structure ====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/structure.php\|new guide]]
-		+
-	The documentation for extensions is located in:	+
-		+
-	/phpdoc/en/trunk/reference/extension_name/	+
-		+
-	For example, the SVN extension documentation exists in:	+
-		+
-	/phpdoc/en/trunk/reference/svn/	+
-		+
-	There you'll find several files:	+
-		+
-	* //book.xml// (Acts as the container for the extension and contains the preface. Other files (like //examples.xml// are included from here)	+
-	* //setup.xml// (Includes setup, install and configuration documentaiton)	+
-	* //constants.xml// (Lists all constants the extension declares, if any)	+
-	* //configure.xml// (Usually this information is in setup.xml, but if the file exists it is magically included into setup.xml)	+
-	* //examples.xml// (Various examples)	+
-	* //foo.xml// (Example, foo can be anything specific to a topic. Just be sure to include via //book.xml//)	+
-		+
-	A procedural extension (like SVN) also has:	+
-		+
-	* //reference.xml// (container for the functions, rarely contains any info)	+
-	* //functions/// (folder with one XML file per function that the extension declares)	+
-		+
-	And OO extensions (such as imagick) contain:	+
-		+
-	* //classname//.xml (container for the methods defined by the class, contains also basic info about it)	+
-	* //classname/// (folder with one XML per method that the class declares)	+
-		+
-	* Note: "//classname//" is the lowercased name of the class, not a literal file or directory name.	+

styleguide

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

2011/07/10 22:42		current
Line 1:		Line 1:
-	==== Style Guide ====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/style.php\|new guide]]
-	This style guide affects the PHP Manual.	+
-		+
-	=== Reference ===	+
-	We follow the following style guide as a base:	+
-		+
-	* A first-person active voice is preferred, which also means do not address the reader directly as "You"	+
-	* We follow the [[http://fedoraproject.org/wiki/DocsProject/StyleGuide\|Fedora Style Guide]]	+
-		+
-	=== Conventions specific to the PHP Manual ===	+
-	* The refpurpose should not end with a period	+
-	* Indenting is one space, and never tabs	+
-	* Whitespace changes should never be mixed with content changes	+
-	* Text that's repeated 3x or more should be defined as an entity within language-snippets.ent	+
-	* Many words, such as TRUE, FALSE, and NULL, should use the entity versions instead, like %%&true;%%	+
-	* Using %%<para>%% or %%<simpara>%% does not matter, but %%<para>%% is preferred	+
-	* Constants should be surrounded with %%<constant>%%, like %%<constant>PHP_EOL</constant>%%	+
-	* Functions should be surrounded with %%<function>%%, like %%<function>strlen</function>%% (Or, %%<methodname>%% for methods)	+
-	* Variables should be surrounded with %%<varname>%% like %%<varname>$foo</varname>%%	+
-	* ... Create "common docbook tag usages" instead of repeating....	+
-	* Examples should use the [[http://pear.php.net/manual/en/standards.php\|PEAR Coding Standards]]	+
-		+
-		+
-	=== Common mistakes ===	+
-	* Improper spacing. Mixing tabs with spaces, and indenting	+
-	* Long lines. Line width should not exceed 80 characters, although this is a loose requirement. 100 is probably fine, depending on the situation	+
-	* Committing leftover/bogus text that was generated using scripts/docgen/docgen.php. This should not be committed	+
-	* Windows line endings. Only use Unix line endings	+
-	* Having an IDE or Text editor remove trailing whitespace, then mixing it with commits. Don't do this	+
-	* Mixing %%&example.outputs.similar;%% and %%&example.outputs;%% entities. Use the former when the example output may differ, depending on the users usage/settings	+

configure

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

2010/01/08 21:11		current
Line 29:		Line 29:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

oo

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

2010/01/08 21:11		current
Line 110:		Line 110:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

reference

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

2010/01/08 21:11		current
Line 23:		Line 23:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

setup

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

2010/01/08 21:11		current
Line 45:		Line 45:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

changelog

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

2026/09/01 11:06	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 11:06	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/

articles

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

2014/04/06 10:30		current
Line 1:		Line 1:
-	==== Documentation related articles ====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-	* [[doc:articles:localdocsetup\|Setting up Documentation environment]]	+
-	* [[doc:articles:nomenclature\|Nomenclature guide]]	+
-	* [[doc:articles:whitespace\|Why whitespace is important in phpdoc]]	+
-	* [[doc:articles:newtranslation\|Adding a new translation]]	+
-	* [[doc:articles:updating-markup\|Updating documentation to new OO markup]] - historical document	+

howto

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

2011/07/10 22:51		current
Line 1:		Line 1:
-	===== HOWTO contribute to the PHP Manual =====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-		+
-	=== Introduction ===	+
-		+
-	PHP is well known for having excellent documentation, documentation that is created by volunteers who collectively make changes every day. This HOWTO is designed for people who work on the official PHP documentation. See also http://www.php.net/docs for viewable and downloadable versions of the PHP manual.	+
-		+
-	This HOWTO contains information about every aspect of the documentation process, which includes editing the DocBook XML sources, validating changes made to these sources, using the build system to generate documentation into other formats, and general tips like how to use SVN.	+
-		+
-	Related to this HOWTO is the simple README file that lives within the [[http://svn.php.net/viewvc/phpdoc/\|phpdoc SVN module]]. It's a quick guide for those already familiar with the basics of XML and SVN.	+
-		+
-	=== TOC ===	+
-		+
-	* [[doc/howto/gettingstarted]] - Getting started and setup to handle the docs	+
-	* [[doc/howto/communication]] - How the Documentation team communicates	+
-	* [[doc/howto/docbook]] - Information about DocBook, which is how the sources are stored	+
-	* [[doc/howto/translations]] - Translation specific information	+
-	* [[doc/howto/pecldocs]] - PECL specific information	+
-	* [[doc/howto/faq]] - Frequently asked questions	+
-	* [[doc/howto/structure]] - Structure of the docs	+
-	* [[doc/howto/skeletons]] - Doc XML skeletons	+
-	* [[doc/howto/styleguide]] - Style Guide	+
-	* [[doc/howto/editing]] - Editing, validating and building the docs	+
-		+
-	=== Feedback ===	+
-		+
-	Feedback is most certainly welcome on this document. Without your submissions and input, this document wouldn't exist. Please send your additions, comments and criticisms to the following email address: <phpdoc@lists.php.net>.	+

scratchpad

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

2011/04/06 10:59		current
Line 4:		Line 4:
	===== Topics =====		===== Topics =====
	* [[doc:scratchpad:upgrade\|Upgrade/migration Documentation]]		* [[doc:scratchpad:upgrade\|Upgrade/migration Documentation]]
-	* [[doc:scratchpad:howto\|The Documentation HOWTO]]
	* [[doc:howto:translations\|How to do Translations for the Manual]]		* [[doc:howto:translations\|How to do Translations for the Manual]]
	* [[doc:scratchpad:pecldocs\|How to document a PECL extension]]		* [[doc:scratchpad:pecldocs\|How to document a PECL extension]]

communication

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

2011/04/06 10:59		current
Line 1:		Line 1:
-	===== Communication =====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-		+
-	There are four main routes of communication for discussing PHP documentation:	+
-		+
-	* The [[http://php.net/mailing-lists\|phpdoc@lists.php.net]] mailing list	+
-	* The [[http://news.php.net/\|doc-$LANG@lists.php.net]] mailing lists (where $LANG is a lang code)	+
-	* IRC ([[irc://irc.efnet.net/php.doc\|EFnet #php.doc]])	+
-	* Bugs database (http://bugs.php.net)	+
-		+
-	The main mailing list is the main avenue for chat and must be used when discussing major changes to the documentation. It's also used by people wanting to contribute to the project, and really anything related to the PHP documentation.	+
-		+
-	The doc-$LANG lists are dedicated to the translations. They include commit information but also are a place to discuss topics specific to a given translation.	+
-		+
-	IRC is often used when people are collaborating or brain storming for ideas, or for those times when a second set of eyes just seems like a good idea. Of course the mailing list works great for all of this too.	+
-		+
-	The Bugs database is used for, you guessed it, bugs.	+

docbook

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

2011/04/06 10:59		current
Line 1:		Line 1:
-	==== Introduction ====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-		+
-	First, don't be worried about learning another language or syntax because DocBook is fairly straight forward and most contributors simply cut-n-paste existing files, modify the content, then commit. It's just plain text.	+
-		+
-	==== What is DocBook? ====	+
-		+
-	The following is a quote from DocBook: The Definitive Guide:	+
-		+
-	DocBook is a very popular set of tags for describing books, articles, and other prose documents, particularly technical documentation. DocBook is defined using the native DTD syntax of SGML and XML. Like HTML, DocBook is an example of a markup language defined in SGML/XML.	+
-		+
-	Simply this means that writing a DocBook file is no more than writing a text file and using a few simple "tags" when needed. Like HTML, an opening tag is a < bracket followed by the tag's name, optionally some arguments, and then the > bracket (e.g. <para> for paragraphs). A closing tag is a < bracket followed by a / sign, the tag name, then the closing > bracket (e.g. </para> for paragraphs). For example uses, have a look at an existing file within the PHP manual sources, or use the documentation skeletons.	+
-		+
-	As described above, DocBook uses a similar structure to HTML with the main difference being DocBook uses tags to define the meaning whereas HTML often times defines the look and layout. So the idea behind DocBook is to define as much as possible about the information so that build and rendering software will intelligently output the text into many formats.	+
-		+
-	==== Why do we use DocBook? ====	+
-		+
-	We use DocBook because it makes it easy to generate several formats of our documents (HTML, PDF, Microsoft HTML Help (CHM), RTF, etc.), and DocBook is the standard way for storing structured technical information.	+
-		+
-	==== Our DocBook history ====	+
-		+
-	DocBook version upgrade history: On January 2, 2007 we upgraded from DocBook 4.1.2 to 4.5 and then to DocBook 5 at around June 20, 2007. These upgrades included changes to most files in the phpdoc CVS repository.	+
-		+
-	==== DocBook reference ====	+
-		+
-	For information about the DocBook DTD, look here: http://www.oasis-open.org/docbook/.	+
-		+
-	There is a DTD reference for DocBook at: http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html.	+
-		+
-	Get Going With DocBook, Notes for Hackers: http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro.html.	+
-		+
-	You can also find more information and downloads of style sheets and other tools for DocBook in the DocBook Open Repository at: http://docbook.sourceforge.net/.	+
-		+
-	You can also read the book DocBook: The Definitive Guide online, or buy it at a bookstore, but be warned, that the first edition of the book (currently the only printed edition available) contains outdated information.	+
-		+
-	There is a great DocBook Wiki, where you can collect information on DocBook editors, transformation tools, etc.	+

gettingstarted

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

2013/04/28 10:31		current
Line 1:		Line 1:
-	===== What is needed =====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-		+
-	==== Joining the PHP Documentation team ====	+
-		+
-	Joining the PHP Documentation team is a simple process, but a process nonetheless. It can be summarized as:	+
-		+
-	== Write the mailing list ==	+
-		+
-	Because official communication is done there, you should [[doc/howto/communication\|write the list]]. Say "Hi" and what you're interested in doing. You may feel more comfortable lurking for awhile, or reading the archives, or hanging out in IRC (#php.doc on Efnet) for awhile, but ultimately let the list know who you are.	+
-		+
-	== Create a doc patch or three ==	+
-		+
-	This shows a few things:	+
-		+
-	* That you really do intend to do some work	+
-	* That you're a real human	+
-	* That you know, for the most part, what you're doing	+
-		+
-	This HOWTO covers how to do this (checkout from SVN, edit, svn diff foo > doc.patch) but ultimately you must do it. We're all in the same boat here, so please jump on board!	+
-		+
-	Or, another (and simpler) way to get started is by using the [[https://edit.php.net/\|Online Documentation Editor]] which allows you to login via facebook/twitter/google connect and write patches.	+
-		+
-	== Talk about the patch ==	+
-		+
-	So now that you've showed initiative enough to actually setup the documentation toolchain, make edits, and create a nice looking patch (or three), it's time to let people know about it. Post it to the mailing list. People will offer feedback and advice, and do remember that we all make mistakes so don't be afraid. The most common mistakes involve whitespace issues so watch that whitespace! :)	+
-		+
-	== Gain commit access ==	+
-		+
-	After talking about the patch, you'll be asked to request a SVN account and soon thereafter it'll be approved with PHP documentation karma granted. In other words, commit your own patches! PHP peer review happens after commits are made, and most committers receive emails regarding each commit and have a look. Essentially, we all trust each other and enjoy seeing each other work.	+
-		+
-	==== Subversion (SVN) ====	+
-		+
-	Since the documentation is stored in SVN, you'll need a SVN client. SVN is a common form of version control and every operating system has clients for this. A client does not mean a GUI although some people prefer GUI interfaces. The following list is not exhaustive put should provide an idea for what we're talking about.	+
-		+
-	== Windows ==	+
-		+
-	The most common is TortoiseSVN. Here are the steps to checkout the sources of the PHP manual using it:	+
-	* Download and install TortoiseSVN: [[http://tortoisesvn.net/]]	+
-	* Open a new explorer window and go to the folder you wish to do the checkout into	+
-	* Right click anywhere in the blank area to spawn the context menu, select "SVN Checkout..."	+
-	* A new window will popup asking for details about the checkout, these values will be remembered, so you will not need to enter them again	+
-	* Enter the following URL: "https://svn.php.net/repository/phpdoc/modules/doc-en/", then OK to begin the checkout	+
-		+
-	== Mac ==	+
-		+
-	The command-line works fine, download/install the sources (or binaries) from [[http://subversion.tigris.org/]]	+
-		+
-	== Linux ==	+
-		+
-	The command-line works fine, download/install the sources (or binaries) from [[http://subversion.tigris.org/]]	+
-	==== The source files ====	+
-		+
-	//Note:// There are two ways. Everyone should have a local checkout, but the [[https://edit.php.net/\|Online Editor]] also works.	+
-		+
-	Using SVN, checkout the source files of the PHP manual. These are the files you will edit and commit, and anyone (no account is required) may checkout these files. For example, using the command-line:	+
-		+
-	* ''svn checkout https://svn.php.net/repository/phpdoc/modules/doc-en phpdoc''	+
-		+
-	That will use svn:externals to checkout both the doc-base and en/ modules, into a local directory named phpdoc. Then, after the above you might:	+
-		+
-	* ''cd phpdoc''	+
-	* ''vim en/preface.xml''	+
-	* ''php doc-base/configure.php''	+
-		+
-	In other words, this will create a directory named 'phpdoc' with a subdirectory 'en' that contains all of the English files. And a 'doc-base' directory with files used to validate/build/help the process. Now, a translator will instead do something like the following (to checkout German):	+
-		+
-	* ''svn checkout https://svn.php.net/repository/phpdoc/modules/doc-de phpdoc-de''	+
-	* ''cd phpdoc-de''	+
-	* ''vim de/preface.xml en/preface.xml''	+
-	* ''php doc-base/configure.php %%--%%with-lang=de''	+
-		+
-	Note: The above can all be done anonymously, therefore does not require a SVN account. Going through the above process is required before gaining SVN access, as is submitting a few patches to the [[communication\|phpdoc mailing list]]. After doing so, people realize your're both sane and serious, [[http://php.net/svn-php\|apply for SVN access]] and it will granted so you may commit changes to the PHP documentation yourself.	+
-		+
-	==== PHP ====	+
-		+
-	You'll need a recent version of PHP. Since the build system requires PHP 5.3, you should probably install it. However, building the manual is optional as validation (ensuring XML changes are valid) is a separate process and will work with any version of PHP 5.	+
-		+
-	==== PhD ====	+
-		+
-	The build system that builds both the downloadable and online versions of the PHP manual. It also builds the PEAR manual, and several other DocBook 5 based documents. Installing PhD is optional, however it's recommended so you may see what your changes will look like.	+
-		+
-	Note: doc-base/configure.php is not part of phd. configure.php is what turns all the XML files into one monolithic XML files that phd then processes, therefore, running configure.php before each use of phd is required.	+
-		+
-	==== A text editor ====	+
-		+
-	Any will do, as XML is simply text. Most text editors provide syntax highlighting for XML files.	+
-		+
-	Note: Please disable the 'remove ending whitespace' feature of your text editor.	+

pecldocs

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

2014/02/26 15:13		current
Line 1:		Line 1:
-		+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-	====Writing PECL Documentation====	+
-		+
-	PECL documentation is stored within the official PHP Manual, and while releasing a PECL extension it's important to publish documentation to allow users to find and know how to use the extension, and easily allow others to contribute to these docs.	+
-		+
-	The process of writing documentation is as follows:	+
-		+
-	* Load the PECL extension into PHP CLI.	+
-	* Checkout the SVN modules, namely phpdoc/en and phpdoc/doc-base. For how, see: [[doc:scratchpad:howto:checkout]]	+
-	* Read the README found within phpdoc for a quick overview of how these docs work	+
-	* Generate the documentation skeletons like so:	+
-		+
-	<code>	+
-	$ cd phpdoc/doc-base/scripts/docgen	+
-	$ php docgen.php --help	+
-	$ php docgen.php --output tmp --extension extname --pecl	+
-	</code>	+
-		+
-	This will create a directory named 'tmp' that will contain documentation skeletons for the 'pecl' extension named 'extname'. Reflection is used to make guesses about the extension, like for classes, methods, functions, constants, parameters, version information, etc. but this information will not be fully correct. Please go through and edit each XML file by updating this information and adding documentation.	+
-		+
-	* Read the Validating Changes section of the [[doc:scratchpad:howto\|PHP Documentation HOWTO]].	+
-	* Once validated, commit this documentation.	+
-		+
-	If the user account lacks phpdoc karma, write the documentation list (phpdoc@lists.php.net) and put in the request. While doing this, show the created documentation and eventually karma will be granted.	+
-	==== What the PECL extension requires ====	+
-	Because docgen utilizes Reflection to create the skeletons, it's necessary for the extensions code to use arginfo structs to provide parameter information.	+
-		+
-	For example, the count() source code has this:	+
-	<code>	+
-	/* Definition of the arginfo */	+
-	ZEND_BEGIN_ARG_INFO_EX(arginfo_count, 0, 0, 1)	+
-	ZEND_ARG_INFO(0, var)	+
-	ZEND_ARG_INFO(0, mode)	+
-	ZEND_END_ARG_INFO()	+
-		+
-	*/ Implement it /*	+
-	zend_function_entry basic_functions[] = {	+
-	PHP_FE(count, arginfo_count),	+
-	{NULL, NULL, NULL}	+
-	};	+
-	</code>	+
-		+
-	Which eventually provides Reflection the information, so:	+
-		+
-	<code>	+
-	$ php --rf count	+
-		+
-	Function [ <internal:standard> function count ] {	+
-		+
-	- Parameters [2] {	+
-	Parameter #0 [ <required> $var ]	+
-	Parameter #1 [ <optional> $mode ]	+
-	}	+
-	}	+
-	</code>	+
-	Need more information? Here's a [[http://cweiske.de/howto/hackingphp5/Hacking.html\|rough draft]] that will one day find itself within the official documentation.	+
-		+
-	==== Other Notes ====	+
-	* Docgen may be used to generate specific documentation too, like for individual classes and functions	+
-	* Write in third person voice (no "You")	+
-	* XML is single spaced	+
-	* Don't commit skeletons and "fill them out later", commit them when they are filled out	+
-	* Skeletons generate several sections that you may not use, such as examples and errors... in this case delete them	+
-	* Don't commit auto-generated files from build time (like entities.*)	+
-	* Feel free to ask phpdoc@lists.php.net for code review, or #php.doc on Efnet	+
-	* When testing, be sure to add to manual.xml.in in phpdoc/ otherwise it won't be validated/tested/built	+
-	* When adding documentation to an already documented extension, the --copy and --phpdoc directives are used to copy only new docs over	+
-	* Use --seealso to add skeleton SeeAlso roles, and --example to add skeleton Example roles (and adds a examples.xml).	+
-	* Use --test to enter test mode, which affects a few things like when enabled, --copy will print what it would have copied	+

skeletons

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

2011/04/06 10:59		current
Line 1:		Line 1:
-	==== PHP Documentation Structure and Skeletons ====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-		+
-	=== Skeletons ===	+
-	* [[doc:skeletons:book\|book.xml]]	+
-	* [[doc:skeletons:configure\|configure.xml]]	+
-	* [[doc:skeletons:constants\|constants.xml]]	+
-	* [[doc:skeletons:examples\|examples.xml]]	+
-	* [[doc:skeletons:function\|function.xml]]	+
-	* [[doc:skeletons:ini\|ini.xml]]	+
-	* [[doc:skeletons:reference\|reference.xml]]	+
-	* [[doc:skeletons:setup\|setup.xml]]	+
-		+
-	=== Structure ===	+
-	* [[doc:skeletons:structure\|File structure]]	+
-	* [[doc:skeletons:oo\|OOP Structure]]	+
-		+
-	=== WIP Guides ===	+
-	* Guide to [[doc:scratchpad:pecldocs\|documenting a PECL extension]]	+
-	* Guide to [[translations\|Working on a Translation of the PHP Manual]]	+
-		+

translations

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

2011/04/06 10:59		current
Line 1:		Line 1:
-	===== Working with Translations =====	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]
-		+
-	=== Introduction ===	+
-		+
-	The PHP Manual is translated into several languages, but this process requires humans to constantly update each language.	+
-		+
-	=== Getting started ===	+
-		+
-	A few steps must be taken before working on a translation.	+
-		+
-	And since this document is not complete, please read the official HOWTO on this topic:	+
-		+
-	* http://doc.php.net/php/dochowto/chapter-translation.php	+
-		+
-	Also, read the [[doc:howto\|HOWTO]] for additional information, like how to download the documentations source from CVS.	+
-		+
-	== Determine if the translation exists, and if it's active ==	+
-		+
-	This is an easy step for several languages, but not for those that are considered outdated. A few places to look:	+
-		+
-	* Each week a suite of tools are ran against the translations, with the results online here:	+
-	* http://doc.php.net/php/	+
-		+
-	The mailing list. Each translation has its own mailing list that receives both commits and discussion. The lists will show up as php.doc.{lang} below, whereas the mailing address is doc-{lang}@lists.php.net where {lang} is the appropriate country/language code.	+
-		+
-	* http://news.php.net/	+
-		+
-	Several tools/scripts exist within the documentation files that help out finding errors and/or information related to the translation. The output of these scripts are also online:	+
-		+
-	* http://doc.php.net/trantools/	+
-		+
-	=== Write the appropriate mailing list ===	+
-		+
-	Send an email to the translations list and introduce yourself. If you're interested in translating a certain section, say so, or ask for suggestions. While writing this introduction, also send a copy to the main documentation list (phpdoc@lists.php.net).	+
-		+
-	=== Start work on the translation ===	+
-		+
-	The main documentation HOWTO discusses working on the English version, but a few translation specific notes are worth mentioning here:	+
-		+
-	* Add the EN-Revision tag to each translated file.	+
-	* Check out either:	+
-	* phpdoc-all : includes English (phpdoc-all/en/) and every translation (phpdoc-all/{lang}	+
-	* phpdoc-{lang} for the translation, which includes the English version (in en/)	+
-	* Commits go to the translation go to the appropriate list whereas English commits go to doc-cvs@lists.php.net	+

usage

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

2026/09/01 11:06	current
Line 1:	Line 1:
	+	===== PhD Usage ===
	+	First, check out the internal help information:
	+	<code>
	+
	+	$ phd -h
	+
	+	PhD version: 0.2.4
	+	Copyright (c) 2008 The PHP Documentation Group
	+
	+	-v
	+	--verbose <int> Adjusts the verbosity level
	+
	+	-f <formatname>
	+	--format <formatname> The build format to use
	+
	+	-t <themename>
	+	--theme <themename> The theme to use
	+
	+	-i <bool>
	+	--index <bool> Index before rendering (default) or load from cache (false)
	+
	+	-d <filename>
	+	--docbook <filename> The Docbook file to render from
	+
	+	-p <id[=bool]>
	+	--partial <id[=bool]> The ID to render, optionally skipping its children chunks (default to true; render children)
	+
	+	-s <id[=bool]>
	+	--skip <id[=bool]> The ID to skip, optionally skipping its children chunks (default to true; skip children)
	+
	+	-l <formats/themes>
	+	--list <formats/themes> Print out the supported formats/themes (default: both)
	+
	+	-o <directory>
	+	--output <directory> The output directory (default: .)
	+
	+	-c <color>
	+	--color <color> Enable color output when output is to a terminal,
	+	optionally specify numerical color value (default: false)
	+
	+	-V
	+	--version Print the PhD version information
	+
	+	-h
	+	--help This help
	+	</code>
	+
	+	===== Descriptions of each argument ====
	+	%%--verbose%%
	+	* VERBOSE_INDEXING
	+	* VERBOSE_FORMAT_RENDERING
	+	* VERBOSE_THEME_RENDERING
	+	* VERBOSE_RENDER_STYLE
	+	* VERBOSE_PARTIAL_READING
	+	* VERBOSE_PARTIAL_CHILD_READING
	+	* VERBOSE_TOC_WRITING
	+	* VERBOSE_CHUNK_WRITING
	+	* VERBOSE_NOVERSION
	+	* VERBOSE_ALL
	+	* VERBOSE_DEFAULT

howto

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

2011/04/06 10:59		current
Line 1:		Line 1:
-	This page has been removed, in favor of: [[doc/howto]]	+	This page has been removed, in favor of [[http://doc.php.net/tutorial/\|new guide]]

book

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

2010/01/08 21:11		current
Line 35:		Line 35:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

constants

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

2010/01/08 21:11		current
Line 34:		Line 34:
	indent-tabs-mode:nil		indent-tabs-mode:nil
	sgml-parent-document:nil		sgml-parent-document:nil
-	sgml-default-dtd-file:"../../../manual.ced"	+	sgml-default-dtd-file:"~/.phpdoc/manual.ced"
	sgml-exposed-tags:nil		sgml-exposed-tags:nil
	sgml-local-catalogs:nil		sgml-local-catalogs:nil

include

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

2026/09/01 11:06	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 11:06	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 11:06	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

pt_br

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

2016/04/11 03:38		current
Line 1:		Line 1:
-	====== This page contens is being MOVED to https://github.com/phpdocbrbridge/traducao/wiki ======	+	All the information has been moved to [[https://github.com/phpdocbrbridge/traducao/wiki]].
-		+
-		+
-	====== Apêndices ======	+
-		+
-	===== Translation Fest 2014 =====	+
-		+
-	=== Canais de comunicação ===	+
-		+
-	* Canal IRC irc.freenode.net/phpdocbr (com interface web em [[https://webchat.freenode.net/?channels=phpdocbr\|https://webchat.freenode.net/?channels=phpdocbr]])	+
-	* Sala no Gitter em [[https://gitter.im/phptranslationfestbrasil/chat]]	+
-	* Trello disponível em [[https://trello.com/b/j6Nuulpn/lista-de-tarefas-traducao-pt-br]].	+
-		+
-	Os últimos dois são específicos do esforço de tradução do Translation Fest, e o primeiro não costuma ter movimento ou pessoas online. Acaba que a lista de email oficial é o caminho para falar da tradução.	+
-		+
-	=== Dependências para ambiente completo ===	+
-		+
-	* git	+
-	* subversion	+
-	* php5-cli	+
-	* php-pear	+
-	* php5-sqlite	+
-	* phd	+
-		+
-	Quase tudo você instala via apt-get/yum/brew, exceto o phd. O phd pode ser instalado facilmente assim:	+
-		+
-	<code>	+
-	git clone git@github.com:php/phd.git	+
-	cd phd	+
-	sudo pear install package.xml package_generic.xml package_php.xml	+
-	</code>	+
-		+
-	=== Ambientes prontos ===	+
-		+
-	Você pode utilizar uma máquina virtual com as dependências já instaladas. Para isso, siga os próximos passos.	+
-		+
-	== Baixar e instalar o Oracle Virtual Box ==	+
-		+
-	Utilize a página abaixo para instalar o Virtual Box na sua máquina.	+
-		+
-	https://www.virtualbox.org/wiki/Downloads	+
-		+
-	== Máquinas virtuais prontas ==	+
-		+
-	Baixe a máquina virtual de sua preferência nos endereços abaixo.	+
-		+
-	= Máquina Virtual Ubuntu 14.04 32bits (3,8Gb) =	+
-		+
-	* md5sum 83c4947594ebdae38dc4ec515eef94c7	+
-	* Usuário root Senha translationfest	+
-	* https://drive.google.com/file/d/0BzJtYovThzl_ZEdlTVVvQXpWR2c/view?usp=sharing	+
-		+
-	Nessa maquina ainda é preciso instalar o package_php antes de compilar o manual, você pode fazer isso da seguinte forma:	+
-		+
-	<code>	+
-	cd ~/translation_fest/phd	+
-	sudo pear install package_php.xml	+
-	</code>	+
-		+
-	= Máquina Virtual xUbuntu 14.04 64bits (1,6Gb) =	+
-		+
-	* md5sum ad167d8953a36996d14f422f2942538f	+
-	* Usuário xubuntu Senha reverse	+
-	* Usuário root Senha reverse	+
-	* https://dl.dropboxusercontent.com/u/3528005/xUbuntu64.7z	+
-		+
-	Nessa maquina ainda é preciso instalar o package_php antes de compilar o manual, você pode fazer isso da seguinte forma:	+
-		+
-	<code>	+
-	cd ~/translation_fest/phd	+
-	sudo pear install package_php.xml	+
-	</code>	+
-		+
-	= Máquina Virtual xUbuntu 14.04 32bits (2,0Gb) =	+
-		+
-	* md5sum 494e45601657efe973d1b1f19853b4f9	+
-	* Usuário xubuntu Senha reverse	+
-	* Usuário root Senha reverse	+
-	* https://drive.google.com/file/d/0BxhT5kE991U5VmdCRHlDbHd4LTQ/view?usp=sharing	+
-		+
-	Nessa maquina ainda é preciso instalar o package_php antes de compilar o manual, você pode fazer isso da seguinte forma:	+
-		+
-	<code>	+
-	cd ~/translation_fest/phd	+
-	sudo pear install package_php.xml	+
-	</code>	+
-		+
-	= Máquina Virtual centOS 7 64bits (740Mb) =	+
-		+
-	* md5sum 3794c55e94de29a4001ecaec2ce1cc50	+
-	* shasum 678c97df3d059ad784035a9a2cb7c299d0fefb1d	+
-	* Usuário root Senha tfest	+
-	* https://www.dropbox.com/s/g8olctbyje9o5lg/TranslationPHP.ova?dl=0	+
-		+
-	Existe um compartilhamento nfs na pasta /root/translationfest para que a máquina host possa ler os arquivos. Basta montar como um compartilhamento de rede. Funciona em Windows/Linux/Mac.	+
-		+
-	== Instalar as dependências no Ubuntu (e similares) ==	+
-		+
-	Caso não esteja usando uma máquina virtual, você também pode usar o script abaixo para instalar as dependências numa máquina Ubuntu:	+
-		+
-	<code>	+
-	source <(wget -qO- https://gist.github.com/royopa/599259ebeffa6ab7b1cb/raw/)	+
-	</code>	+
-		+
-	Pronto, você já pode começar a editar o manual.	+
-		+
-	== Atualize o repositório svn da documentação ==	+
-		+
-	Assim que iniciar o trabalho em qualquer dos ambientes escolhidos, atualize o repositório svn da documentação, com o comando:	+
-		+
-	<code>	+
-	cd ~/translation_fest/doc-pt_BR	+
-	svn up	+
-	</code>	+
-		+
-	== Compilando o manual ==	+
-		+
-	Para compilar, existem algumas opções:	+
-		+
-	= Documentação no formato xHTML =	+
-		+
-	Gera arquivos no formato xHTML, sem imagens, porém funcional:	+
-		+
-	<code>	+
-	$ cd ~/doc-pt_BR/	+
-	$ php doc-base/configure.php --enable-xml-details --with-lang=pt_BR	+
-	$ phd --docbook doc-base/.manual.xml --package PHP --format xhtml --output mydocs_xhtml	+
-	</code>	+
-		+
-	Agora inicie o servidor web do PHP para acessar a documentação pelo navegador:	+
-		+
-	<code>	+
-	$ php -S localhost:8000 -t ./mydocs_xhtml/php-chunked-xhtml	+
-	</code>	+
-		+
-	E acesse a documentação gerada através do endereço http://localhost:8000/	+
-		+
-	Veja esse processo rodando aqui: https://asciinema.org/a/14378	+
-		+
-	= Documentação no formato PHP =	+
-		+
-	Gera arquivos no formato php, que dependem de outros arquivos explicados em http://doc.php.net/tutorial/local-setup.php. Com os comandos abaixo essas dependências já são resolvidas.	+
-		+
-	<code>	+
-	$ cd ~/doc-pt_BR/	+
-	$ php doc-base/configure.php --enable-xml-details --with-lang=pt_BR	+
-	$ phd --docbook doc-base/.manual.xml --package PHP --format php --output mydocsphp_pt_BR	+
-	</code>	+
-		+
-	Depois de executar os passos acima, utilize os comandos abaixo para baixar as dependências que o formato de documentação em php possui:	+
-		+
-	<code>	+
-	$ wget https://github.com/php/web-php/archive/master.zip	+
-	$ unzip master.zip	+
-	$ rm -rf master.zip	+
-	$ rsync -avzC --timeout=600 --delete --delete-after --exclude='distributions/' --exclude='extra/' --exclude='backend/notes/' ./web-php-master/ ./myphpnet/**	+
-	$ rm -rf web-php-master/	+
-	</code>	+
-		+
-	Então mova a pasta da versão da documentação que você criou para dentro da pasta que será usada pelo servidor web:	+
-		+
-	<code>	+
-	$ mv mydocsphp_pt_BR/php-web/ myphpnet/manual/pt_BR	+
-	</code>	+
-		+
-	Agora inicie o servidor web do PHP para acessar a documentação pelo navegador:	+
-		+
-	<code>	+
-	$ php -S localhost:8000 -t ./myphpnet/	+
-	</code>	+
-		+
-	E acesse a documentação gerada através do endereço http://localhost:8000/manual/pt_BR/	+
-		+
-	Veja esse processo rodando aqui: https://asciinema.org/a/14385	+
-		+
-	== Criando um patch com as suas alterações ==	+
-		+
-	Depois de terminar suas alterações de tradução e testá-las, você deve fazer um patch com essas alterações.	+
-		+
-	Para evitar mandar algum patch que mexa na estrutura do original do manual, é sugerido que o patch seja gerado a partir da pasta ''pt_BR''. Depois de navegar para essa pasta, execute o seguinte comando:	+
-		+
-	<code>	+
-	svn diff > minha_traducao.patch	+
-	</code>	+
-		+
-	Pronto. Basta mandar esse patch para a [[doc-pt-br@lists.php.net\|lista]] e alguém irá aplicá-lo caso esteja acordo com o foco da tradução e as regras mencionadas no manual.	+
-		+
-	Não esqueça de mandar uma commit message junto! ex.:	+
-		+
-	<code>Translating the Windows install FAQ [Fulano de Tal <fulano@tal.com>]</code>	+
-		+
-	Quanto mais patches seus forem aprovados, mais fácil para você conseguir uma conta VCS aprovada (SVN, nome@php.net) e agilizar o processo, pois você mesmo vai poder mesclar suas alterações.	+
-		+
-	== Aplicando um patch na documentação ==	+
-		+
-	Para aplicar um patch na sua tradução, utilize um dos comandos abaixo:	+
-		+
-	Se tiver usando o SVN >= 1.7 é só chamar:	+
-		+
-	<code>	+
-	svn patch $file	+
-	</code>	+
-		+
-	Se não tiver o comando svn patch, use o seguinte comando:	+
-		+
-	<code>	+
-	patch -p0 < $file	+
-	</code>	+

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