#Needs backport to D7

I understand that this issue here was raised to explicitly allow underscores in attribute names, however, I would like to point out the following from https://www.w3.org/TR/REC-xml/#NT-Name

• Attribute names should follow the NameStartChar (NameChar)* format
• NameChar may contain dashes, dots, mid-dots, numbers (among other characters), but it does NOT explicitly state allowing underscores
• also, NameStartChar (the first character of attribute names) must NOT be a dash - it can however be a colon ( : ) or an underscore.

So unless I'm interpreting that wrong, the current regex is incorrect, as it allows the first character of attributes to be a dash. So if we want to allow underscores, they should only be allowed as the first character of the attribute name.

So unless we don't want to follow the standard strictly (in order to allow the use case for which this issue here was opened), the regex should be like so instead:
[_a-zA-Z][-a-zA-Z0-9]*

The above:

• allows the first letter of the attribute name to be an underscore, but NOT a dash
• allows any character following the first character to be a dash, but NOT an underscore

Not sure about how people feel about the rest of the characters (colons, dots, mid-dots etc.). They seem edge cases to me, and best left to be discussed in a follow-up issue, in order to avoid derailing this one here.

my 2c.

Regarding #157 and the idea to have a second page to list disabled formats I think this was answered in point 2 of the href=" https://www.drupal.org/project/drupal/issues/2502637#comment-15058495 🐛 Disabled text formats can't be seen in the GUI Needs work ">Usability report in comment #116. Specifically they state "The group agreed moving the discussion how the enabled/disabled state is communicated to a follow-up issue with resolution TBD."

@vijayavelr, Welcome to Drupal! Thanks for the interest in this issue. Since your solution is a custom module and will never get committed to core I suggest you create a contributed module → for that work. That is, if you wish to.

I also checked the priority and agree with alexpott that this is not Critical. There is not data loss and there is a work around. I have added the work around to the issue summary, so it is can be found.

@vijayavelr, Welcome to Drupal! Thanks for the interest in this issue. Since your solution is a custom module and will never get committed to core I suggest you create a contributed module → for that work. That is, if you wish to.

I was looking at other other configuration forms for examples of having a separate page for disable 'things'. There is none that I saw. The closest was search pages which simply add a column for 'Status'. That is easy to implement but does not fulfill the suggestion of a second page. For me, I think before coding and changes this should get direction from usability. I also am inclined to think that this should go in as an incremental step towards a better solution. I will ping in #usability.

I also checked the priority and agree with alexpott that this is not Critical. There is not data loss and there is a work around. I have added the work around to the issue summary, so it is can be found.

Updated summary and removed corresponding tag.

How would I go about getting the usability team's review on this?

Have not reviewed yet but issue summary appears to be incomplete could that be updated please

Can use https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... → . for help if needed.

Added test case .

Please review , moved NR

apaderno → changed the visibility of the branch 3454259-d7-validate-the-redirect-url-only-when-necessary to hidden.

I committed the changes directly to the project branch because the issue fork branch was not updated and I was not able to update it. (The issue fork UI allows to update the fork only from the default branch, which is not the Drupal 7 branch.)

I have created a custom module patch disabled_text_formats_18062024.patch → by listing the disabled formats with enable links

Step 1 :

Step 2 :

Step 3:

Step 4:

Hi I tried the steps above but the issue only occurs when we try to change the URL and not when we visit the URL for the first time?
If that is the expected behaviour how can we write a test for that scenario?

Thanks for continuing to work on this. Will need a test case showing the issue.

Just adding a link to the comment quoted in #157. It is at #949220-49: Text format names can never be reused (Possible solution: Allow disabled text formats to be re-enabled) → .