Problem/Motivation
Several methods in WebTestBase accept $path as their argument, such as drupalPost(), drupalGet(), etc.
Most of them (or at least some) appear to accept Url objects as well as strings. For instance, see this call:
+++ b/core/modules/quickedit/src/Tests/QuickEditLoadingTest.php
@@ -106,7 +107,7 @@ public function testUserWithoutPermission() {
+ $response = $this->drupalPostWithFormat(Url::fromRoute('quickedit.metadata'), 'json', $post);
However, the docs for this function don't say that $path can be anything but a string:
+++ b/core/modules/simpletest/src/WebTestBase.php
+ * @param string $path
+ * Drupal path where the request should be POSTed to. Will be transformed
+ * into an absolute path automatically.
...
+ protected function drupalPostWithFormat($path, $format, array $post, $options = []) {
Proposed resolution
Fix all WebTestBase methods that accept $path as a Url as well as string so that their documentation matches this.
Remaining tasks
a) Figure out which methods accept Url objects as $path (probably all of them?).
b) Make a patch to fix the docs. This should end up looking something like:
* @param \Drupal\Core\Url|string $path
* Drupal path or URL to load into the internal browser.
User interface changes
None.
API changes
None.
Beta phase evaluation
Comments
Comment #1
dawehnerComment #2
chananapeeyush commentedComment #3
dawehner@trwad
Did you checked all the methods here, like
drupalPostWithFormatanddrupalGetWithFormat?Comment #4
chananapeeyush commented@dawehner,
As per the documentation specified in drupalPostWithFormat in WebTestBase.php the path should be string not object, same in drupalGetWithFormat but as per the current implementation in QuickEditLoadingTest the
Url::fromRoute('quickedit.metadata')function returns the object.Is the documentation outdated ?
Should we need to look the other usages of the drupalPostWithFormat ?
Comment #5
jhodgdonYes. Please look at all of the functions in WebTestBase that accept a $path parameter. If the function is documented to just accept string but it actually accepts a Url object as well, fix the docs. I'll update the summary to say this explicitly, as it's a bit confusing (to me anyway) as it is now.
Also on the one that was patched here:
These docs were incorrectly changed to say "internal browser" not "AJAX". So just be careful when finding these -- can't just copy/paste the description everywhere, it has to match the method's functionality. [This change was actually copied directly from the issue summary, and I've fixed the summary.]
Thanks!
Comment #6
peacog commentedI've made a patch for this. As well as fixing the documentation of the $path variable, I fixed a few docblocks that had incorrect @return values, or were missing a @throw section. Should I have created a separate issue for those, or maybe changed the issue title?
Comment #7
jhodgdonSo...
Could you please split off all the return value stuff into a separate issue? This issue is only about the $path parameter.
That said, I reviewed the entire patch, and I think it needs a bit of work:
I believe this is either returning a string (the content of the page) or FALSE (if it failed. So instead of "mixed", lets' say
string|false
and document that it returns FALSE if the reqeust fails.
First line docs for functions need to be <= 80 character lines... so this needs to be shorter.
I would suggest leaving the wording as it was, but changing the verbs so they are all ending in s (third person).
Again, needs to be <= 80 characters. I think in this line we can just say URL instead of "Drupal path or absolute path", to stay shorter.
"given format" is not appropriate here, as this is for only Ajax.
json -> JSON
Again, for this function I wouldn't say "given format".
Line needs wrapping
Also ajax => Ajax.
Um. How can it return decoded JSON and an array of Ajax commands? Makes no sense to me.
Also json -> JSON
See above comment about this return value...
So we have some things that are documented to return string, and some mixed. I think probably all of them can return string|false, right? Not sure... but let's document them all the same if so.
HEre's another one.
If TRUE cannot be returned, use
string|false
not
string|bool
string|false
Needs namespace on the class here.
Comment #8
peacog commentedThanks for reviewing. OK, I've split out the $path parameter stuff and rolled a patch for this issue.
I'll open a new issue for the rest of the doc fixes.
Comment #9
peacog commentedComment #10
jhodgdonLooks good! Thanks for keeping this patch to what the issue is actually about.
Comment #11
jhodgdonAPI docs only.
Comment #12
alexpottCommitted aeed399 and pushed to 8.0.x. Thanks!