In the documentation, change all instances of "url" to "URL".

Thanks for the patch! Most of it looks fine. A few things to fix:

1. +++ b/core/assets/vendor/backbone/backbone.js
   +++ b/core/assets/vendor/jquery/jquery.js
   +++ b/vendor/zendframework/zend-feed/src/Reader/Extension/Podcast/Feed.php
   

   We should not be modifying anything in /core/assets/vendor or /vendor in this patch.

2. +++ b/core/includes/menu.inc
   @@ -22,7 +22,7 @@
   + *     - #link: A menu link array with 'title', 'URL', and (optionally)
   

   This should not be changed. This is describing elements of a $variables array and the array key is 'url' here, not 'URL'.

3. +++ b/core/includes/menu.inc
   @@ -59,7 +59,7 @@ function template_preprocess_menu_local_task(&$variables) {
   + *     - #link: A menu link array with 'title', 'URL', and (optionally)
   

   This should not be changed. This is describing elements of a $variables array and the array key is 'url' here.

4. +++ b/core/lib/Drupal/Core/Menu/menu.api.php
   @@ -241,7 +241,7 @@
   + *     Either the route_name or URL element must be provided.
   

   This should not be changed. This is describing an array element whose key is actually 'url'.

5. +++ b/core/lib/Drupal/Core/Template/TwigExtension.php
   @@ -129,7 +129,7 @@ public function getFunctions() {
   -      // The url and path function are defined in close parallel to those found
   +      // The URL and path function are defined in close parallel to those found
          // in \Symfony\Bridge\Twig\Extension\RoutingExtension
          new \Twig_SimpleFunction('url', array($this, 'getUrl'), array('is_safe_callback' => array($this, 'isUrlGenerationSafe'))),
          new \Twig_SimpleFunction('path', array($this, 'getPath'), array('is_safe_callback' => array($this, 'isUrlGenerationSafe'))),
   

   This is describing Twig functions, whose names are url and path, so don't change the caps here.

6. +++ b/core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php
   @@ -183,7 +183,7 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
   -    // 'url' form element and we have to do the validation ourselves.
   +    // 'URL' form element and we have to do the validation ourselves.
   

   This is referring to an array element name, no change.

7. +++ b/core/modules/system/src/Tests/Theme/EngineTwigTest.php
   @@ -43,7 +43,7 @@ function testTwigVariableDataTypes() {
   +   * Tests the URL and url_generate Twig functions.
   

   This is referring to the name of a Twig function called "url", so should not be changed.

8. +++ b/core/modules/views/js/base.js
   @@ -92,7 +92,7 @@
   +    // 3 is the length of the '?q=' added to the URL without clean urls.
   

   at the end of this sentence, "urls" should be changed to "URLs".

9. +++ b/vendor/zendframework/zend-feed/src/Reader/Extension/Podcast/Feed.php
   @@ -173,7 +173,7 @@ public function getKeywords()
   +    public function getNewFeedUrl()z
   

   This is most likely the cause of the test failures? Stray "z" at the end of the line.

@ jhodgdon

I have updated your comments on the patch. please review it.

@ jhodgdon

I have updated patch with your comments. please review it.

Thanks! Everything in the patch looks good now.

Also as a note, this patch doesn't apply to Drupal 8.0.x, so tagging for backport after we get 8.1.x. in.

However, I do not think this patch is fixing all instances of "url". After applying the patch, I found the following:

core/modules/comment/src/Tests/CommentNonNodeTest.php:    // @todo Check proper url and form https://www.drupal.org/node/2458323
core/modules/simpletest/src/WebTestBase.php:    // Make sure the url generator has a request object, otherwise calls to
core/modules/rdf/src/Tests/Field/LinkFieldRdfaTest.php:    // Test the link formatter: trim at 20, url only (as plaintext.)
core/modules/rdf/src/Tests/Field/LinkFieldRdfaTest.php:    // Test the link formatter: do not trim, url only (as plaintext.)
core/modules/contact/src/Tests/ContactSitewideTest.php:    // Cannot use ::assertNoLinkByHref as it does partial url matching and with

At this point, I stopped looking for more, but there probably are more.

The scope is still big IMO. The patch is making changes in many files, difficult to apply the patch after nearly an hour or two. @Jennifer should we reduce the scope by refining it more?

If you want to reduce the size of the patch, ... I don't think the scope can be reduced in any way that makes sense, but the way to reduce the size of the patch is to make "sections" like core/lib vs. core/modules or something like that. See
https://www.drupal.org/core/scope
for guidelines on how to properly scope issues.

So, if you want to reduce the patch size, make this a Meta issue and split it into a few parts that are clearly defined as to which files in Core they cover.

Thanks for the rescoping. I've reviewed the child issues with patches and will follow the other.

I don't think we need that one issue to be both related and a child though. ;)

For anyone following this, you may be interested in this kind-of related issue.

Oh, I guess we need a few more child issues, right? core/includes, core/themes, core/profiles, core/misc are not covered by these issues yet. We should not touch core/assets, and I looked and core/scripts is fine.

We need to be careful about core/misc, which is all our core Drupal-project-owned JS files. Just be careful there because local parameters can legally be called "url" and they don't start with $ so you may have lines like

@param {string} url

and you don't want to change those.

Apparently (see the other related issues), @catch wants all of these combined into one patch. See #2679417: In the documentation, change all instances of "url" to "URL". Under '/core/modules/' folder M to Z for example of his comment. Probably this issue needs to be not a meta any more, and @catch wants one patch for the whole thing.

I am sorry for leading you down the path of multiple patches. Apparently I do not properly understand the Scope document. Good luck.... I will stay out of it. :(

Also crediting malavya who worked on some of the child issues.

This seems like a good issue scope to me. Thanks @catch and @jhodgdon!

Oh, following up, @jhodgdon, I think splitting up into grouping by file is only necessary when a patch is completely unmanageable with the minimum logical scope. For a word diff, the actual diff is much smaller than the line diff in the patch, and the reviewer just needs to scan the same change, so a much larger patch size is manageable. I think this is the key bit of the scope doc:

As a rule of thumb, patches of between 10-40K are a good size, but this varies with the type of fix. Large patches with many instances of the same simple change can still be easy to create and review, while even small patches with complex new code or documentation can take longer. Good conceptual scope is more important than the size alone.

https://www.drupal.org/core/scope#size

And more generally:

Very large patches are extremely difficult to create and review. For this reason, it can seem like a good idea to create a series of patches like "Fix coding standards errors in module A", "Fix coding standards errors in module B", etc. However, this can turn out to be the worst of both worlds: the patch mixes multiple different concepts and contexts, while also leaving the codebase in an incomplete state.

https://www.drupal.org/core/scope#files

Apologies since my discussion of scope is not actually in scope for the issue. ;) Just wanted to explain why I thought this was a good scope.

Well I disagreed, and the people making this patch (see above) were having trouble with needing to reroll it too much. Splitting it up made it way easier to get right, too (there were numerous changes that didn't belong in the patch, it's not "replace everywhere with URL", see reviews on the sub-issues).

But whatever. I'm stepping back from it. Someone else can review the huge patches. I'm not.

Also, in terms of the patch not applying quickly, it will probably need rerolls occasionally as it is developed:
https://www.drupal.org/contributor-tasks/reroll
When the patch applies, you don't have to throw the whole thing out -- you can just resolve the conflicts using that rebase strategy.

Attached rerolls the earlier patch on the issue. I did this as follows:

[mandelbrot:drupal | Thu 11:15:05] $ git log --before=2016-02-29
commit cce99d5ac534acd174a2f157e59b39afe31c7bcf
Author: Nathaniel Catchpole <catch@35733.no-reply.drupal.org>
Date:   Mon Feb 29 21:06:15 2016 +0900

    Issue #2559695 by leolando.tan, bhavikshah9, falufalump, nod_, eiriksm: JSDoc tabledrag.js
[mandelbrot:drupal | Thu 11:09:25] $ git checkout -b url cce99d5ac534a
[mandelbrot:drupal | Thu 11:09:32] $ git apply --index - | curl https://www.drupal.org/files/issues/2676182-7.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 73546  100 73546    0     0  74291      0 --:--:-- --:--:-- --:--:--  142k
[mandelbrot:drupal | Thu 11:09:40] $ git commit -m orig
[url 27fb4a3] orig
 81 files changed, 145 insertions(+), 145 deletions(-)
[mandelbrot:drupal | Thu 11:10:05] $ git rebase 8.1.x
First, rewinding head to replay your work on top of it...
Applying: orig
Using index info to reconstruct a base tree...
M	core/modules/path/src/Tests/Migrate/d6/MigrateUrlAliasTest.php
Falling back to patching base and 3-way merge...
Auto-merging core/modules/path/src/Tests/Migrate/d6/MigrateUrlAliasTest.php

There were no merge conflicts to resolve with this; git took care of it automatically.

So it just needs to be updated for @jhodgdon's earlier reviews.

NW to address #9. Also probably anything from @jhodgon's other reviews on other issues. Thanks everyone for working on this!

Rerolled #28 to apply on 8.2.x.

Patch #32 slightly rerolled because files have changed with this other patch :
Issue #2553655 by dawehner, Berdir, martin107: Convert ViewKernelTestBase to use KernelTestBaseTNG.

Thanks @pguillard for the reroll.

(Removing inapplicable tag.)

Rerolled #34.

+++ b/core/modules/quickedit/js/util.js
@@ -24,7 +24,7 @@
diff --git a/core/modules/simpletest/src/BrowserTestBase.php b/core/modules/simpletest/src/BrowserTestBase.php

diff --git a/core/modules/simpletest/src/BrowserTestBase.php b/core/modules/simpletest/src/BrowserTestBase.php
index dc933ac..b67cb83 100644

index dc933ac..b67cb83 100644
--- a/core/modules/simpletest/src/BrowserTestBase.php

--- a/core/modules/simpletest/src/BrowserTestBase.php
+++ b/core/modules/simpletest/src/BrowserTestBase.php

+++ b/core/modules/simpletest/src/BrowserTestBase.php
+++ b/core/modules/simpletest/src/BrowserTestBase.php
@@ -473,7 +473,7 @@ protected function prepareRequest() {

@@ -473,7 +473,7 @@ protected function prepareRequest() {
    * @param string $path
    *   Drupal path or URL to load into Mink controlled browser.
    * @param array $options
-   *   (optional) Options to be forwarded to the url generator.
+   *   (optional) Options to be forwarded to the URL generator.
    *
    * @return string
    *   The retrieved HTML string, also available as $this->getRawContent()
@@ -1209,7 +1209,7 @@ protected function rebuildContainer() {

@@ -1209,7 +1209,7 @@ protected function rebuildContainer() {
     // Rebuild the kernel and bring it back to a fully bootstrapped state.
     $this->container = $this->kernel->rebuildContainer();
 
-    // Make sure the url generator has a request object, otherwise calls to
+    // Make sure the URL generator has a request object, otherwise calls to
     // $this->drupalGet() will fail.
     $this->prepareRequestForGenerator();
   }
@@ -1219,12 +1219,12 @@ protected function rebuildContainer() {

@@ -1219,12 +1219,12 @@ protected function rebuildContainer() {
    *
    * This is used to manipulate how the generator generates paths during tests.
    * It also ensures that calls to $this->drupalGet() will work when running
-   * from run-tests.sh because the url generator no longer looks at the global
+   * from run-tests.sh because the URL generator no longer looks at the global
    * variables that are set there but relies on getting this information from a
    * request object.
    *
    * @param bool $clean_urls
-   *   Whether to mock the request using clean urls.
+   *   Whether to mock the request using clean URLs.
    * @param array $override_server_vars
    *   An array of server variables to override.
    *

In my opinion this instances of "url" should be fixed in the parent class.
So I will upload these changes in other patch.

Apply changes mentioned above on #38.

Rerolled #39.
Some changes in core/includes/theme.inc has been caused this reroll.
See #2710685: inconsistent use of tags in docs for template_preprocess_links()

Attached a new interdiff.
The changes that we see in this interdiff are the changes that are already committed on #2710685: inconsistent use of tags in docs for template_preprocess_links().
(Sorry for so many comments)

The latest patch did not apply.
Rerolled #41.

Lots of attention to detail here, and I've reviewed all lines to agree that this looks good.

Simple rebase fixed it.
RTBC maybe?

I was able the patch. So changing status to need's review.

Thanks!!

Rerolled #52.

test pass and looks good to me :)

accidentally attached a patch file.. so removing it.

I do not understand what happened in these last two comments ...
I upload the patch indicated in #57.

After 2 weeks, more work is needed on this task?
RTBC maybe?

Patch in #62 applies successfully against 8.2.x but it seems there's a bit more work before it's ready. Here's what I could spot:

1. +++ b/core/modules/views/js/base.js
   @@ -92,7 +92,7 @@
   +    // 3 is the length of the '?q=' added to the url without clean URLs.
   

   Another 'url' spotted.

2. +++ b/core/modules/views_ui/src/ViewEditForm.php
   @@ -289,7 +289,7 @@ public function save(array $form, FormStateInterface $form_state) {
   +      // Find out the first display which has a changed path and redirect to this URL.
   

   This line should be wrapped at 80 cols.

Addressed this in the attached patch. Also tried to address #9 and correct a few cURL strings that I suspect might have been replaced as part of a bulk search/replace.

Oh, I do see some strings have been reverted in the interdiff but those are NOT in my 8.2.x checkout nor in the above patch - Was #62 generated against 8.1.x, maybe?

Patch on #62 was generated against 8.2.x.
However I upload another patch. (It appears to be identical to patch indicated on #62)
I upload an interdiff that the only thing amending are the points 1 and 2 explained on #64.

re: #66 - If you want to ignore non-URL-related changes in #64, please at least incorporate the points raised in #9

@anavarre Thanks for your review.
I upload a new patch to incorporate the points raised in #9.
I also searched other matches and tried to solve them (See interdiff).

On the other hand, I have doubts when I found the following string:
"url object".

What would be more correct? "Url object" or "URL object" (Although the scope of this issue is only to change "url" by "URL")

+++ b/core/modules/filter/filter.module
@@ -497,7 +497,7 @@ function _filter_url($text, $filter) {
+  //and allow @ in a URL, but only in the middle. Catch things like http://example.com/@user/

Should be wrapped at 80 cols.

On the other hand, I have doubts when I found the following string: "url object".

I think this might have to stay as is since it's a reference to an actual object, not the URL acronym. But I'd defer to Jennifer for the correct path to follow here.

Also, found a few more it seems:

core/lib/Drupal/Core/Entity/Controller/EntityController.php:78:   *   The url generator.
core/tests/Drupal/Tests/BrowserTestBase.php:990:   *   Options to be forwarded to the url generator.
core/tests/Drupal/Tests/Core/Utility/LinkGeneratorTest.php:208:   * Tests the generate() method with a url containing double quotes.
core/tests/Drupal/Tests/Core/UrlTest.php:367:      // Clone the url so that there is no leak of internal state into the
core/tests/Drupal/Tests/Core/Routing/UrlGeneratorTest.php:439:   * Test that the 'scheme' route requirement is respected during url generation.
core/modules/simpletest/src/WebTestBase.php:1957:   *   (optional) Options to be forwarded to the url generator. The 'absolute'
core/modules/simpletest/src/WebTestBase.php:1990:   *   (optional) Options to be forwarded to the url generator. The 'absolute'

What about the many 'url' strings in core/modules/filter/tests/filter.url-output.txt and core/modules/filter/tests/filter.url-input.txt ?

Took a stab at incorporating the above changes and other url strings I found. Also went ahead and changed the url object string as well for now since I also changed the url generator strings.

Also noticed the interdiff says I've changed uppercase to lowercase but I don't get why since the patch does not actually do that. In any case, more progress on this issue, hopefully.

+++ b/core/tests/Drupal/Tests/Core/Routing/UrlGeneratorTest.php
@@ -436,7 +436,7 @@ public function testBaseURLGeneration() {
+   * Test that the 'scheme' route requirement is respected during URL generation.

Line exceeding 80 characters

I am not sure weather this should be handled in this issue

Reroll against 8.4.x
Hope it works!

+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -2108,7 +2108,61 @@ protected function assertResponse($code, $message = '', $group = 'Browser') {
+    return $this->assertFalse($match, $message ? $message : SafeMarkup::format('HTTP response not expected @code, actual @curl_code', array('@code' => $code, '@curl_code' => $curl_code)), $group);
...
+  protected function prepareRequestForGenerator($clean_urls = TRUE, $override_server_vars = array()) {
...
+    $request = Request::create($request_path, 'GET', array(), array(), array(), $server);

+++ b/core/tests/Drupal/Tests/BrowserTestBase.php
@@ -1080,6 +1080,163 @@ protected function prepareEnvironment() {
+  protected function prepareRequestForGenerator($clean_urls = TRUE, $override_server_vars = array()) {
...
+    $request = Request::create($request_path, 'GET', array(), array(), array(), $server);

use short array syntax (new coding standard).

Fixed the short array syntax error and attached new patch.

I'm not sure if we should change to the short array syntax, probably is out of scope?
I think that we have to fix all errors at #77.

#77 and #78 have two extraneous functions that are not in scope for this issue, and broke the testbot so bad that it flushed out the queue.

You'll need to reroll #70 again. plz do not use 77 / 78 as a base.

+++ b/core/lib/Drupal/Core/Routing/UrlGenerator.php
@@ -238,8 +238,7 @@ protected function doGenerate(array $variables, array $defaults, array $tokens,
-   *   The URL path corresponding to the route, without the base path, not URL
-   *   encoded.
+   *   The url path corresponding to the route, without the base path.

this change is wrong, converts URL to lower case. Why?

Applied @klausi remark, a few that wre missing, and reverted one that was not a comment.

@pguillard Probably we should make the reroll again based on #70 as @Mixologic said above on #82 because my latest patch could been have a mistake, secondly we have to check that all ocurrences works fine.

Re rolled #70 according to #87.
Not find all the changes.
Did some extra changes too.

#88 fails and needs to be re-rolled against 8.6.x.

Taking this issue.

Re-rolled the patch against 8.6.x branch.

Yogesh Pawar your patch failed to apply

Patch rerolled

Re-rolled for 8.9.

Patch in #100 failed to apply.

Rerolled patch as #107 failed to apply.
Some unrelated test is failing.

Hi,

Fixing the test case error. Please have a look at this patch.

Usually, when there is a change in twig file, the generated hash key gets updated. So we need to update the hash key in the file. Updated the hash key again.

Since in previous patches, we have changed that in few themes also. I have noticed now that the URL is not changed in these files.

1) core/themes/claro/templates/classy/navigation
2) core/themes/bartik/templates/classy/navigation/menu.html.twig
3) core/themes/stable9/templates/navigation/menu.html.twig
4)core/themes/stable9/templates/navigation/menu--toolbar.html.twig
5) core/profiles/demo_umami/

Changed in all files, updated the patch.

+++ b/vendor/zendframework/zend-feed/src/Reader/Extension/Podcast/Feed.php
@@ -173,7 +173,7 @@ public function getKeywords()
+    public function getNewFeedUrl()z

Unexpected z

Would be great to work out a script to check if all are fixed or is there more to do.

Added a reroll of patch #118.

Was able to see change in documentation for url to URL

did the git grep for changes after applying patch, some example output is here

modules/media/src/OEmbed/Resource.php:   *   (optional) A URL for the author/owner of the resource.
modules/media/src/OEmbed/Resource.php:   *   (optional) A URL to a thumbnail image representing the resource. If this
modules/media/src/OEmbed/Resource.php:   *   (optional) A URL for the author/owner of the resource.
modules/media/src/OEmbed/Resource.php:   *   (optional) A URL to a thumbnail image representing the resource. If this
modules/media/src/OEmbed/Resource.php:   * Returns the URL of the resource author.
modules/media/src/OEmbed/Resource.php:   *   The absolute URL of the resource author, or NULL if none is provided.
modules/media/src/OEmbed/Resource.php:   * Returns the URL of the resource's thumbnail image.
modules/media/src/OEmbed/Resource.php:   *   The absolute URL of the thumbnail image, or NULL if there isn't one.
modules/media/src/OEmbed/Resource.php:   * Returns the URL of the resource. Only applies to 'photo' resources.
modules/media/src/OEmbed/Resource.php:   *   The resource URL, if it has one.
modules/media/src/OEmbed/ResourceFetcher.php:   *   The URL of the resource.
modules/media/src/OEmbed/ResourceFetcher.php:   *   The resource URL.
modules/media/src/OEmbed/UrlResolver.php: * Converts oEmbed media URLs into endpoint-specific resource URLs.
modules/media/src/OEmbed/UrlResolver.php:   * Static cache of discovered oEmbed resource URLs, keyed by canonical URL.
modules/media/src/OEmbed/UrlResolver.php:   * A discovered resource URL is the actual endpoint URL for a specific media
modules/media/src/OEmbed/UrlResolver.php:   * object, fetched from its canonical URL.
modules/media/src/OEmbed/UrlResolver.php:   * Runs oEmbed discovery and returns the endpoint URL if successful.
modules/media/src/OEmbed/UrlResolver.php:   *   The resource's URL.
modules/media/src/OEmbed/UrlResolver.php:   *   URL of the oEmbed endpoint, or FALSE if the discovery was unsuccessful.
modules/media/src/OEmbed/UrlResolver.php:   * Tries to find the oEmbed URL in a DOM.
modules/media/src/OEmbed/UrlResolver.php:   *   A URL to an oEmbed resource or FALSE if not found.
modules/media/src/OEmbed/UrlResolver.php:    // Check the URL against every scheme of every endpoint of every provider
modules/media/src/OEmbed/UrlResolver.php:    // Try to get the resource URL from the static cache.
modules/media/src/OEmbed/UrlResolver.php:    // Try to get the resource URL from the persistent cache.
modules/media/src/OEmbed/UrlResolver.php:    // Let other modules alter the resource URL, because some oEmbed providers
modules/media/src/Form/MediaSettingsForm.php:   * The iFrame URL helper service.
modules/media/src/Form/MediaSettingsForm.php:   *   The iFrame URL helper service.
modules/media/src/Form/MediaSettingsForm.php:      '#title' => $this->t('Standalone media URL'),
modules/media/src/MediaSourceInterface.php: *   URL or other identifier, while sources that represent local files might
modules/media/src/Plugin/Derivative/DynamicLocalTasks.php:    // Provide an edit_form task if standalone media URLs are enabled.
modules/media/src/Plugin/Field/FieldWidget/OEmbedWidget.php: *   label = @Translation("oEmbed URL"),
modules/media/src/Plugin/Field/FieldFormatter/MediaThumbnailFormatter.php:   * Get the URL for the media thumbnail.
modules/media/src/Plugin/Field/FieldFormatter/MediaThumbnailFormatter.php:   *   The URL object for the media item or null if we don't want to add
modules/media/src/Plugin/Field/FieldFormatter/OEmbedFormatter.php:   * The oEmbed URL resolver service.
modules/media/src/Plugin/Field/FieldFormatter/OEmbedFormatter.php:   * The iFrame URL helper service.
modules/media/src/Plugin/Field/FieldFormatter/OEmbedFormatter.php:   *   The oEmbed URL resolver service.
modules/media/src/Plugin/Field/FieldFormatter/OEmbedFormatter.php:   *   The iFrame URL helper service.
modules/media/src/Plugin/Field/FieldFormatter/OEmbedFormatter.php:        $this->logger->error("Could not retrieve the remote URL (@url).", ['@url' => $value]);
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraint.php: * Checks if a value represents a valid oEmbed resource URL.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraint.php:   * The error message if the URL does not match any known provider.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraint.php:  public $unknownProviderMessage = 'The given URL does not match any known oEmbed providers.';
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraint.php:   * The error message if the URL matches a disallowed provider.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraint.php:   * The error message if the URL is not a valid oEmbed resource.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraint.php:  public $invalidResourceMessage = 'The provided URL does not represent a valid oEmbed resource.';
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraintValidator.php: * Validates oEmbed resource URLs.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraintValidator.php:   * The oEmbed URL resolver service.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraintValidator.php:   *   The oEmbed URL resolver service.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraintValidator.php:    // The URL may be NULL if the source field is empty, which is invalid input.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraintValidator.php:    // Ensure that the URL matches a provider.
modules/media/src/Plugin/Validation/Constraint/OEmbedResourceConstraintValidator.php:    // Verify that resource fetching works, because some URLs might match
modules/media/src/Plugin/media/Source/OEmbedDeriver.php:        'description' => t('Use remote video URL for reusable media.'),
modules/media/src/Plugin/media/Source/OEmbed.php: *   description = @Translation("Use oEmbed URL for reusable media."),
modules/media/src/Plugin/media/Source/OEmbed.php:   * The iFrame URL helper service.
modules/media/src/Plugin/media/Source/OEmbed.php:   *   The oEmbed URL resolver service.
modules/media/src/Plugin/media/Source/OEmbed.php:   *   The iFrame URL helper service.
modules/media/src/Plugin/media/Source/OEmbed.php:      'author_url' => $this->t('The URL of the author/owner'),
modules/media/src/Plugin/media/Source/OEmbed.php:      'provider_url' => $this->t('The URL of the provider'),
modules/media/src/Plugin/media/Source/OEmbed.php:      'url' => $this->t('The source URL of the resource'),
modules/media/src/Plugin/media/Source/OEmbed.php:    // The URL may be NULL if the source field is empty, in which case just
modules/media/src/Plugin/media/Source/OEmbed.php:    $label = (string) $this->t('@type URL', [
modules/media/src/Controller/OEmbedIframeController.php:   * The oEmbed URL resolver service.
modules/media/src/Controller/OEmbedIframeController.php:   * The iFrame URL helper service.
modules/media/src/Controller/OEmbedIframeController.php:   *   The oEmbed URL resolver service.
modules/media/src/Controller/OEmbedIframeController.php:   *   The iFrame URL helper service.
modules/media/src/Controller/OEmbedIframeController.php:    // Hash the URL and max dimensions, and ensure it is equal to the hash
modules/media/src/MediaForm.php:    // overview' permission. If not, redirect to the canonical URL of the media 

This can be moved to RTBC if code review is fine

No longer applies

Actually no. The patch here is very much the same as in the parent issue. This looks like it is a duplicate of the parent.

On another read, the issue summary says this is for files in core/modules but it is covering all of core. But more importantly there are questions to resolve in the parent. Postponing on the parent, specifically until there is resolution on the points in 2574981#125.

Also not a bug, this is a task.

This was discussed at a documentation triage meeting. I have updated the IS with the standard template and added what this is postponed on.

Reviewing this again. This was created after #2574981: Fix grammar ("an URL" should be "a URL") and consistent use of URL (not "url" / "Url") in documentation only, part 1 which is doing the same work and is now fixed. That makes this a duplicate. I am closing this and transferring credit.