Agreed closed issues need to be migrated.
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.
Projects with code are not deleted. I recommend updating the project to check:
- Unsupported
- Obsolete
- Add "Replaced by" for a structured note about the replacement
Yes, I think we can call this done. It looks like connections are initiating and being held open for a reasonable amount of time.
Drupal version isn't too relevant nowadays, the shifts between Drupal 9/10/11 are not like 5/6/7.
For modules used, we'll have to see how much this is actually used. I think in many cases, the people updating the case studies might not have all the technical details and leave it blank.
The 404 errors are now fixed.
larowlan → credited drumm → .
Done!
I believe this was intentional, since it is an “Issues for you” page. And as avpaderno said, the page will be removed as issues migrate to GitLab.
Anyway, @drumm could you delete all sections named something with D5 / D6 Migration archive? Maybe all of it is D5 / D6, but quicker to review when the obvious stuff is gone.
Done, and I’ve reviewed & completed the deletes requests in the child issues.
Viewing PHP settings using phpinfo() → I think we should keep this information. It is linked to from https://www.drupal.org/docs/getting-started/system-requirements/php-requ... → . We could either merge into that page, or migrate it to be a sibling of that page.
I’ve completed the deletions currently mentioned in the issue summary. Thanks!
I’ve deleted pages marked for deletion in the issue summary. I also went ahead removed “Views snippets” which was mostly Views 1 & 2.
I think for the rest of the snippets, we might want to identify & migrate anything worth keeping, then bulk delete what remains.
I completed the deletions from the issue summary, except for https://www.drupal.org/docs/7/modules/ultimate-cron → . That is already migrated, and I don’t have an automated process for recursively deleting a documentation guide. There’s a decent chance I’d manually delete the 30 pages, even though that is a bit much to not automate.
Will this break the links that any module/theme/distribution is using?
In general, migrations and page merges have added redirects as they go.
What will happen to the book outline for the pages?
I’ve been working towards tooling that can migrate with hierarchy, some notes are at #2762837: Migrate documentation into the new system → . Many of the sections for single modules/themes might be flattened to one page first. For example, https://www.drupal.org/node/402796 → could have its 2 child pages merged into itself.
Should there be a blog post to inform maintainers of the move and consequences?
We could probably use a general blog post highlighting the need for help triaging old book pages, and mentioning its progress toward upgrading Drupal.org.
As I completed #3442307: Decide what to do with 'Tutorials and site recipes' → I added 3 new capabilities:
- Removed the 30-book-page cap on bulk migrations. However, migrations via the UI still only migrate into child pages of a single guide. So this is actually only limited usefulness. https://git.drupalcode.org/project/drupalorg/-/commit/7a6290a27763e966fa...
- Added a drush command to flatten a tree of book pages into a single page. https://www.drupal.org/docs/7/howtos/book-drupal-7-the-essentials → had many chapters with ~15-25 tiny child pages. This command recursively merges the child pages into the parent page, adding h2/h3/etc headings for the titles, moving attached files to the parent, and adding redirects to replace the deleted pages. https://git.drupalcode.org/project/drupalorg/-/commits/7.x-3.x?ref_type=...
- Drafted a process for migrating a book page to be a guide. After a couple og_menu-related issues, this looks like it is working well. However, on next edit, the character limit for the guide’s description will be enforced; that’s probably why we didn’t build this before. This can be adapted to move a tree of book pages with hierarchy if needed.
The CDN configuration to passthrough websocket connections to our origin is now in place. The websocket requests now look like they are connecting successfully.
I fully expect more adjustments will be needed as we monitor.
I went ahead and added both. Please follow up here or a new issue if this wasn’t effective.
I remember now we added the query to disable these at https://git.drupalcode.org/project/infrastructure/-/blob/d130654e877dc4c... but GitLab has been failing to restore on staging the last few weeks, exiting before getting to that step.
In function cleanup, we can either also run that query and/or stop GitLab.
Updating credit
The preserved section of this book tree is now at https://www.drupal.org/docs/7/howtos/book-drupal-7-the-essentials → and the rest is deleted.
It looks like this is supported in GitLab, so would migrate okay.
Yes, this would be a global allowing this markup.
The commit I’ve pushed addresses the second part of #2, so places with WYSIWYG editing don’t remove the tags when they are allowed.
The default styles need to be checked before actually allowing this markup.
I’ll go ahead with the deletions.
Need to decide where exactly to migrate https://www.drupal.org/documentation/the-essentials-7 →
The text format was set to Full HTML instead of Filtered HTML, which is now corrected. That should fix this.
Correcting text format that was improperly set.
Correcting input format that was improperly set.
Some of the old Composer metadata had been cached. That is now cleared. You may still have local caches and need to use composer --no-cache …
alexpott → credited drumm → .
There is currently a backlog for Solr indexing. I have accelerated indexing to catch up.
Done, these will be available at Packagist.org shortly.
Documentation at https://www.drupal.org/docs/develop/using-composer/using-drupals-lenient... → has been updated
And the warning for CLI users is now:
Support will be REMOVED November 18, 2024! The Drupal lenient endpoint is DEPRECATED and does not support Drupal 10. Use mglaman/composer-drupal-lenient. See https://www.drupal.org/composer/lenient for more information.
A potential problem I see is that Drupal 9 requires PHP 7.3, while https://github.com/mglaman/composer-drupal-lenient requires PHP 8.1. So anyone with a Drupal 9 site running on PHP 7 will have more to upgrade. mglaman/composer-drupal-lenient does look like it supports Drupal 9 regardless.
That said, packages.drupal.org/lenient only supported Drupal 9, which is no longer supported. PHP 7 is not supported either. This has been deprecated for nearly 2 years, since #3327686: Update lenient facade warning for D10, suggest mglaman/composer-drupal-lenient → .
Let’s go ahead and set the date for this to November 18th to get ahead of the holidays.
Over 24 hours we got 820 requests for https://packages.drupal.org/lenient/packages.json, less than 0.3% of the 298k requests for packages.json files. They came from 111 unique IP addresses. 262 requests were from a single IP, which might be dependabot.
Usage is very low.
Deployed!
I think we can call this done now.
I missed a couple links in features/drupalorg_marketplace/drupalorg_marketplace.views_default.inc, which looks like all that remains.
The user search actually uses the core user search, which is not aware of fields.
For site admins with access to email addresses, we do add email search with customization. We could either do the same for first & last name fields. Or we could switch to the elastic search backend.
Is this sort order actually needed? What is the use case for it? Will many people use it?
These tabs no longer exist.
All of Drupal.org now has the new style.
drupalorg_crosssite no longer gets in the way of breadcrumbs.
This will be deployed along with the next deployment, likely in the next couple days.
drumm → made their first commit to this issue’s fork.
This looks like it was fixed.
We do not delete issue forks in this situation. I have deleted the branch and tag containing the accidental pushes. Housekeeping has run, so the commits should no longer be reachable with git clone --mirror
For future requests like this - please note the branch(es) and tags up front. Issue fork repositories are not deleted for accidental pushes.
Projects are generally not deleted from Drupal.org. https://www.drupal.org/project/ai_exceptionizer → is already marked unsupported & obsolete, which is great. I recommend also updating the project page to mention it is replaced by the similar module.
If you'd like to completely abandon the project, you can click Leave project at https://git.drupalcode.org/project/ai_exceptionizer under the three-dot menu at the top-right of the page.
Yes, this is works as designed, the steps to reproduce are part of the problem/motivation.
Modules like drupal/token are distributed via the https://packages.drupal.org/8 Composer repository using Composer 2. They are not on Packagist.org.
I'll ask this more explicitly - are you trying to make a module named ai_exceptionizer?
Can gitlab be made aware of the node ID of the project
GitLab does not have that sort of customization, nothing like Drupal’s fields or modules. So it is up to Drupal.org to do the redirecting.