I've found this great utility class today. When using the dummy image generation function, I've found that the function parameters are documented wrong. As per phpDoc the type of $min_resolution and $max_resolution should be integers. The truth is however, that both parameters should be a string in the format '[width]x[height]'.

I'll provide a patch fixing the type and adding an appropriate description.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

agoradesign created an issue. See original summary.

agoradesign’s picture

Status: Active » Needs review
FileSize
921 bytes
agoradesign’s picture

Component: documentation » base system
mondrake’s picture

Component: base system » documentation
Status: Needs review » Reviewed & tested by the community

Looks good. Patch is doc change only.

xjm’s picture

Title: \Drupal\Component\Utility\Random::image() has wrong parameter documentation » Add missing parameter documentation to \Drupal\Component\Utility\Random::image()
Status: Reviewed & tested by the community » Needs work

Good spot on the missing parameter documentation.

+++ b/core/lib/Drupal/Component/Utility/Random.php
@@ -262,8 +262,12 @@ public function paragraphs($paragraph_count = 12) {
+   *   The minimal image resolution, formatted as '[width]x[height]', e.g.
+   *   '640x480', if you want a min resolution of 640px width and 480px height.
...
+   *   The maximal image resolution, formatted as '[width]x[height]', e.g.
+   *   '640x480', if you want a max resolution of 640px width and 480px height.

It should say "minimum" and "maximum" (which have slightly different meanings than "minimal" and "maximal"). We should use the full word instead of "min" and "max" later in the description as well.

The sentences are also kind of a run-on. We should split it into two sentences.

Finally, is there an existing description of data in this width x height format elsewhere in core that we should make it consistent with? The square brackets can confuse users since we are using them to denote "replace '[width]' with the number" but that is not actually clear or consistent. In general we should avoid such pseudo-delimiters because users can think they are part of the actual string format.

Actually this also calls into question why we do not allow passing separate min_width, min_height, max_width, and max_height parameters rather than this weird special string format. :) But that is out of scope for this issue, so would need to be discussed in a followup if anything.

Also, thinking about the scope of this issue in terms of: https://www.drupal.org/core/scope#coding-standards

This issue is adding missing parameter documentation. While missing parameter documentation is itself a coding standards error, adding that documentation needs to be done by writing it, which means understanding the concepts involved. So the current scope of this patch, limited to one concept, also makes sense.

However, we should make sure we're adding all the missing parameter documentation for this specific concept. Can we check whether there is any other missing documentation in the Random component? Writing that documentation together would work best.

Thanks @agoradesign!

himanshu-dixit’s picture

Status: Needs work » Needs review
FileSize
889 bytes
1.11 KB

@xjm Here is the new patch.

is there an existing description of data in this width x height format elsewhere in core that we should make it consistent with?

I found file which have existing description of data in this width x height format. The file is file.module :) .

 * @param string|int $maximum_dimensions
 *   (optional) A string in the form WIDTHxHEIGHT; for example, '640x480' or
 *   '85x85'. If an image toolkit is installed, the image will be resized down
 *   to these dimensions. A value of zero (the default) indicates no restriction
 *   on size, so no resizing will be attempted.
agoradesign’s picture

The quick reactions to this tiny issue are awesome :) thx @xjm, @himanshu-dixit

I agree, that we should think of that parameters in general, as there are way better solutions. We could introduce value objects or at least use arrays with "width" and "height" parameters directly, as these are normally the way we work with image dimensions in Drupal afaik. E.g. there's ImageStyle::transformDimensions, where such an array is used.

@xjm: I've one interesting question left about issues like this one. As you can see in the issue's revision, I was rather unsure, which component to choose for this issue. On the one hand it's kinda documentation related, as phpdoc comments are part of the API documentation. But there are also valid arguments to choose the subsystems. I've changed it from "documentation" to "base system", after berdir answered to my question on IRC and gave me this advice

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

tanubansal’s picture

Tested via #6.
It's showing the added text. This can be moved to RTBC

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

quietone’s picture

Category: Bug report » Task
Status: Needs review » Closed (duplicate)
Issue tags: +Bug Smash Initiative
Related issues: +#3076644: Mistake in the comment documenting the "image" method of the "Random" utility class.

A description for these parameters was added in #3076644: Mistake in the comment documenting the "image" method of the "Random" utility class.. The text is different than what is in the patch, but the meaning is the same. Closing as a duplicate.