Don't hardcode the description in PathWidget

Initial patch. Let's push media initiative by patch a day.
// Naveen

Looks good to me.

To me personally this doesn't seem worth writing a test for. It would require adding two new test entity types, and the new trend seems to be not to add them to entity_test directly, but in fact add a whole new test module just for that. So it seems like a whole lof of work for not that much benefit.

Of course this is not up to me in the end, but setting RTBC due to the above.

+++ b/core/modules/path/src/Plugin/Field/FieldWidget/PathWidget.php
@@ -44,6 +44,8 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
+    $alias_description = $this->fieldDefinition->getDescription();
+    $alias_description = $alias_description ?: $this->t('Specify an alternative path by which this data can be accessed. For example, type "/about" when writing an about page.');

Given that we are adding logic I'm not sure that not having a test is a good thing. If we don't have a test then this could be easily broken.

Assigning to myself for tests

+++ b/core/modules/path/src/Plugin/Field/FieldWidget/PathWidget.php
@@ -44,6 +44,8 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
+    $alias_description = $this->fieldDefinition->getDescription();
+    $alias_description = $alias_description ?: $this->t('Specify an alternative path by which this data can be accessed. For example, type "/about" when writing an about page.');

Can we set default field descriptions in default config as well. In which case we can also just remove this fallback maybe and just rely on the field description?

Maybe that would be a BC break in which case I understand the fallback but its counter-intuitive and may lead to strange bugs, eg. you want to remove the description by entering nothing or removing what you entered for the field but it then makes this built-in thing disappear. That sounds to me like a usability WTF.

So I think we would rather remove this fallback entirely. Its a very tiny BC break to pay for evident behavior in the future :)

Forms are specifically excluded from the BC promise. So I'm not sure where the BC break is - what this does mean is that you need an upgrade path.

@alexpott: well this is both form and config :) Its a form driven by config. If the fallback is not there, existing fields will not have the description unless we have an upgrade path. The question is how can we find what needs an upgrade path. Eg. how do base fields altered in get this?

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Still seems valid.