|  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
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
Have you experienced this issue?
Rate the importance of this bug to you:

 [2008-04-17 15:14 UTC] rrf5000 at psu dot edu
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.


Add a Patch

Pull Requests

Add a Pull Request


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

 [2014-12-31 08:23 UTC]
-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]
Can't we "just" redirect the alias pages to the "real thing"
 [2018-03-17 05:28 UTC]
@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[function] and even ignoring that I believe we should stay explicit about documented features.
 [2018-03-17 12:04 UTC]
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] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Feb 23 01:01:30 2024 UTC