|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #65532 Recommendation to remove undocumented configuration directives
Submitted: 2013-08-22 22:52 UTC Modified: 2013-10-03 05:50 UTC
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: cevfora at elitemail dot org Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
46 + 22 = ?
Subscribe to this entry?

 [2013-08-22 22:52 UTC] cevfora at elitemail dot org

The page titled "List of php.ini directives" at

includes directives lacking documentation such as 


These directives

A) lack links to documentation, and
B) have no corresponding PHP extensions listed on the page

where the extension name would be implied from the configuration directive name of the form <extension name>.<parameter>  (e.g. pam.servicename implies extension "pam").

Moreover, PECL does not have packages with the names birdstep, ircg, velocis, simple_cvs) according to searches at


A) Remove these directives from the page "List of php.ini directives" and no longer make an effort to document them on

or ...

B) Remove these directives from the page "List of php.ini directives" and move them to a new page (e.g. "Directives Formerly Documented on").

or ...

C) Retain these directives on the page "List of php.ini directives" and provide links to a page that informs the programmer seeking documentation that the corresponding PHP extensions are no longer being documented at


The following are my opinions on these 3 possible solutions.  I recognize that others may have different, and more enlightened insight into the realities of documenting a list of configuration directives that continues to evolve. 

Solution A is cleanest; if a directive is listed, then it is documented.

Solution B could provide a resource for the programmer who asks "What happened to the directive I used 8 years ago that appears to be missing?".  

Solution C inelegantly combines directives currently documented on with directives no longer adequately documented on the site.  Over time the list of directives may grow with the undocumented directives becoming a larger fraction of the total set of listed directives, diluting the value of the list. The programmer would find no clear documentation of why some configuration directive "remnants" are left in the list while many other extensions (as provided in numerous PECL packages) are not documented at all. 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-10-03 05:50 UTC]
-Status: Open +Status: Not a bug
 [2013-10-03 05:50 UTC]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

The INI list is not meant to function as a sitemap, it is meant to provide an exhausting list, it does not necessarily have to link to other manual pages for every option on the page.

I have removed the old extensions from the ini list.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu May 06 03:01:24 2021 UTC