🇺🇸United States @drumm

quietone → credited drumm → .

https://www.drupal.org/download-latest/cms → now redirects to download the latest stable release of the cms project.

We already had the download-latest/* menu callback for core, and this was straightforward to adapt with that path.

Done: https://www.drupal.org/project/cms →

Since D7 is now unsupported, a feed of all releases would be what we want to provide. As far as I know, that would be a new feature to be added.

Semver-versioned releases are not tagged with a taxonomy term like the non-semver releases are. They may not have any taxonomy terms associated with them so the taxonomy-module-provided feeds won’t work here.

We should not add a redirect like that, I fully expect creating edge cases like that could confuse us again when issues are being migrated. Until we know at least a couple people are genuinely confused by the current setup, I don’t think its worth trying to solve. We should be spending time on the issue migration to GitLab instead

The best way to check is if the release has field_release_category === 'current'

field_release_category for releases compatible with 6 or earlier is obsolete. Compatible with 7 is legacy

This avoids pitfalls like core versions not having prefixes, and just avoiding parsing in general.

lists.drupal.org is currently being migrated, so this may need to wait for that migration to complete, since I expect the migration to include DNS changes.

poker10 → credited drumm → .

volkswagenchick → credited drumm → .

🐛 Missing information about the version of the project going to be installed Active should make this straightforward to implement, as it should open a line of communication from package manager to project browser.

Project browser has had a few issues with hardcoding things that should only ever come from Drupal.org APIs, I don’t want to see the good progress on that backtrack.

This is now done, and pift is removed from our codebase.

This is fixed now.

The webhook for this package was set up and sent a notification to update Packagist.org, but it failed to update. I manually triggered an update.

Done, and the people with https://bsky.app/profile/* URLs are now being updated to backfill this.

With GitLab CI, we no longer have patches reviewed.

With GitLab CI, patches are no longer recommended.

With 📌 Remove project_issue_file_test (DrupalCI) Active , DrupalCI is no longer on Drupal.org.

With 📌 Remove project_issue_file_test (DrupalCI) Active , DrupalCI is no longer on Drupal.org. Gitlab CI does have the ability to automatically do a test-only run.

With 📌 Remove project_issue_file_test (DrupalCI) Active , DrupalCI is no longer on Drupal.org. GitLab CI can test arbitrary branches.

The first phase of this is now done. Old test results are no longer accessible.

Next, there is more code in drupalorg, extended_file_field, and bluecheese that can be removed since it is no longer doing anything.

And we can uninstall the module and permanently delete its data.

drumm → created an issue.

Patches should not be uploaded now, and we won’t be able to add UI text to GitLab explaining patches when issues are migrated.

Patches are no longer tested - https://www.drupal.org/about/core/blog/drupalci-and-all-patch-testing-wi... →

This space comes with the “Infrastructure management for…” banner above the footer which is now present again.

For https://www.drupal.org/project/genoring_distrib → - I’ve converted it to a general project, which is for projects that do not fit another type of project; profiles are not exactly distributions currently. When there is a valid composer.json in a release, it will be sent to Packagist.org.

Currently the package name at https://git.drupalcode.org/project/genoring_distrib/-/blob/1.0.0-alpha3/... does not match drupal/genoring_distrib, so it isn’t sent to Packagist.org. A new release with that change, and fixing any other issues will fix that.

I recommend creating a dev release from the 1.0.x branch so everything can be tested without making an alpha release for each change.

https://www.drupal.org/project/genoring → was created as a distribution instead of a module, and is now converted to be a module and is installable with Composer.

For now it is best to use https to access git.drupalcode.org in these cases. When you need authenticated access for pushing commits, you can create a personal access token - https://www.drupal.org/drupalorg/docs/user-accounts/git-authentication-f... →

Removing outdated references to patch workflow

We should be able to configure the View to output the link as an absolute URL instead of post-processing, but this is all being removed in the next few weeks as security.drupal.org is replaced ahead of GitLab issue migration.

This is not a great time to be implementing this on Drupal.org. We are a few weeks away from migrating issue credit, which will require implementing this again. There are some technical hurdles to implementing this in D7, nothing insurmountable, but our time is better spent on the migration.

Unless there’s a compelling reason to have this right now, we should postpone. The D7 site should be considered feature-frozen until after migration except for things that move migration forward.

🐛 Search summary very long and also contain adverts Active included this change.

This is also resolving ✨ Source logos on project search page from project repositories Active

Ideally, this would parse out the URI and update the query array instead of a regex, and output with l(), but this seems safe and we can do it better in the D10 version.

luke.leber → credited drumm → .

Looks good to me. Unless we have other feedback soon, I should go ahead and put this in production, so the client side implementation is unencumbered. We can always do a follow-up deployment if we want to change something. It would be great to attach a couple example outputs for client test fixtures, here or in the client side implementation issue.

There was a suggestion in Slack to distinguish deprecated vs. unsupported. I think that’d be a good idea so we can communicate ahead of dropping support for a particular Drupal client version.

I think it might make sense to combine this with the maintenance & development status metadata API into a single API request for “project browser metadata that the client can keep cached for a few hours.” While we don’t really need to over-optimize, one less HTTP request is a bit nicer for the client. As long as the client processes this support data first, we can update the rest of the API response as-needed. I can’t think of what we’ll add in the future, but I expect this pattern of needing relatively-static metadata to supplement JSON:API could be expanded to have additional metadata in the future.

Another use case for this - if something happens to the project index and we’re doing maintenance, this would be a good way to communicate that results might not be as expected, while the client Drupal version is supported.

I think we can call this done.

There’s some rough edges, but it works well enough for Drupal CMS rc2. Specifically, CI doesn’t finish before packaging starts, so tagged release nodes should be created after CI finishes. If CI hasn’t finished, that’s fine, packaging is queued again when the release is saved. Dev will be 1 commit behind, which should be fine, all we really need to know is that the fetching & attaching process works.

This is now deploying, we’ll see if it works.

drumm → created an issue.

phenaproxima → credited drumm → .

Looks like a great start. I think we’ll want to be able to provide specific messages to be shown in the project browser UI when a Drupal version loses support. That will let us giver users a path forward, either explaining the deprecation/loss-of-support, and what to do next.

For example:

$settings['drupalorg_project_browser_unsupported_drupal_versions'] = [
  '<10.0.0' => 'Not sure how you are using project browser with Drupal 9 or earlier',
  '<11.0.0' => 'Upgrade to Drupal 11 to continue using Project browser, <a href="https://www.drupal.org/some/announcement">details are in this announcement</a>',
];

The client should ideally render some limited HTML, with filtering for XSS, and validating that all URLs are *.drupal.org.

We may also want the ability to have a message without saying that Drupal version is no longer supported, so we can communicate upcoming deprecations.

Yes, that’s exactly correct. Since issues are being migrated to GitLab at git.drupalcode.org, 📌 Migrate drupal.org issues to gitlab issues Needs review , we are not fixing issues like this on www.drupal.org as the time is better spent on the migration.

List some services 

Clarifying that there is no current bug bounty

Deployed, thanks!

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

None of this should be hard-coded into the client. While there are no changes to the security advisory policy coming up, change is inevitable long-term.

https://packages.drupal.org/files/packages/8/p2/drupal/token.json has the data and text for each version: "security-coverage":{"status":"covered","message":"Covered by Drupal\u0027s security advisory policy"}

With the Drupal.org rebranding work, there were too many things like CTAs on https://www.drupal.org/download → , and the tgz & zip download links got removed.

Core and contrib release pages do have some differences, so the proposed changes for each should be clearly summarized.

Drupal doesn't really support directly downloading a tarball any more, but release pages still show .tar.gz and .zip and 'Alternative installation files'.

This is true for contrib. And mostly true for core - the results of composer create-project and extracting the archive are the same. Using Composer to create the project is a good way to make sure composer is present and working from the start.

Composer still relies on the same .tar.gz files that d.o publishes so we're not actually removing them as such.

This is totally true for contrib (technically, Composer only uses .zip files, not .tar.gz). Composer does not use the core zip files.

xjm → credited drumm → .

Remove relation to self

Remove outdated things

Remove old DrupalCI and patch things

I think this must have been fixed already. I am not seeing the behavior now.

For categories, it isn’t a regression, but we should update these to more-closely match project browsing.

• Let’s only show the categories, and not the maintenance and development status. Maintenance and development status are not meaningful unless they are something like “no further development;” the “actively maintained”-like statuses don’t affirm that it really is currently actively maintained.
• Let’s link the categories to the same browser. Project pages like https://www.drupal.org/project/token → have code which sets up these links. We probably also want the link to include the current parameters for filtering.

Is there some way we could migrate the events to d.o - community/events/past-events The content itself is probably not that useful, but the fact the events took place is nice to preserve.

Some of the old events looked like they would be a bit large to flatten into a single page, which would be required for moving into community events.

And maybe all the Google Summer of Code events could be removed - we have https://groups.drupal.org/google-summer-code

We also need to figure out the best way to handle groups.drupal.org, which could end up being a static archive. I wouldn't move anything there. That did lead me to find https://www.drupal.org/community/contributor-guide/reference-information... → , where those pages could land.

I actually have this on a dev site, this is what I have so far.

diff --git a/sass/partials/drupalorg/_project-page.scss b/sass/partials/drupalorg/_project-page.scss
index 22c5429..d035a19 100644
--- a/sass/partials/drupalorg/_project-page.scss
+++ b/sass/partials/drupalorg/_project-page.scss
@@ -6,8 +6,8 @@
   }
 }

-#page-title .repository-logo {
-  margin: -.25em .5em 0 0;
+.repository-logo {
+  margin: -.25em .25em 0 0;
   max-height: 1.5em;
   max-width: 1.5em;
   vertical-align: middle;

I added the repository logo, so there is still a visual element to the page, and it’s closer to project browser.

The old page, and project browser, have categories. I could go either way on keeping those for this issue. I’m not sure how useful the categories are on listings.

Agreed the past events should be migrated.

I updated https://www.drupal.org/node/233045 → to removed the dead links.

The migration tooling so far has been really geared toward discouraging huge hierarchies of pages, but this section does greatly benefit from hierarchy, and should be migrated with some of it. I may be able to do it with some manual work to get additional automation going. In the meantime:

• Should the year-level of pages, like https://www.drupal.org/node/299564 → for 2006, be removed? So there is a simple list of all the events here.
• Should individual events, like https://www.drupal.org/forum/general/news-and-announcements/2006-08-07/2... → , or Summer of Code years, like https://www.drupal.org/google-summer-of-code/2006 → be merged into a single page, with headings for the sub-pages?
• Where would be a good place for these pages to land in a documentation guide?

Email reports to security@drupal.org will be accepted indefinitely. There are no plans to change this.

For reports received by email, we do ask them to create an issue with a Drupal.org account. However, if an issue is valid and important to fix, we don’t let the process hold up working toward a fix. We can make the issue, start working on it, and ask if they have a Drupal.org account for collaboration on the issue. We do make it clear that to be credited on the security advisory, we do need a Drupal.org account.

Updating the organization you are credited with is doable, but does require admin access. We’re happy to update anything when asked.

I revised the pages about resetting the admin password an moved them all to https://www.drupal.org/docs/7/howtos/how-to-reset-the-administrator-user... →

Moving into Drupal 7 HowTos and adding more content from book pages

Copying content from a book page which had more-detailed instructions 

Great, the remaining snippets have been deleted. Thanks all!

What pattern do these URLs follow?