processwire
Docs typos
Hopefully we can all make use of this issue to add typos as we find them rather than creating new issues for each one.
-
https://processwire.com/api/ref/fieldgroup/has-field/ Does this fieldgroup have~~ing~~ the given field?
-
https://processwire.com/api/ref/config/version/ Check if current ProcessWire version is equal to or newer than given versi**~~n~~on**
Not a typo exactly but the Template::hasField() method has no arguments description: https://processwire.com/api/ref/template/has-field/
Pageimage.php, line 50: file -> File Pageimage.php, line 1656: please add @since 3.0.126 for render() method Pageimages.php, line 225: please add @since 3.0.126 for render() method Pageimage.php, line 1657: and or -> and/or Sanitizer.php, line 24: intances -> instances Sanitizer.php, line 75: example -> example, Sanitizer.php, line 86: ta -> a
In ProcessPageList.module(/wire/modules/Process/ProcessPageList/ProcessPageList.module): hierarchal should be hierarchical
- line: 6
- line: 41
In ProcessPageList.module(/wire/modules/Process/ProcessPageList/ProcessPageList.module): classs should be class line: 327
double negative on this page: https://processwire.com/api/ref/sanitizer/
Sanitize input string as multi-line text without no HTML tags
Typo in $database API example: https://processwire.com/api/ref/wire-database-backup/
The very first example, instead of
$database->backup();
looks like should be:
$database->backups();
Source: https://processwire.com/talk/topic/20967-not-sure-where-to-report-code-sample-typos-in-the-api-docs/
module.php: "You may implement also implement this method as hookable, ..." double implement
wire\modules\AdminTheme\AdminThemeUikit\config.php
"Chose option B if you are having any trouble achieving intended Inputfield column widths."
Change Chose to Choose.
wire\core\WireArray.php
"Property or properties to retrieve, or callable function that shuld receive items."
shuld -> should
wire/core/Wire.php
Line 1618: $this->wire('widgets', $widgets');
should be: $this->wire('widgets', $widgets);
A double semicolon in line 289 in ProcessPageAdd.module: $parentTemplates = new TemplatesArray();;
In case you didn't see: typo in Pageimage.php line 1558 https://github.com/processwire/processwire/pull/139/commits/a434b1be0089fa4787cb62caeb2d27c1f3bb3dff
ProcessModule.module here and here
"This URL may be be accessed directly" should be "This URL may not be accessed directly".
Not a typo, but there appears to be no links to this important documentation page: https://processwire.com/api/ref/paths/ The URL structure implies that it should be linked to from https://processwire.com/api/ref/ Are there other similar pages under https://processwire.com/api/ref/ that are not linked to from the parent page but should be?
Another unlinked section of the API docs: https://processwire.com/api/ref/pages-names/
@Toutouwai These are dynamically generated doc pages from the ProcessWireAPI module that go out and look for the class and then generate a doc page for it on the fly. The list you see a /api/ref/ is just a small curated list that I've picked out as being the most useful/important parts of the public API, which is probably only about 1/10th of the total number of classes you could generate documentation for from this endpoint/module. Other classes are linked where relevant as argument or return values. If you think the ones you mentioned need more exposure, I can always include them in the curated list index, but I also want to be careful about having too much info up front.
I personally would add https://processwire.com/api/ref/paths/ since it's common to use in templates, even (or especially) for beginners. https://processwire.com/api/ref/pages-names/ is from my point of view more developer oriented.
@matjazpotocnik @Toutouwai I think you guys are right about Paths — I've added the Paths class to the main index (and also as $urls API var). for PagesNames, I've not added it to the main index but it does seem like it's got potential usefulness in the public API (even if occasional), so have made the $pages->names() method part of the public API so that the class can be navigated to (as the return value for that method) or it can be found from the search.
Again, not really a typo, but I think that $mail needs references to all the methods that are available to WireMail. If you look at the docs to $mail you don't see anything like toName(), fromName(), etc.
I think newbies won't know to also check the WireMail() docs. I think it's also really important to explain why $m = new WireMail(); is a bad idea unless you know what you are doing - ie it breaks modules that extend WireMail.
The list you see a /api/ref/ is just a small curated list that I've picked out as being the most useful/important parts of the public API, which is probably only about 1/10th of the total number of classes you could generate documentation for from this endpoint/module.
Personally I'm in favour of listing all documentation pages that exist. To avoid clutter and give the most important pages priority the other currently unlisted pages could be contained in a collapsed Other/Advanced/Kitchen Sink section (whatever naming you think best).
Besides the fact that I myself would refer to these pages I think it adds credibility to the PW project to have full and comprehensive documentation on display.
In PageimageVariations.php in count(): @param array $options See options for find() emthod
In Module.php, I think "called" should be "cannot":
If the install() method determines that the module called be installed for some reason, it should throw a `WireException.`
In ProCache 4: "When in cahce debug mode" (the word 'cache' is misspelled).