🇦🇺Australia @klonos

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.

@bendqh1 yes, building sites straight in D10 should be relatively easy and the workflow should be similar to D7. However, the tools and technologies needed in order to work with D10 are more and have a learning curve (which means effort, which means time, which means $$$). Also, just try setting up a D7 (or Backdrop) site on a cheap, $5/month hosting company, and do the same with a D10 site. Compare how much time both of these tasks take. Add some content and Views etc. to both sites, and then benchmark both. You'll see then. Sometimes you won't have to even benchmark anything ...it will be obvious by the time it takes for pages to load. And sure, you can put advanced caching and CDNs etc in front of the site to have it perform well, but again, that costs $$$.

Also, moving small sites with a only few pages to Drupal 9 or 10 should be easy. But there is a reason why 100s of 1000s of sites are still on D7 https://www.drupal.org/project/usage/drupal →

If you take the time to read the posts I provided above, you'll see things like this (coming from established and very experienced Drupal agencies in the industry):

Our first guesstimate placed a full Drupal 8/9 rebuild in the neighborhood of 4000 hours. ... The platforms run some 50% faster than before (Pantheon and Backdrop CMS share the credit) ... Perhaps most impressively, our total cost was less than 20% of the cost to rebuild

...when we are talking about big sites, the 20% of 100,000s of dollars is A LOT of $$$.

As with regards to your comment about what features you assume will first come to Drupal rather than Backdrop, I will tell you that people were saying things like "Backdrop is a small project. They won't be around for long" ...and that was more than 10 years ago. Yes, we are a much smaller community, but considering our size we have been doing really great things, and our adoption has been steadily upwards (about 400-500 new sites launched per year). There are features that get into Drupal first/faster, but Backdrop for example has had a layout builder since v1.0 back in 2015 (although not as complex or impressive as the one in Drupal), and we have been enjoying a Project Browser/Installer since v1.4 back in 2016, whereas the respective solution in Drupal is still in beta.

Regardless of the above, it is not about whether Backdrop or Drupal is better - they are both awesome pieces of software, and if you know how to work with one, then you know how to work with other too (my day job has been exclusively Drupal since 2017, but my passion is with Backdrop). All I was trying to say is that it's just silly to not offer Backdrop as an option to customers that don't have the budget for Drupal. That's all.

For those looking for other options for page/layout builders in Drupal, you may want to watch this video from OSTraining that lists a few: Exploring Page Builders in Drupal 9

Also you may want to stay tuned for more exciting news: https://dri.es/evolving-drupal-layout-builder-to-an-experience-builder

For those looking for other options for page/layout builders in Drupal, you may want to watch this video from OSTraining that lists a few: Exploring Page Builders in Drupal 9

Also you may want to stay tuned for more exciting news: https://dri.es/evolving-drupal-layout-builder-to-an-experience-builder

For everyone coming to this blog post that would like to continue working with D7 because you have customers still on D7 without the budget to move to modern versions of Drupal, or because you don't want decades of acquired knowledge to go to waste, or if you are yourself a D7 site owner, then you should definitely give Backdrop CMS a go. You can spin up an ephemeral 24hr sandbox site in less than 10sec and look around: https://backdropcms.org/demo ...it should feel right at home straight out of the box!

You will be happy to find that so may things have been bundled into core, so you can reduce the time to start working on the site. ...you get updated versions of things like jQuery and CKEditor 5, plus functionality previously provided by separate modules like Views, Media, Pathauto, Token, Admin Menu, Entity API, Display Suite, Panels, Nice Menus etc. ...all there without having to lift a finger! And this was not just a quick "chuck every contrib module in core and call it a day" thing - everything was carefully integrated and become part of the core CMS + sensible defaults that work out of the box for the majority + so many UX improvements and fixes over the past 10+ years that you will realize all the love, time and effort by people that come from the Drupal community that went into that fork of Drupal 7.

Most of the Backdrop CMS community are smaller shops or individual freelancers and they have been working with both Backdrop (for customers with smaller budgets and no complex requirements) as well as with modern versions of Drupal (for more complex sites and organizations that need and can afford that). This is a really good combination of a "dual toolset":

• you don't have to hire new developers that are familiar with whatever other technology/CMS you might be considering, as your existing developers do not have to re-learn anything from scratch. If they know how to work with D7, then they should be able to do just fine in Backdrop.
• If your existing customers don't have the budget or the need to move to modern Drupal, then move them to Backdrop and keep them happy (they get security coverage + new features+ they won't need to re-learn how to use a new CMS either). Perhaps in time they will grow and have the budget to move back to Drupal, perhaps they'll just stick with Backdrop - either way, you should be able to accommodate them and not lose customers.
• What's more, you are keeping everyone (yourself, your developers, your customers) within the same wider community, which will benefit the wider Drupal community in the long run.

Lastly, for those that still think that only modern versions of Drupal are the only right fit for the enterprise, I have (old) news for you: enterprise and larger/complex sites have been running securely and performantly for decades on D7 and now on Backdrop, achieving complex and "ambitious" requirements just fine. In the past 1-2 years specifically, we have seen many rather larger Drupal agencies like Lullabot, Aten, and recently Giant Rabbit to start moving "large" customers to Backdrop with great success, and they have started including Backdrop as an alternative option in their RFQs. You really need to read up on these posts if you have not done so already:

• Why we moved two Stanford websites to Backdrop CMS (and watch the case study presentation)
• Making the case for a Drupal 7 to Backdrop CMS upgrade
• Stanford University Bio-X: Decision to move from Drupal 7 to Backdrop
• Case study: Moving six sites (and counting) to Backdrop at Penn State University

So yeah, don't give up on Drupal just yet ;)

Linking to the Drupal 10 localization server upgrade initiative status presentation from DrupalCon Lille 17-20 October, 2023. The video description is stating the following:

A group of volunteers is currently porting the Drupal community translation server (localize.drupal.org) from Drupal 7 to Drupal 10. This platform is an important part of Drupal's infrastructure: if you ever have installed Drupal in any language other than English, you have already (transparently) downloaded translations from Localize, which is also a collaborative tool where contributors from various linguistic and cultural communities coordinate their efforts to get Drupal core and contrib projects translated.

In a first phase, we have focused on porting existing features. However, by the time we will give this presentation in Lille, we should be working on new features, such as: UI and UX improvements, web services (for instance to get statistics per language), addressing crediting issues, or even integrating efforts around a translation memory tool for Drupal. Volunteers will be more than welcome to work on issues during the event and take care of our tools.

Also updating the issue title to reflect D10 as the target version the site is going to be upgraded to.

I would be willing to agree with most of the things mentioned in this statement, but certainly NOT better performance. You used to be able to run a D7 site just fine on $5 or $10/month hosting services, which is not the case with D8+.

This article compared early versions of Backdrop CMS against D7: https://backdropcms.org/news/backdrop-vs-drupal-7-benchmarks-php-55-56-a...

The gist of the article is the following:

• Backdrop is 20%-30% faster than vanilla D7 when page cache is enabled
• When page cache is disabled, Backdrop is about 2% slower in php7 and about 11% slower in php5 than vanilla D7, but you need to keep in mind that vanilla Backdrop contains many contrib modules in its core. If you added all these contributed modules to a D7 site, it would surely run much slower.
• There was no comparison done between Backdrop and D8, but there are plenty of comparisons of performance between D7 and D8 that people can have a look at. Backdrop should be comparable to D7, but it has so many more added modules/features.

Although that article is from back in 2016 and there aren't any recent benchmarks on php8, this article here might be of interest: https://atendesigngroup.com/articles/making-case-drupal-7-backdrop-cms-u...

Highlights from the above-linked article:

The short answer is that Backdrop CMS is an upgrade-in-place for Drupal 7 that resolves end-of-life (EOL) concerns and facilitates further feature development. Importantly, it is dramatically more cost effective...

In January (2022) we launched Stanford Seed Funding and Stanford On and Off-Campus Learning Opportunities on Backdrop CMS. All said and done, upgrading both platforms took about 550 hours across three calendar months. That was more than we’d originally hoped, but dramatically less than the 3500 - 4000 hours we informally estimated for a rebuild in Drupal 9.

Today Stanford On and Off-Campus Learning Opportunities and Stanford Seed Funding are humming away on their new codebase and in their new hosting environment performing some 50% faster than before. Our automated tests — nearly twenty suites containing thousands of individual steps — run in ~20 minutes instead of an hour or so. Our total cost was less than 20% of the cost to rebuild.

Will this also be committed to 10.1.x?

klonos → created an issue.

@katannshaw → and @Amber Himes Matz → admittedly this is a hard problem to fix, but at the same time I don't think that it can be marked as "works as designed".

To sum up the problem:

• <label> elements should have a for attribute that points to an HTML id of a labelable element (see https://html.spec.whatwg.org/multipage/forms.html#the-label-element )
• <div> elements are NOT labelable elements (see https://html.spec.whatwg.org/multipage/forms.html#category-label ), so they should not be pointed to via the for attribute (and not have a <label> to begin with).

So this for example, is NOT proper use of the label and for attribute:

<div id="edit-my-item" >
  <label for="edit-my-item">Test item </label>
  <div class="description">Test item description.</div>
</div>

After some quick research, the best suggestion I have found is to use a combination of a <span> and the aria-describedby attribute. Something like this for instance:

<div aria-describedby="label-for-div" >
  <span id="label-for-div">Test item </span>
  <div class="description">Test item description.</div>
</div>

Noting the following from https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut... :

1. the aria-labelledby attribute is not appropriate, because it should only be used for interactive elements (which div s are NOT)
2. the aria-describedby is not ideal either, since it should be used for a description (longer text) rather than a label (short text)

The purpose of aria-labelledby is the same as that of aria-label . It provides the user with a recognizable, accessible name for an interactive element.

The aria-labelledby and aria-describedby attributes both reference other elements to calculate text alternatives. aria-labelledby should reference brief text that provides the element with an accessible name. aria-describedby is used to reference longer content that provides a description.

Reopening this issue in order to figure out a proper solution to this, rather than haste to dismiss it.

We've addressed this in Backdrop CMS with https://github.com/backdrop/backdrop/pull/4382/files (to be included in the upcoming 1.25.0 release in May 15).

The code changes were fairly minimal and straight forward:

• mostly an implementation of hook_field_widget_form_alter()
• a handfoul of CSS lines

These changes depend on and take advantage of the addition of a new '#indentation' property for form elements in the Form API (which is a new feature, and slightly more elaborate set of changes): https://github.com/backdrop/backdrop/pull/4364/files

...so perhaps they can't be considered for inclusion to D7 core.

...I will leave this MR here to help us collaborate, but from reading through this thread it seems to me that we need a decision with re to whether it is preferred to keep using a hidden span, or to remove that and use aria-selected instead? (or do both?). Until we know what works best for a11y, we cannot really move this forward.

Sorry for crossing wires here. Since there is so much interest to contribute by multiple members, I have created a fork/branch and applied the patch from #16 (thank you Nikhil_110), then fixed failures. This way, we can all add commits to that branch instead of having to upload multiple patch files here, and to keep re-rolling them. Lets please do that, shall we?

There was another instance in core/misc/vertical-tabs.js that was appending the span with the "active tab" indicator, so I've changed that to be adding a single space before the span.

I've also updated the issue summary, to fix a typo, and change the suggestion to consider using "aria-selected" (instead of the original proposal to use "aria-current").

klonos → made their first commit to this issue’s fork.

Slightly tweaked and clarified things.

I personally have availability most all days/times (although in Melbourne/AU timezone) in the spirit of "I can make time whenever most others can" - I'm very flexible.

klonos → created an issue.

gargsuchi → credited klonos → .

gargsuchi → credited klonos → .

Here are my thoughts on the proposed solutions so far:

In the original/legacy design, the druplicon seems to be the prominent element, which is nice. Although the proposed design in #2 tries to mimic that and modernize it, I find the "hook" bit of the question mark too "busy" and confusing, and that it unnecessarily draws attention - it also seems proportionally huge. I would prefer it if it was more compact.

I really like the design in #18, as I find it slick and to the point, without any unnecessary "bling". I wouldn't mind some smart/funny textual comment to go along with it, rather than raw "tech lingo" coming from robots.

#24 seems a bit too much and as if it is "celebrating" the 404.

My 2c - not an expert - not a designer - just expressing feelings/reactions for having a look at the proposals, and I understand that personal preferences and reasoning differ. Please do not feel offended/sad.

FTR, I don't feel strongly re adding inline comments, but just wanted to say that more inline comments in not a bad thing, and that at the end of the day it'll be either more comments, or more potential confusion and more (duplicate) issues raised 🤷‍♂️

what would the checkbox label be? Are there any other circumstances where Drupal/Symfony returns 503? Maybe this could be a followup issue?

@ John Pitcairn I haven't checked whether there were other cases where 503 is returned - I just happened to notice that in D7 in drupal_deliver_html_page() there are checks for 404, 403, and also for 503, and in the case of 503 it was only calling things relevant to maintenance status (it is adding a "'503 Service unavailable'" HTTP "Status" header as well).

Anyway, I thought that it might be relevant here, in case people want to add blocks that are shown during maintenance mode only. That's why I brought it up.

Can certainly be a follow-up issue if people think that it is not relevant/appropriate here or that it unnecessarily broadens the initial scope of the issue.

Not sure if we want to keep translatable string parity with D9, but for the respective issue in Backdrop CMS we ended up using this generic message that doesn't mention any username at all:

> You cannot use a password reset link while logged into the site. Please logout and try using the link again.

I have created a MR here: https://git.drupalcode.org/project/drupal/-/merge_requests/3581

klonos → made their first commit to this issue’s fork.

klonos → created an issue.

I would like to help with the D7 EoL Soft Landing initiative: https://www.drupal.org/community-initiatives/drupal-7-soft-landing-initi... → .

Is it worth it adding 503 to the mix here? (to allow visibility conditions for blocks when in maintenance mode)

I also agree with won't-fixing this if the security concerns apply, however, to avoid someone raising the same issue to propose this in the future (because they aren't aware that this has been raised/discussed/decided before), should we at the very least add an inline comment to those 2 places stating that the directory name is intentionally NOT disclosed for security reasons?

Perhaps also add to that inline comment something about what the alternative is, in which case I find the "it should probably be the caller of save() that reports an error to the user" phrase by @longwave above to be short and to the point. So perhaps tweak that and use it?

Thanks @Liam Morland 🙏

Although I could not reproduce the issue with the duplicate headers reported in 🐛 Duplicate X-Content-Type-Options headers both with the value nosniff Fixed (tried on my local with both ngnix and apache), this is a simple, straight-forward change that makes sense and mimics what has been added to the .htaccess file in Drupal core 10.1.x (minus the Symfony-related changes that are not relevant in D7). Based on that, I am going to go ahead and mark this as RTBC.

@Berdir trying to move this forward, can you please provide some additional technical direction? What should the requirements check be, and what would you then expect the error to say?

I have tested this on D7.94 (and Views 7.x-3.28 FWIW), where previously I would get these 4 warnings (after for example clearing caches):

Warning: strnatcasecmp() expects parameter 1 to be string, array given in admin_menu_element_sort() (line 733 of /app/sites/all/modules/admin_menu/admin_menu.module).
Warning: strnatcasecmp() expects parameter 2 to be string, array given in admin_menu_element_sort() (line 733 of /app/sites/all/modules/admin_menu/admin_menu.module).
Warning: strnatcasecmp() expects parameter 1 to be string, array given in admin_menu_element_sort() (line 733 of /app/sites/all/modules/admin_menu/admin_menu.module).
Notice: Array to string conversion in check_plain() (line 1908 of /app/includes/bootstrap.inc).

After applying the patch from the MR via via https://git.drupalcode.org/project/helper/-/merge_requests/1.patch all these warnings/notices go away.

The code does exactly what the maintainer of the module suggested in #5, so RTBC 👍

...I've added a comment with a simple code suggestion to fix the date output according to the RFC expectation, but as I mentioned in my earlier comment, perhaps we should offer an option to be outputting the date in UTC instead of local time.

The code generally looks good, and I have tested this in simplytest.me with https://git.drupalcode.org/project/securitytxt/-/merge_requests/5.patch and confirmed that it works as expected:

1. I navigated to admin /config/system/securitytxt
2. I added dummy input for the email and phone fields, since at least one contact method needs to be provided
3. scrolled down and found the "Expires" fieldset
4. the "Expire date" field, was marked as required 👍 (since the RFC states that this is a requirement)
5. the date was set to a year in the future 👍
6. saved configuration
7. I navigated to /admin/config/development/configuration/single/export and confirmed that the settings were saved
8. the expiration date was saved as a Unix timestamp 👍
9. I then navigated to /.well-known/security.txt and the output as as expected (mostly):
   

   Contact: security@example.com
   Contact: 123456789
   Expires: 2024-01-27T02:37:37+00:00
   Signature: https://master-k6xfydjaryuxcpxtpgvolwenkzysbfpd.tugboatqa.com/.well-known/security.txt.sig
   

I'm marking this as "Needs Work", since the standard requires this to be in ISO 8601.

I ended up testing this in simplytest.me and it works:

1. I navigated to admin /config/system/securitytxt
2. only added dummy input for the email and phone fields
3. saved configuration
4. I navigated to /admin/config/development/configuration/single/export and confirmed that the settings were saved
5. I then navigated to /.well-known/security.txt and the output as as expected:
   

   Contact: mailto:security@example.com
   Contact: tel:123456789
   Signature: https://master-gvsv2yytmhdtth5c31xiqvvgbpw4mmdd.tugboatqa.com/.well-known/security.txt.sig
   

Sorry, I didn't realize that there was a patch already provided for this, since the issue was not set to NR.

I've reviewed the patch, and the changes seem straight-forward. I'll set this up on my local and test to confirm.

Hey @danieljrmay 👋 ...since it's been a year without any progress here, I hope that you won't mind if I take a crack at this.

...another last edit to create a "Maintainers" section at the end of the file, and add both maintainers there.

I have reviewed this and fixed even more things:

• Added single line after all headings
• Removed extra lines (more than 2) in some places
• Added 2 lines after headings
• Indented the nested list items in the ToC at the top by 4 spaces
• Removed leading spaces from paragraphs
• Wrapped paragraphs at 80 characters (besides a link, which was previously wrapped in a way that was breaking it in my markdown viewer)
• Added dots after the numbers in the heading for consistency with other headings. We can remove the dots, but we need to be consistent - some headings had them before, while others didn't have them.
• Added a couple of commas mid-sentense where it made sense.
• Converted the instructions on permissions to a bullet point list.

Could use another round of review from someone else now, in case I missed something.

klonos → made their first commit to this issue’s fork.

PPS: @hestenet not sure which other issue you meant to cross-link back in ???, but you have accidentally linked #2705733: Update organization content type to better reflect types of organizations in Drupal ecosystem → twice.

Anyway, removing the duplicate entry.

https://drupalsouth.org is an annual event happening in AU/NZ (separate to the various, smaller local Drupal camps/meetups happening regularly multiple times throughout the year). I see that the profiles have checkboxes for all US and EU DrupalCons, but not this event. Can we please have them added? (past ones as well) ...the implementation for this is already in place - we just need to add more checkboxes/options to the existing field, so shouldn't require too much effort I imagine.

Noting that the site I have linked above is home for the DrupalSouth events, but also DrupalGov, which is an event dedicated to the Australian and New Zealand government sector (also annual, minus the COVID years that threw event planning/organizing off worldwide).

I'm not 100% sure if there are other similar annual events being organized in South America, Africa, India and other Asian countries. If there are, then those should also be listed.

PS: once these are added, can we please get an announcement in the monthly newsletter, to let people know that they can update their user profiles? Thanks

Here's a feature module to help those that want to test/reproduce/troubleshoot this. I've named the fields and groups according to the order they are meant to be, but here's what the order should look like:

Updating issue summary with some details and slightly reordering steps to what makes sense.

Anyone feel like the issue summary needs an update? I mean, D6.4?? :)

...title change then ;)

subscribing...