The warning on edit is now deployed.
It didn’t cross my mind before that we could theoretically fix the display somewhere in custom field formatting, without the underlying date module bug being fixed. Assuming enough time zone information is stored consistently.
I’ve deployed that fix and repackaged all 11.2.* releases. I believe that the downloads should be good now. And the additional error handling should show this type of problem earlier next time.
Please follow 📌 Remove drupal/legacy-project as a starting point for Drupal 10 Needs work and related issues for future changes to supported file layouts (recommended-project vs legacy-project) and packaging. The downloadable packages are generated with Composer, so you can use them as a starting point and get modules and other dependencies with Composer, but it is best to use Composer from the start, so you are familiar with it.
Looks like this was simply running on a too-old version of PHP. I am updating that, and adding exception handling if composer create-project fails.
This is likely a drupalorg or infrastructure issue for packaging. I’ll leave the issue here for findability, and move once closer to a fix.
I think we do want to keep the tarball packaging in some form, it is somewhat of an end-to-end test of the subtree splits and project templates working correctly, and is one of the faster packaging steps.
As far as I can tell, the subtree splits and templates look good for now.
Tarball packaging would switch to recommended-project to support 📌 Remove drupal/legacy-project as a starting point for Drupal 10 Needs work , and removing / deprecating them will hopefully be more coordinated than them not being packaged correctly.
When issues move to GitLab, https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... → will be replaced by GitLab’s label listing like https://gitlab.com/gitlab-org/gitlab/-/labels. So we don’t want to spend time rearranging something that will go away.
Deleting tags is highly destructive and removes the history of when a tag was added or removed from any issue. It should happen only for spam and things like briefly-used misspellings. Unfortunately, I have seen tags that must have been over-aggressively been deleted by site moderators, but it hasn’t been bad enough for me to spend time investigating. If something is approaching a code of conduct issue, or just plain unwelcoming, that could be a good reason to delete it.
Tags can be renamed, which might be another option. Something like “(historical)” or some other convention could be used when the description is useful for additional context. For example, “VDC” will always need explanation.
I also recommend removing descriptions, like from the PHP version tags.
GitLab pages will not be indexed in the Drupal.org site search, so there will be some loss of findability, but we probably will want to de-emphasize the site search anyway, as some important projects are on GitLab pages already.
The unique thing API module could do, and does for .txt files, is auto-link references to classes/functions/etc like any docblock comment. For example https://api.drupal.org/api/drupal/core%21INSTALL.txt/11.x has links to other files. That is not used much, so I’m sure serious use would find improvements to be made (URLs aren’t auto linked, but would be less-relevant for markdown) in addition to adding markdown parsing.
That said, I think it is all good to go ahead with GitLab pages. There should be some plan to completely replace and delete documentation like https://www.drupal.org/docs/8/api/cache-api/cache-api → , so we try to avoid the usual problem of good documentation initiatives accumulating into just more versions of more documentation to be disorganized.
I suspect the current design was intentional so that the page was not overwhelming.
You can actually filter the Drafts tab by published status: https://www.drupal.org/list-changes/drupal/drafts?keywords_description=&... → and get to what you are looking for.
We are monitoring for known causes of integrity issues, such as queues not being processed promptly. Verifying the entire repository would probably take multiple days and have little practical benefit for spotting issues which I suspect are only present for a few minutes at a time.
Can we go ahead and delete the www.drupal.org pages right away, as redirects are added?
What is the URL you are seeing this on?
Makes sense to me
I don’t see git@git.drupalcode.org mentioned on that page either.
Regardless, this is not something we can change, git.drupalcode.org is fronted by a CDN, which forwards HTTP connections, not SSH. So swapping the protocol used without getting the full documented Git remote URI will not work.
This is deployed now, and organization ranking has been recalculated.
Both https://packagist-signed.drupalcode.org and https://packages.drupal.org/8 should be in composer.json with "tuf": true
https://packages.drupal.org/8 only includes contrib modules and themes from Drupal.org. The rest of Drupal, including core, is distributed via Packagist.org, which does not have code signing. packagist-signed.drupalcode.org mirrors packagist.org, so core and the TUF library are signed.
https://packagist-signed.drupalcode.org/metadata/3.root.json is by design, that will only exist when the root metadata is refreshed for a 3rd time.
I keep hitting https://packages.drupal.org/8 could not be fully loaded (Maximum allowed download size reached. Content-length header indicates 7240 bytes. Allowed 1024 bytes), package information was loaded from the local cache and may be out of date
Until https://github.com/php-tuf/composer-integration/issues/128 is resolved, I have basically no capability to help with issues like this. I need to know which HTTP request is causing the problem.
Where did you see instructions to use git@git.drupalcode.org?
That is not listed as a remote URI on pages like https://git.drupalcode.org/project/drupal or on https://www.drupal.org/project/drupal/git-instructions → and is not a domain that accepts SSH connections.
Screenshot of the addition to the Owner tools page for each organization.
Issue originally raised by xjm in Slack.
drumm → created an issue. See original summary → .
We did recently refresh the root metadata ahead of the expiration later this month for both:
- https://packages.drupal.org/8/metadata/2.root.json
- https://packagist-signed.drupalcode.org/metadata/2.root.json
I would expect the client to fetch and use this automatically. If we refreshed and rotated keys in the root metadata as a result of a compromise, I would think the client should automatically start using the new metadata, which has a chain of trust back to 1.root.json. This should be checked against the TUF spec.
This will need some debugging to figure out where the root cause is.
Confirmed that made it through to https://github.com/drupal/recommended-project & https://github.com/drupal/legacy-project
That also means we could add a README.md to each, so anyone who lands on the GitHub repo has some explanation.
benjifisher → credited drumm → .
A dev dependency is a good idea.
This looks like its working well in dev.
This is probably the right version.
📌 Check “view unpublished [specific content type]” access in Views listings Active will probably take care of this post-upgrade.
drumm → created an issue.
These nodes are actually now all deleted with 📌 Dismantle code which supported drush make distribution packaging Fixed
Issue are migrating to GitLab, ✨ Move issues from www.drupal.org to git.drupalcode.org Postponed , so we aren’t adding features to the existing issues. GitLab does support videos, https://docs.gitlab.com/user/markdown/#videos. You can already upload a video to a merge request to see how it works.
I think at this point we would like to move https://www.drupal.org/project/localgov → from "Distributions" to "General projects" to support straightforward composer require.
That’s now done and https://packagist.org/packages/drupal/localgov is now available.
2. Is it important to make the .info file and composer.json to have the same dependencies? (It seems that drupal.org packaging adds things it finds in the .info file).
Yes, it is very important that dependencies are in composer.json. That is the only source of dependency management for general projects. Those are published straight to Packagist.org, which has no idea what an info file might be. It is a good idea to keep them in sync for modules & themes too.
I think that might have everything in this issue answered
✨ Attach Drupal CMS custom-packaged .tar.gz files Active is now done and confirmed localize.drupal.org is able to parse cms releases.
This is complete and localize.drupal.org has parsed the missing releases, which I manually repackaged into a tgz files.
This is now deployed: https://www.drupal.org/project/drupal →
The short descriptions can be updated by core release managers.
For review:
This should now be allowed.
(Correcting text format)
phenaproxima → credited drumm → .
phenaproxima → credited drumm → .
https://www.drupal.org/about/drupal-7/d7eol/partners → lists the current policy.
We have a notice like that for D7 documentation already. For example: https://www.drupal.org/docs/7/understanding-drupal →
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → is more of a lost & found of potentially-unmaintained documentation that could still use triage. For example, https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → has a supported version compatible with Drupal 11, and that documentation has a good chance of being relatively current.
The only thing needed to close out this issue is triaging the orphaned book pages at https://www.drupal.org/node/3522465 →
Agreed we should keep the short descriptions for all, and make them more concise & accurate. If some descriptions really shouldn’t be there, should be able to edit the release to remove them. Some explanation for showing older versions makes sense to me.
Search indexing has now caught up again.
Mixing the subtree split & other derivative repositories into GitHub is not a good idea for access management long-term. Everything working the same way will be much better to manage.
(If we had general projects ready for when core required subtree splits, we would not have used GitHub.)
As part of #3048700: Discontinue groups.drupal.org → we removed multi-site searching from Drupal.org. This caused all content on www.drupal.org to be marked for reindexing. We’ve accelerated that reindexing and it should complete within the next 2 days.
We can continue putting redirects in by hand. Where should the two pages you linked go to?
We do keep records of deleted nodes, but now is not a good time to engineer new functionality as we’re migrating the site. That is something we could build once documentation is fully migrated, if the search for the previous page title is tested and shown to be useful.
This is all done, tested, and I’ve updated https://www.drupal.org/drupal-security-team/security-team-procedures/sec... →
Updating link for https://www.drupal.org/project/drupalorg/issues/3528485 📌 Move GitLab security issue triage project to hide issue counts Active
Yes, the labels filter is hiding in the left sidebar, at the bottom.
I did a quick pass through the orphaned book pages ( https://www.drupal.org/node/3522465 → ) and deleted a couple of pages for themes that didn’t have D7 or later versions.
The can be deleted but I don't have edit accees, the bitcahce project is unsupported.
And those have been deleted too, thanks!
What about the pages for modules that do not have a stable D7 release?
I think we have to keep those for now, there will be plenty of people with D7 sites that they need to figure out, and documentation has potential to help.
benjifisher → credited drumm → .
Even if this feature was present in GitLab, it is always best to keep patches locally
MR.patch URLs should never be used by composer patches. The upcoming 2.x version https://github.com/cweagans/composer-patches has some protections built-in, including https://github.com/cweagans/composer-patches/issues/347. The best way to help is to look into blockers for the 2.0.0 release of composer-patches, and help move those forward. Until then, you might consider setting up CI to flag improper composer-patches use in your projects.
Even if this were a GitLab feature, local copies of patches still eliminate the possibility of the remote URL becoming unavailable, changing, or causing other chaos. And you have a definite record of what your codebase was patched with. For example, we may need to clean up stale forks for closed issues in the future, that could affect the MRs from those forks. Indefinite MR patch hosting is not a service we can promise to provide.
Done and https://packagist.org/packages/drupal/settingsphp will be available in a few minutes.
The missing statuses are filled out now:
- Reviewed & tested by the community → Security status::reviewed & tested
- Ready for SA to be Published → Security status::ready to be published
- Postponed → Security status::postponed
- Closed (duplicate) → Closed::duplicate
- Closed (won't fix) → Closed::invalid, potentially might be other statuses
And what I mentioned in #5 is done by https://git.drupalcode.org/project/drupalorg/-/commit/109256299611a258d8... & https://git.drupalcode.org/security/triage/-/commit/cc6e081e6ab08d16f49b...
So I think everything we’ve thought of has been followed up on.
This was deployed and organization rank has recalculated.
Reported via Slack
This is now running in staging for verification.
Closed (duplicate) - We can link another issues in Gitlab, but there are only three options: relates to, blocks, is blocked by. If it will be sufficient to mark it as "relates to" and close it with a comment that it is a duplicate, then we probably do not need this label.
Closed (won't fix) - Not sure how to label such issues. Probably need to add this?
We should add both of these, I imagine they will be useful for retrospectives.
Reviewed & tested by the community - I think that we discussed to use milestones to schedule releases. So adding an issue to a milestone can be probably considered as RTBC?
I think we do want to add a label, that can have an automated response to tell everyone the next steps. That will be a bit better UI, labels are easier to remember and look for, and there is sometimes negotiation around which Wednesday a maintainer wants, or the team coordinating with something else. We could have the automation follow up if a ready issue is not assigned a milestone within a certain amount of time.
Ready for SA to be Published - We used this status when maintainers actually committed the fix and created release. Can this be automated somehow, so that we are notified about new private releases in the Gitlab issue? If so, then web probably do not need this?
📌 Update automated messages in Security Team's Gitlab Active did automate this, https://git.drupalcode.org/project/drupalorg/-/commit/47f37bb9 is the message added. It does not currently add a label. It was not working for the one_time_password issues since the advisories weren’t drafted starting from the GitLab issue, so there was no link from the advisory to the issue.
Ready for SA to be published also needs the advisory to be drafted. I think what I’ll add is:
- When a release is made, also add a label that the security release is done
- Add a “Ready to publish” label (trying to keep labels as concise as they can be)
- When an issue has both release done & advisory drafted, automatically add ready to publish. There isn’t a security team member has approved the SA draft state, but I think that’s fine to leave loose, as it will get a final review on security release Wednesday
We can add additional daily notifications leading up to the scheduled security release date, if either tag is missing. Those can be drafted in 📌 Update automated messages in Security Team's Gitlab Active or a separate followup
The create event permission should be restored now. There was a second role that I thought was redundant and outdated, but apparently it is the one that matters. And role syncing from www.drupal.org might not be working properly. So the site is indeed in bad condition and a liability to keep running.
https://new.drupal.org/browse/recipes is now available. ✨ Add tracking for when recipes from Drupal.org are applied Active must be taken on by someone if we want the page to be useful. Until that is done, this will be sorted alphabetically, and might not get much more prioritization.
This almost certainly is caused by OG menu module loading all menus for all documentation guides.
access to create new events on groups.drupal.org is no longer available.
This has been turned back on, not having email notifications for group members is a regression a few people contacted us about. And is not something we can practically implement on https://www.drupal.org/community/events/ → for now. We both don’t want to build new functionality on D7, where community events are now, and there isn’t the same group system for subscribing to a specific location/meetup.
benjifisher → credited drumm → .
Maybe instead of porting, we could just add the Event content type and functionality to d.o. main, then ?
That was done: https://www.drupal.org/community/events/ → and as of today, access to create new events on groups.drupal.org is no longer available.
We have also replaced Solr-powered search with Drupal core’s default search. We are migrating and upgrading Solr servers and can no longer support indexing groups since the compatibility issues are not worth trying to solve.
GitLab is a product and not customizable like Drupal is. This sort of UI change/layer isn’t something we could reasonably implement and maintain. This would be feature requests for https://gitlab.com/gitlab-org/gitlab/-/issues
Hover over a line of code inverts the line for easier readibility (also could be a preference)
This one might be more doable standalone issue for GitLab. There are already preferences around syntax highlighting and diff colors at https://git.drupalcode.org/-/profile/preferences. And there are already some hover effects on the line numbers for merge request diffs. I briefly searched for related issues and found https://gitlab.com/gitlab-org/gitlab/-/issues/300469
Somewhere on the top right corner you have a button to reveal comment threads: one button to show and unfurl the first and one button to unfurl all.
I briefly looked for an existing issue for this one too, I did not find one. There is a “Hide all comments” option in one of the three-dot menus, so it might be doable for GitLab to add “Show all comments” next to that.
As the Drupal community, there isn’t a lot more we can do to influence GitLab’s development other than opening good issues for their product. They do have good contributor onboarding, so its doable to contribute code to them, with the huge caveats that its a huge project and changes take care, and its mostly Ruby code.
There have been significant memory usage improvements which need review linked from https://github.com/php-tuf/composer-integration/issues/127. Those could help the runtime as well.
Most often I think I see the tag not being “on the branch.” The Git history can be completely arbitrary. Actually detecting this would require some walking through the commit graph since there is a valid edge case for some security releases:
- Development on the branch has moved on, there are many commits since the last tagged release. A security release is needed and the maintainer wants to make a release with minimal changes from the last tagged release.
- This effectively will be a branch made from the last tagged release or even a few commits after. (There doesn’t need to be a branch, tags don’t require branches.)
- So in this case we’d be looking at the history of the branch and tag, looking for a common ancestor that is “reasonable.” That will require some careful logic, every Git commit pair in a repository has a common ancestor, usually.
You can see the project is migrated at https://www.drupal.org/jsonapi/node/project_module?filter[field_project_... →
How project browser is setting up filters for querying might be filtering out the project for some reason.
This is all done now.
hestenet → credited drumm → .
Done!
I’ve started work on the next phase here - configuration updates to get general projects indexed.
The orphaned pages are now at https://www.drupal.org/node/3522465 →
I took a first pass through deleting placeholders, obvious D6 & earlier, and a couple terrible security ideas. 101 pages remain
This is now deployed so https://www.drupal.org/list-changes/drupal/drafts?field_change_record_st... → lists all published change records with their issue.
- Downloading drupal/core-project-message (11.x-dev 656efa0)
Failed to download drupal/core-project-message from dist: Maximum allowed download size reached. Content-length header indicates 10666 bytes. Allowed 10658 bytes
This is now fixed. I had put in logic that only signed each zip file once. The dev version zip archives have the Git commit ID in their name and change when a new commit is added. However, the target name drupal/core-project-message/11.9999999.9999999.9999999-dev isn’t changing and what is actually checked. The fix was https://gitlab.com/drupal-infrastructure/package-signing/packagist-signe... and https://gitlab.com/drupal-infrastructure/package-signing/packagist-signe...
benjifisher → credited drumm → .
The project is now a theme
We do not delete and recreate in this case. It can be changed to a theme.
- Downloading drupal/core-project-message (11.x-dev 656efa0)
Failed to download drupal/core-project-message from dist: Maximum allowed download size reached. Content-length header indicates 10666 bytes. Allowed 10658 bytesThis is a server-side issue. https://packagist-signed.drupalcode.org/metadata/bin_094-097.json says
"drupal/core-project-message/11.9999999.9999999.9999999-dev": {
"hashes": {
"sha256": "78163df67a5207b9b0ba0ede7ff2652396f5c66ee9d6ce5f137db24d4242bd6e"
},
"length": 10657
},But https://packagist-signed.drupalcode.org/dist/drupal/core-project-message... is a different file. It was last updated Feb 3, which is around when I was shoring things up, so it's hard to say if it was a systematic issue or debris from something that was fixed. I'll look at getting that re-signed.
TUF is signing a target named drupal/core-project-message/11.9999999.9999999.9999999-dev and presumably it has a previous version of that file. For packagist-signed, dev zipballs do change location with every commit, the commit hash is in the filename. I wonder if there’s some way to use this for better error messaging or working around issues.
Now that all books have been triaged in child issues, we are left with 123 orphaned book pages. There’s some gems like https://www.drupal.org/teapot → that should have a place to land, and others that can be deleted.
The comparison of modules is now at https://www.drupal.org/docs/7/extend/comparison-of-contributed-modules →
The remaining module documentation is now at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → where it can continue to be pruned, improved, moved, or left until the next major reorganization
Thanks everyone!