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.
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.
Deployed, thanks!
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.
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?
This should be all set so no one else runs into this in the future now.
Looks good, and I don’t see a risk of embedding arbitrary images. Deployed!
drumm → made their first commit to this issue’s fork.
Since the project has code and a release, the short name can no longer be changed. Unless you want to keep the existing name, I recommend creating the project with your preferred name. Then update azure_ai_search_vdb_provider to make it clear that it is not supported and replaced by the new project.
Projects on Drupal.org are almost never deleted. This is so end-users can trust that what they are deploying will continue to be available indefinitely.
Since https://www.drupal.org/project/webform_booking_calendar_ → didn’t fully get created, I’ll go ahead and delete it.
https://www.drupal.org/project/webform_booking_calendar → has a release, and can not be deleted. Once webform_booking has the complete functionality, I recommend marking the releases for webform_booking_calendar as unsupported and updating the project page to make the replacement clear.
I expect the trailing underscore is not allowed in GitLab project names. It looks like you also made https://www.drupal.org/project/webform_booking_calendar → recently. What is the reason for both projects?
We should keep this issue open to review GitLab’s current project name rules, and make sure we are validating in Drupal equivalently.
Ok, back to the original title. Looks like this needs to be revisited:
https://git.drupalcode.org/project/drupalorg/-/blob/8841f8823e77ae53614a...
We avoid loading 3rd-party resources as much as possible, especially JS. This is for visitor’s privacy, and security since this is JS code. If there is a really good reason this can’t be all in Drupal.org’s codebase without 3rd-party requests, then we can look around your privacy policy and make sure our privacy policy and terms are compatible.
Unless this is time-sensitive, we really should wait for Drupal 10. The more time we spend on D7, the longer migration will take.
Keeping this focussed on forum comments is best.
Since project browser is installed with Drupal CMS. We do need to get the Drupal.org API as final as possible. I fully expect there are more API changes we might want/need to make server side, since there wasn’t a real API design phase. Some of those API changes might be breaking changes. Once Drupal CMS 1.0 is released with project browser, we’re committed to no longer making breaking API changes. Finalizing the API has a good chance of also requiring changes to the project browser plugin API.
I can’t think of anything else. Looks like everything remaining under https://www.drupal.org/documentation/customization/snippets → can be deleted now?
hestenet → credited drumm → .
Go with the list in #3, the search queries likely aren’t changing that often.
Looks good to me
I was concerned about this hard-coding paths on Drupal.org, but this looks relatively safe. It will become a no-op as Drupal.org aligns to its modern infrastructure. It could use a bit more of a code comment explaining that.
thejimbirch → credited drumm → .
In the future, depending on infra, recipes could be managed in a monorepo
This does not depend on infrastructure. An example of a monorepo being subtree split out is https://git.drupalcode.org/project/drupal_cms/-/blob/8e5cc51cdc876e8004f...
Done, https://packagist.org/packages/drupal/cwo_demo will be available shortly
Add version data to send
Agreed closed issues need to be migrated.
Remove outdated lenient endpoint documentation
https://packages.drupal.org/lenient/ is now completely gone.
Deployed and closed comments on existing case studies.
The categories are now updated. It will take some time for these edits to make it into the API for project browser. If it is significant, we can either reopen this issue, or a followup issue.
I’ll go ahead and make this change.
packages.drupal.org/lenient will no longer be updated. Next the files will be backed up and removed, so it will be gone.
Deployed!
I edited the page to correct the markup. The whole table had been enclosed in another table, all in a single th tag. Links inside a table heading are styled for tablesort header links
Adding note that migration needs to happen.
The initial work in the MR now handles new issues being filed:
And the moved issue currently looks like this:
drumm → created an issue.
Not by design, we have an issue with events.
https://www.drupal.org/project/drupalorg/issues/3475098 ✨ Add a View of unpublished security advisories for security team members Active actually did this. Marking flxed for crediting the work done here.
With issues moving to GitLab, there are not standard components or the ability to add custom validation. GitLab does have confidential issues built in.
longwave → credited drumm → .
I misread the conversion here:
PHP Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/vendor/php-tuf/php-tuf/src/CanonicalJsonTrait.php on line 461.6MB is not a lot, especially when Drupal will require 64MB. Regardless, the php-tuf client will need to be better at detecting constrained memory situations, and keeping memory usage low. We do want to be judicious with memory use, since the hope is to expand TUF signing to the wider PHP ecosystem.
This is actually 1.6GB, which is already quite a high memory limit. Along with #21, it does look like the client seems to have a memory usage problem. So https://github.com/php-tuf/composer-integration/issues/127 is looking like the biggest blocker to getting this closer to core.
https://www.drupal.org/terms#accounts → might be the best explanation of shared accounts.
Dashes aren’t allowed in Drupal.org project names, so drupal-cms-project would not have worked. Since this is the command for composer create-project, the short name is ideal.
This will likely need to wait a few days as we are upgrading the VM that handles @drupal.org incoming email.
It will actually be easier to forward the messages. Is the volume of spam this address receives something that’s okay to forward to security@drupal.org? Otherwise, we could forward it to an @association.drupal.org Gmail account and have that do spam filtering and forward or auto-reply from there.
I asked for this issue to be opened under the infrastructure project. Micromanaging where it is isn’t necessary until implementation, either project is fine.
As far as I know, the reasons core committers are not using GitLab’s merge UI are the commit message format, which this hopefully solves, and https://gitlab.com/gitlab-org/gitlab/-/issues/26902
Ideally we set up GitLab’s merge UI to do the right thing by default, and discard the commit message drafting from Drupal.org. GitLab’s commit message templates are documented at https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates....
The next step is to set up a contrib project with a template containing %{co_authored_by} and %{reviewed_by}.
If that is workable, we can make it the default for new projects, and bulk update projects that haven’t set their own template.
It was not a float issue. It was that events with cover photos have their content squeezed into a readable width. This also squeezes the lists of people, which could really use the full width, which they now have.
Comments are now closed for topic in deprecated forums.
The test page I happened to try on dev, https://www.drupal.org/community/events/florida-drupalcamp-2025-2025-02-21 → , happens to have a float issue with the camp logo, making the entire page wider. That made me think this would be solved, but not yet.
This is deployed now. No one, including admins, can post to deprecated forums.
Is it possible to disable the "reply" link in the deprecated forums?
We can close comments to all nodes in deprecated forums.
This is done now
lists module currently protects posting to the old security advisories forum, and doesn’t actually interface with forums currently otherwise. So we can make this a generic set of forums that are closed.
We can make the columns wider for all the lists of people on events, many usernames are line wrapping, too.
Deleted Pages display incorrectly and pages under that. And I've also deleted Module/theme name collision.
As in those two should be kept (for now) and everything else deleted? Or the other way around?
Custom Tokens and its snippets can be migrated to module documentation.
Linkified Git log messages for drupalcode.org and Issue queues does have pre-GitLab URL formats. It could be adapted to be modernized, but it already is adapted from https://github.com/cowboy/dotfiles/commit/78fde838a, so I think it could be deleted.
skyejohnson & kyriazo - what was your PHP memory limit that you hit when you started, and how much did you raise it to succeed?
Putting my edits to address #7 back in the issue summary.
Opened a few issues to track what I mentioned in my last comment:
- Improve resilience of uploading building directories https://gitlab.com/drupal-infrastructure/package-signing/packagist-signe... this is an operational improvement. When a building directory is stuck, rugged continues as usual
- Improve handling of low-memory situations https://github.com/php-tuf/composer-integration/issues/127
- Improve error messages to show which HTTP request is the source of errors https://github.com/php-tuf/composer-integration/issues/128
- The fallback TTL of 1 hour was being used for TUF metadata at the CDN. It is now reduced to 10 minutes
I moved “To provide the root of trust for TUF verifications, download the initial root metadata for these two repos:” up in the issue summary, which should make the setup steps run more smoothly. While there are things to improve, we do need more real-world testing to see if the improvements have been effective, so setting back to needs review.
On the other hand, this kind of error can also persist longer. If re-running `composer update` show no change in the 'bin_c50-c53' part of the error message, this likely indicates that the TUF server has "stalled" during a metadata update. This will generally require intervention by a TUF server administrator. This is being addressed upstream in rugged/rugged#204: Add a monitor task to clean up stuck targets.
https://gitlab.com/drupal-infrastructure/package-signing/rugged-metrics now alerts us when targets are stuck, but it does require manual intervention to resolve. Once https://gitlab.com/rugged/rugged/-/issues/204 is deployed, this will be more automatic.
Most of the issues we have seen are actually directories stuck in the building phase, before Rugged is involved. There is also some chance of disruption on Tuesdays during the regular AWS maintenance window for the managed queue.
PHP Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/vendor/php-tuf/php-tuf/src/CanonicalJsonTrait.php on line 46
1.6MB is not a lot, especially when Drupal will require 64MB. Regardless, the php-tuf client will need to be better at detecting constrained memory situations, and keeping memory usage low. We do want to be judicious with memory use, since the hope is to expand TUF signing to the wider PHP ecosystem.
https://packagist-signed.drupalcode.org could not be fully loaded (Maximum allowed download size reached. Downloaded 1165080 of allowed 1165080 bytes), package information was loaded from the local cache and may be out of date
I think the Composer plugin client will need some error handling improved. This suggests something is amiss server-side, good chance cached at the CDN, but I don’t know what it might be. Running with -vvv might help point to which URL might be the issue.
Failing with "The 'bin_d9c-d9f' contents does not match hash 'sha256' specified in the 'snapshot' metadata." - for a while.
This looks like it is resolved now:
$ curl --silent https://packagist-signed.drupalcode.org/metadata/snapshot.json | grep -A2 bin_d9c-d9f
"bin_d9c-d9f.json": {
"hashes": {
"sha256": "bf9500067989a47152416e9dde6b7c059286657d080f2fd526949e462d5c0172",
$ curl --silent https://packagist-signed.drupalcode.org/metadata/bin_d9c-d9f.json | sha256sum
bf9500067989a47152416e9dde6b7c059286657d080f2fd526949e462d5c0172 -Right now we are permanently caching at the CDN and purging when changes happen. I’ve seen caching be enough of an issue that I think I will put a 5 or 10 minute lifetime on the cache at the CDN. So issues like this should self-heal after a few minutes.
The metadata in https://packages.drupal.org/8/packages.json has warning-versions:"<1.99"
I bet the ability to interpret that was added after Composer 2.4.2. Upgrading Composer should be a good solution for this.