🇺🇸United States @drumm

Thanks, that actually has deleted everything except the archive of past events. There’s some discussion of that at 📌 Migrate documentation into the new system Active , it would be good to keep that for posterity. I’ll handle that as an automated migration before closing out that issue. There is too much structure and too many pages to make manually migrating worth the time and effort, when it can be automated.

This was migrated

This was removed with 📌 Identify Migration archive page for delete or needs migration Active

Thanks for the work here! I’ve started going through the deletions, triple-checking and completing them.

I’ve deleted the remaining pages. Thanks!

I agree everything in this book can be deleted, and that’s now done.

I don’t think this is relevant now.

Projects have a documentation link field which can go anywhere, since things like documentation in GitLab pages are effectively off-site.

Documentation on Drupal.org has related content that can include projects, or any other content.

I don’t think so. It looks like a key part of the plan was to add a field to issues. That is not doable with GitLab, which does not have arbitrary fielded data.

@drumm super! I think the only description in the sidebar that needs an update is Ceremony/awards. How about "a special event to celebrate a major Drupal release or the accomplishments of our community members."

Thanks, done!

I’m thinking the same module categories would be good to have for consistency in browsing projects, whether there is a unified module & recipe search, or switching between the two modes.

Those look like projects that didn’t migrate for me locally for whatever reason, I didn’t pay attention to the console output there, but there was some.

So the plugin: migration_lookup section might not be right for the compound primary key in this table. We might not care since production should be in a better state.

This mostly works now, but this error appears 281 times

 [error]  All the id fields are required for a table migration. (/var/www/html/web/modules/contrib/migrate_plus/src/Plugin/migrate/destination/Table.php:180)
 [notice] Processed 64153 items (63872 created, 0 updated, 281 failed, 0 ignored) - done with 'drupalorg_migrate_project_release_supported_versions'

@pameeela - Is there any part of 📌 Decide on naming convention on recipes Active that could move forward with this? For example, a way for recipe maintainers to select “Site starter” or “Site feature”?

I see categories in the issue summary, does this mean they have the same https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → categories as modules?

The immediate next step will be adding a hidden field on general projects in D7 which rolls up the project’s releases’ composer types into a multivalued text field in anticipation of conditional field(s) for projects that have releases that are recipes. I initially thought this would be done only for search indexing, but we’ll likely want this data always available on general project nodes without rummaging through all releases.

We’re tentatively planning on taking a little extra time to build the actual browsing pages on new.drupal.org from the start, rather than building it twice.

Which web browser are you using?

✨ Provide file upload for forums Active is sufficient for tracking this issue, we do not want duplicates for the same site being upgraded.

retry-after: 10 is now in the response headers.

Deployed!

We recently enabled this new-to-us feature from a service provider, in response to API requests sent at an abusive rate. It looks like this is something we can customize to correct.

Our initial setting for the rate limit was somewhat arbitrary. Do you have a sense of how far below your previous crawl rate this kicked in at?

This is all deployed and I’ve updated the block on https://www.drupal.org/community/events →

Thanks!

This is now deployed

I’ve done the initial updates to the fields. I’ll plan to make the same changes to the “Events for all!” block on the right side of https://www.drupal.org/community/events → . Any updates for the copyediting there would be welcome.

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

I’ll go ahead and deploy what I have so far in the issue summary, followups can always change the text later. In particular, https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → could be linked to when it has some updates to be more comprehensive and align with core’s current release cycles.

Crediting people who helped in 📌 False warnings about security updates Active

Updating for 📌 Remove “recommended” status for releases? Active

Remove note about feature branches which is no longer true.

drumm → created an issue.

- The recipe directory name—which is essentially what the recipe name comes down to—has only a loose connection with the project on d.org. I believe we should only send an application update if the recipe includes a composer.json file, so we can verify that it belongs to the drupal/ namespace as outlined in one of the conditions in the issue summary. This would filter out all custom recipes added at the project level (i.e., not available on d.org even if the recipe name matches a general project on d.org), as well as recipes under other vendor namespaces.

That sounds correct to me.

- This also means that all core recipes would never be tracked. Are we okay with that, or should we support core recipes too? If so, we’d need to collect version information from the drupal/core package.

Yes, we do want core recipe information, so that will need to be a special case.

Cleaning up the draft in the issue summary

The issue summary looks all good to me. Are there any open questions or likely revisions?

In general, removing options would be tough, since we will have to migrate the existing content to not use those values before we remove the options. Right now there are no removals requested in the issue summary.

We decided against using this module, since we remembered we have a way to embed blocks on pages built with paragraphs.

However, this module is popular and I’m sure a stable release would be generally appreciated.

Are there any stable blockers now? Blockers for an RC release?

The links are counting exactly what they link to. I think the request is to update the links to link to the issue listing filtered by only open issues, not all issues.

I agree this is not relevant since we publish advisories directly for the API composer audit uses

The issue summary mentions including the update status site key, which is used to de-dupe update status data per-site.

We will have to decide on a new algorithm for translating the recipe application numbers into popularity for ranking. Something along the lines of including the last N weeks, potentially with some decay function so the last week contributes more to the rank, and each earlier week contributes less. Until we have some real data, it isn’t worth much speculation about the specific implementation. The earlier we have data, the better.

Additional metadata that might help is welcome, as long as it doesn’t send identifying information about the site, or delay initial implementation in core. Adding method of installation to the query string with the request would be useful - installed via installer, project browser, drush, as a dependency, etc.

This is now deployed!

A flag isn’t needed, we already have data on what’s a recipe since ✨ Add composer release type field Active

Any listing will not have a chance to be good until ✨ Add tracking for when recipes from Drupal.org are applied Active moves forward. We can only sort by data we have, like alphabetical or last updated date.

drumm → created an issue.

This is now deployed

I’ve added a draft to #686918: Add help text to project release admin page to warn about marking branches unsupported and the impact on update status → for adding help text, please help review and improve it.

It looks like the conclusion of this issue was to add help text and documentation, so I think the other issue will cover making this improvement.

Making the title more straightforward 

Adding a draft to the issue summary for review and updating.

It looks like https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → might be a good page to link to for a detailed explanation, although that page could use an update for Drupal core’s current release schedule.

Updating for 📌 Remove “recommended” status for releases? Active

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

No changes here, I think the behavior is likely different if you are logged in, which could help get it right in some cases.

I fully expect we’ll fix this as a side effect of upgrading to modern Drupal. Effort would be better spent in getting the community events themed with the new brand and landing page refreshed.

Now is a good time to do this since 📌 Remove “recommended” status for releases? Active did get deployed.

This is now all deployed.

Sorry for the abruptness of this change. This is something I’ve been mentioning in other issues, but should have had its own issue earlier. The timing is actually prompted by ✨ Support confidential issues in git.drupalcode.org for security team triage Active , it would be good for the new.drupal.org automations to post an automated comment including what versions of the project with a potential security issue are currently supported. So we need to migrate this data to the new site. Before migrating, we’re simplifying so there is less to migrate and less UI to port to modern Drupal when we get there.

This issue will remove the option to designate releases as “recommended” once it is complete. It will be the last thing to go, once everything that depends on it is removed. That will simplify the page and will be a good opportunity to follow up with #686918: Add help text to project release admin page to warn about marking branches unsupported and the impact on update status → in the near future.

People should see the higher version number, that’s a stable release, as the recommended version. “Recommended” was never communicated to Composer, or update status. So it was only ever shown on project page, many people might not have seen it for some time.

lifecycle: in .info.yml files may be a good way to communicate deprecation of old versions: https://www.drupal.org/docs/develop/creating-modules/let-drupal-know-abo... →

https://www.drupal.org/project/drupal → is now updated and drupalorg module no longer uses the project_release_supported_versions.recommended column.

The project is now a module and Composer install is now available.

The project was created as a distribution instead of module. I will convert it to a module.

Keeping this issue open for

The remaining use of the “recommended” filter is on https://www.drupal.org/project/drupal → . That will add the other two supported releases, currently 11.0.11 and 10.3.12.

I did go ahead and replace the mild grey for non-stable releases with the mildest grey. This should improve contrast, and reduce the highlighting of prereleases.

Whenever we do small design changes, we’ll be incorporating the new branding elements. Hopefully things don’t look too mismatched as they gradually change, but it's a lot more doable than attempting to get everything right all at once.

And yes, the Recommended option for maintainers will be removed once everything that depends on it is removed. This should happen in within the next week.

The remaining use of the “recommended” filter is on https://www.drupal.org/project/drupal → . That will add the other two supported releases, currently 11.0.11 and 10.3.12.

I didn’t want the non-stable color to be too much of a warning. While we do hope production sites can run as many stable releases as possible, we also want maintainers to have some visibility for testing pre-releases.

The text alternative is whether the release is alpha/beta/rc. I decided against additional labeling, since the releases are already very busy.

The initial deployment here is done, leaving open for https://www.drupal.org/project/drupal → which is still showing all “recommended” releases instead of supported.

Notes for deployment:

• cc views
• TRUNCATE cache_project_release_download_table;

This should be ready to deploy now.

The dev site build completed.

eowg-drupal.dev.devdrupal.org is building out and should be available in 30 minutes

Done, you should be able to ssh heatherwoz@wwwdev1.drupalsystems.org

I added a “community events” category for drupalorg module issues to help track issues that will be landing in drupalorg module code. Please do make sure issues are moved to drupalorg module for visibility and implementation planning.

Since we are in progress moving to new.drupal.org on modern Drupal, some things should wait for the event content type to move over. Getting the theming of event nodes implemented with the theme for new.drupal.org is something we might want help with, too.

I think this is no longer an issue since the events landing page was simplified.

We’ve done an initial port of node & field access customizations to the modern version of the site. So we don’t do this work twice, it should wait for events to be migrated to the modern site.

drumm → created an issue.

This looks like it can be closed. The original image is still rendered in WYSIWYG instead of being filtered out, that’s not ideal. It isn’t showing what you will get on save, and could be used as an entry point to cross-site request forgery (CSRF) attacks. The worst example of the attack, <img src="/user/logout"> is mitigated since the logout route now has a token to prevent CSRF attacks.

Since the WYSIWYG is requesting any img src URL, that could have anyone editing having requests made on their behalf. However, CSRF is generally prevented on the receiving end, as was done with /user/logout. I suppose there could be a privacy concern, since a 3rd-party request could still be made. I’m sure this was all handled in previous issues and the current state is okay.

I decided against adding “This release is not stable.” The releases area is already very busy, and alpha/beta/rc are shown in the version number.

This is currently in test on https://gitlab1-drupal.dev.devdrupal.org/project/project_module

benjifisher → credited drumm → .

drumm → created an issue.

This was done

Now this is done

Need to forward-port this

This is now deployed

drumm → created an issue.

Since the new cluster has been stable, we can move ahead with this.

Caching looks like its opt-in via editing .gitlab-ci.yml, so it's not too much risk destabilizing tests, until we get something using this into the main templates.

I’m not seeing any explicit notes about cached items expiring and being cleaned up, we will want to make sure it's not a runaway cost.

I do not think this makes sense to work on before ✨ Move issues from www.drupal.org to git.drupalcode.org Postponed so we do not need to do this work twice.

Another even simpler option would be to not show the filter at all, anywhere, but just render the "negative" icons in the project card and detail page. This might be more drastic but probably none of the top modules will "show" those icons so it's not like we are going to be flooded with bad projects.

Big +1 to this. If there’s concern people will see “bad” projects, we can rank them lower server-side. We should probably do that rank adjustment regardless.

🌱 Change how modules and submodule dependencies are handled to have more consistent namepsaces [DRAFT]. Active is that issue

Or does this only happen when the submodule has its own composer.json?

Submodules never have a composer.json, or if they do, nothing reads/uses it. Composer only works at the repository level, reading the composer.json at the root of the project. Packages.Drupal.org also does nothing with composer.json files in subdirectories.

so that means if we have a submodule in any project, and we want to move that out into its own separate module we are forced to change the name of the module? That seems like it could be really disruptive.

In general, we want to make sure people get the same packages for their site deployments. If someone is requiring a submodule, they should keep getting the same submodule. If an arbitrary new project could take the namespace, that would be a giant supply chain security problem.

Deleted the pages marked in the issue summary. This one is getting close to done!

This is working as designed to prevent a new package from taking over an existing namespace. Since composer only operates on packages, and Drupal has additional dependencies on subcomponents, the subcomponents are made available for dependency resolution with Composer. We of course do not want the possibility of a new module to take over the existing namespace.

This is a symptom of #2201041: Do not re-tokenize text → “2.2” is being indexed as two separate words. This is great for punctuation, but not other uses of periods.

The workaround, which unfortunately does not help here, is to replace the dot with a space when searching. Short words are also not indexed, so the “2”s aren’t indexed. This does work for searching for filenames, like https://www.drupal.org/project/issues?text=WCAG+maintainers+txt&projects... →

Since issues are moving to git.drupalcode.org, ✨ Move issues from www.drupal.org to git.drupalcode.org Postponed , we are no longer fixing most problems with the existing issue queue, so we can concentrate preparing for the migration.

This is deployed on D7 and needs porting for modern Drupal

drumm → created an issue.

fjgarlin → credited drumm → .

Are you saying the demo is unusably broken, or just margins are an issue?

greggles → credited drumm → .

That documentation is updated now.

Basically any Closed status is now the same as Fixed for crediting. I recommend maintainers credit any issue that required effort as if it were fixed, for example something that cannot be reproduced might have required debugging to get there. I don’t recommend maintainers credit duplicate issues that don’t demonstrate some detailed effort from the reporter. As always, where the line is drawn is up to each maintainer.

Removing sentence that is not true

Updating for ✨ Grant credit for all closed issues, not just fixed issues Active , all closed statuses may be credited.

Updating for ✨ Grant credit for all closed issues, not just fixed issues Active , any closed status can be credited, too.

This is now deployed!

For the modern version of the site, we are not using OG for this. Instead just a straightforward entity reference to the parent guide, and building customization around that.

I agree we should consider merging the content types into just documentation pages. There isn’t much practical difference between the two content types. And any amount of planning guide hierarchy upfront will still want guide/page switches as the content evolves over time.

This is not something we could do in D7, the OG Menu setup is already not scaling well. One menu per page would not be workable.