php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #44763 Disable user contributed notes on aliases
Submitted: 2008-04-17 15:14 UTC Modified: 2018-03-17 12:04 UTC
Votes:4
Avg. Score:3.0 ± 1.4
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:2 (50.0%)
From: rrf5000 at psu dot edu Assigned:
Status: Verified Package: Website problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: rrf5000 at psu dot edu
New email:
PHP Version: OS:

 

 [2008-04-17 15:14 UTC] rrf5000 at psu dot edu
Description:
------------
This is a documentation suggestion, not a bug report.

I've noticed more than a few times that users will contribute notes on an alias function's reference page (e.g., Array function sizeof() ) which are already documented on the aliased function's reference page (i.e., Array function count() ).  I think that it would make more sense to keep the sets of notes the same across the page of aliases and their aliased function, or disable notes on alias pages to keep duplicate examples and notes from occurring.  I believe that this will keep things cleaner in the long run, especially for users wanting to peruse the function notes and editors cleaning up the notes.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-20 22:20 UTC] bjori@php.net
Although it is a good idea I don't think our infrastructure can support it...

 [2014-12-31 08:23 UTC] sobak@php.net
-Summary: [FR] Disable user contributed notes on aliases +Summary: Disable user contributed notes on aliases -Type: Bug +Type: Feature/Change Request
 [2018-03-16 23:26 UTC] cmb@php.net
Can't we "just" redirect the alias pages to the "real thing"
instead?
 [2018-03-17 05:28 UTC] sobak@php.net
@cmb I agree that would simplify implementing the requested behavior but at the same time I think it would end up terribly unclear to the manual users. We already have a bunch URL redirects (e.g. for the legacy pages) and I'd myself never think that redirect may indicate an alias.

We need to remember that clicking link on the menu is not the only way people browse the manual. I often simply go with php.net/[function] and even ignoring that I believe we should stay explicit about documented features.
 [2018-03-17 12:04 UTC] cmb@php.net
The reason I posted this comment was that I stumbled upon user
note 117236[1] which suggest to add a see also link to
date_create_from_format.  My first thought was, yes of course, but
actually, DateTime::__construct() already links to
DateTime::createFromFormat(), and both methods already document
their procedural counterparts.

I have not thought about aliases like chop(), which are not even
mentioned in the docs they're aliasing (rtrim() in this case).
This could, however, be changed, e.g. by adding a second
methodsynopsis to rtrim.xml which shows chop().  Then a redirect
from function.chop.php to function.rtrim.php appears to be fine.

[1] <http://www.php.net/manual/en/function.date-create.php#117236>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Dec 04 18:01:31 2024 UTC