I see where our CDN cache was holding onto the old version now, should be actually resolved now.
I’m unable to reproduce this, clicking “Drupal 7 End of Life resources page” goes to https://www.drupal.org/about/drupal-7/d7eol/migration-resource-center/en... →
Documentation for this is started at https://www.drupal.org/drupal-security-team/security-team-procedures/sec... →
Remaining work:
- Set up the GitLab triage bot in a git.drupalcode.org repository with GitLab CI running the schedule, either using a new branch of https://www.drupal.org/project/securitydrupalorg → or a fresh project
- More documentation, including how to publish a security issue, and triage duty
- Test with security team members
- Complete 📌 Move security advisory drafting to www.drupal.org Active to allow project maintainers access to draft security issues
- Make the https://git.drupalcode.org/security/issues/-/issues project public, so anyone can report issues
- Migrate all security.drupal.org issues
I believe this is local caching. Please try composer show drupal/drupal_cms_geo_images -a --no-cache
The full output of composer show might show more clues that your composer is still using packages.drupal.org data instead of switching to packagist.org.
Did anyone open a feature request in gitlab to have a concept of a "security" role for users to be able to access all security issues?
No, that didn’t happen. GitLab has only recently added custom admin roles, https://docs.gitlab.com/user/custom_roles/#custom-admin-roles, which might get us partway there.
Security issues will need private forks regardless, so private MRs can be used for review and testing. Putting those private forks under https://git.drupalcode.org/security takes care of giving the security team access, and the group labels, milestones, etc keep everything organized the same way. Even if there was a good way to give security team members access to all confidential issues, that is only partway there.
https://www.drupal.org/docs/administering-a-drupal-site/security-in-drupal → is probably the destination for the pages in Securing your site that might be kept.
I should update https://www.drupal.org/drupal-security-team → to link to the new documentation
greggles → credited drumm → .
Clarify only security team members can manage access
This is currently using the timestamp on the packaged file for download at https://git.drupalcode.org/project/drupalorg/-/blob/fb5a4efc1f03d10dae32...
We could change that to the release node creation time, or edit “Released” to be more accurate
Done, https://packagist.org/packages/drupal/drupal_cms_geo_images will be available soon.
Note: Unfortunately I couldn't find any official guideline that instructs a Drupal Recipe should be created as a "General project". Is it something out there on this?
We should get this documented. Where did you look for the documentation?
I was reading this as a choice instead of a checklist:
☐ Delete
☐ Redirect
Some of these are now handled.
For Securing your site → , I think we need to go page-by-page. I think these pages in particular have links from elsewhere on the site. Each child page might be:
- Deleted if not relevant today
- Deleted and replaced with a redirect if duplicate documentation already exists
- Migrated using the “migrate this documentation” link on each page
Removing unnecessary header. Could use modernization, such as replacing FTP
Deletions done according to the issue summary.
I missed this issue before, I can take care of the deletions in the issue summary.
Actually #3442232: Decide what to do with TO BE MIGRATED → looks like it has specific details for this book.
And, you can't actually do it until someone at the DA activates some feature on the site that allows for migrations to happen.
This was done some time ago, so migrations can be done by following the “migrate this documentation” link on each page.
I’m also happy to do some bulk actions:
- Delete a tree of book pages - only the top-level parent is needed
- Flatten a tree of book pages into a single page - for example if we wanted to merge the 3 pages under https://www.drupal.org/node/125539 → into a single page
- Anything else that seems like a lot of busywork might be a candidate for automation
Thanks!
Thanks!
Thanks!
Thanks!
wylbur - you should have seen a warning block at the top of book pages with
This documentation needs to be migrated into the new documentation system. If you are a project maintainer, create a new documentation guide for your project first and then migrate this documentation.
If you don't have that, let me know and I’ll double check access to that. Using the links in that block migrates the pages in-place, preserving authorship and revisions, and the old pages are moved, so no additional deletion is needed. This also removes the need to add any redirects or other affordances for URLs changing.
For the theme documentation, we’ll have to continue as-is, it isn’t worth the time to do additional cleanup. I’ll delete the book pages and resolve the issues.
Please do not migrate module documentation, except for special cases and identifying pages to delete. The migration process is cumbersome for more than a handful of pages, or anything with some hierarchy. I don’t want people spending time on busywork that should be automated. A special case might be something like - a module has new documentation and the book pages are being migrated into the module’s existing new documentation section.
Much of this is ready to test, but could use some documentation. Examples of it in action are at:
https://git.drupalcode.org/security/1-drupalorg-security/-/issues/1
https://git.drupalcode.org/security/2-drupalorg-security/-/issues/1
The remaining work on D7 is now to update permissions so project maintainers can create & update drafts, including various field permissions to limit some field to the security team members only.
Remaining work:
On D10 - add a prompt to draft a security advisory to the comment posted on security issue posting
D7 - update permissions so security team members can create & update drafts
This may already be updated for upcoming versions, see ✨ Replace the launcher script with better documentation Active
The Drupal CMS documentation is currently canonically at https://git.drupalcode.org/project/drupal_cms/-/tree/1.x/docs?ref_type=h... and then copied over to new.drupal.org
Events will likely be the next thing to be turned off on groups.drupal.org since we built https://www.drupal.org/community/events → to replace it
We’ll want to port the “How to improve this page” block from documentation pages like https://www.drupal.org/docs/getting-started/system-requirements/web-serv... →
First we should port it without functionality changes, so regular documentation pages will be set up correctly. Drupal CMS documentation is an exception, so after the basics are done, adjustments should be made. For example, there will not be general edit or commenting (discuss) access for these pages.
Some notes from when I’ve discussed this before:
The D7 version has Discuss, which is regular node comments moved to a separate local task page, which we'll want for regular documentation. For the CMS documentation section & pages, we'll want to make sure comments are off and this block has logic to detect that. We're somewhat building this backwards since the CMS documentation's special cases should be built on top of the base documentation functionality, which we should keep mostly as-is.
I hadn't looked into how this was done in D7 yet, that we might want to change. Its a View, with a field formatter for all the text https://git.drupalcode.org/project/drupalorg/-/blob/089409007720bc9009d6...
So changing the text based on logged in status, edit access, comment status, doesn't happen. We could put in some all-or-nothing checks with Views filters or block visibility rules, but anything with different versions of the text would get messy in Views.
The equivalent on D7, https://www.drupal.org/docs/user_guide/en/index.html → is imported, looks like it has the block hidden when there's a field set that indicates it was imported. And there's a different block that shows in the footer.
I'm thinking it would be best to have this all in one block, so it gets placed once, consistently. We can get as far as possible with logic in custom code, that works for normal documentation pages. If we need something additionally special for the CMS guide, we can add logic to check for the page being in that guide.
Thanks! These have been deleted.
This is deployed now
We should update the logo size used here to the 2x version, so it is less blurry on high-pixel-density displays, and add the name since not all logos have readable names, and the other reasons you mentioned.
I’ve approved the group. Please note that groups.drupal.org is on life support, since we have not found the time to prioritize replacing it. We’ll aim to replace what is practical, but its functionality might be more-heavily deprecated or removed in the future. Collaborating in other spaces is encouraged.
I can go ahead and remove the version filtering altogether here, the remaining D7 issues mostly won’t be at the top of listings anyway.
Has this happened recently? The core bug that caused 🐛 Prevent flooding of feeds such as Drupal Planet with old blog posts Closed: duplicate was fixed long ago.
The API Composer uses for security advisories is described at https://packagist.org/apidoc#list-security-advisories if you need to implement it outside of using Composer. Drupal.org packages are installed via packages.drupal.org, so the API endpoint is for example https://packages.drupal.org/8/security-advisories/?packages[]=drupal/core
The APIs used by Composer also have additional metadata, for example https://packages.drupal.org/files/packages/8/p2/drupal/token.json.
Update status used by Drupal is backed by API requests like https://updates.drupal.org/release-history/token/current
These deletes are done, thanks!
These deletes are done, thanks!
And just parent pages to be deleted can be listed, I have automated deleting trees of book pages.
For module documentation, I can go ahead and bulk migrate the remaining documentation as-is. It still could use attention from project maintainers, but we don’t need to have everyone spend time on repetitive migrations. I may do the same for module & theme documentation.
(Updating to fix Drupal.org issue indexing, please disregard.)
benjifisher → credited drumm → .
Advisories on www.drupal.org now allow filling reported/fixed/coordinated with a list of usernames. The Update button does the translation to HTML so it won’t update the HTML unless you proactively want to update it
I recommend using composer audit, which will include advisories from Drupal.org, and elsewhere for your non-Drupal dependencies.
The formatting does look very consistent, so we could convert this to more structured data. The exception I spotted was when we were doing combined advisories like https://www.drupal.org/sa-core-2018-001 → , but that is not too common. The structured data would still need (person, reported|fixed|coordinated, ”of the Drupal security team”); the last value could be a string and add the extra context.
That said, I think I’d like to keep the text field for now and add affordances for filling it out consistently. Converting to structured data would be more time-consuming buildout right now and a migration. That can be done later.
This is now complete.
Release pages like https://www.drupal.org/project/google_tag/releases/2.0.8 → now have a list of security advisories added, so the advisory ID does not need to be known ahead of time for release notes.
The advisory ID behaves as described in the issue summary.
This is deployed now
The new API at
https://www.drupal.org/jsonapi/node/project_module →
does have field_active_installs now
Since the project does not have any code pushed to it, and was created very recently, it is possible to delete. That is now done.
Can you include a bit more context, ideally the full console output? What I was understanding in https://github.com/php-tuf/composer-integration/issues/128 was that the specific files weren’t mentioned in the error message. HTTP requests happen in parallel, so I don’t think the line above the error message is necessarily the cause, which would also explain why it appears to be switching.
https://git.drupalcode.org/project/api/-/blob/7.x-2.x/api.update_branch.... looks like where files were removed in D7. Looks like the general flow was:
- Make a list of current files
- Make a list of previously-parsed files
- When processing current files, remove them from the list of previously-parsed files
- Remove anything left in previously-parsed files, starting with removing the items parsed from them
I’d do that again, or possible solution #1
Good find, even though browser support isn’t great yet.
The same copy widget is also used on issue pages for Git command drafting and other places, and white-space: nowrap; would not be great in all situations.
Where this gets tricky is you probably want to fetch changes. How you do that depends on what you have locally, what is upstream, and the preferred Git workflow for the project. We don’t want to get into providing suggestions for every situation, that is for documentation and learning Git. I think the most I’d want to suggest is git fetch {issue fork remote}. Anything additional would become too much UI trying to fit in a small space - the next step might be git reset … if I know I don’t have anything local, git rebase … if I do have local changes, or git merge … if that’s better for a specific project or situation. Maybe we’d want to add a note about remembering to get upstream changes into your local branch.
For me, since the command is simply git checkout {branch}, I always type it out using shell tab-completion or copying the branch name from the issue or MR page.
hestenet → credited drumm → .
surabhi-gokte → credited drumm → .
This is working as designed to disambiguate components in modules, since Composer resolves dependencies on the project level, and Drupal also handles dependencies among sub-modules and other components within a single project. Composer namespaces do not always equal project names.
Using the Composer command exactly as on the release and project page, composer require 'drupal/matomo_onpage_metrics-matomo_onpage_metrics:^1.0@beta' does work as expected.
This is likely due to migrations on the new.drupal.org site, which is still very much unstable. They should be resolved next week, although data for this field may take some time to migrate again.
field_supporting_organizations is a paragraph field and the paragraphs migration got jumbled enough to justify deleting all data for the field and starting a fresh migration.
The Drupal.org APIs that project browser uses should still be considered unstable. There was a plan to mitigate this and improve error handling in project browser, but that apparently didn't happen.
I haven't found an issue to improve the error handling around Drupal.org responses that should have been opened. Drupal.org will make breaking changes to the API over time, and 4xx errors should be handled better. The usual recommendation will be to upgrade project browser, although in this case it is likely an unplanned API change.
✨ Display warnings/errors from DrupalOrgJsonApi backend Active was done, so we can set up that warning soon.
Automated message: Drupal CI guide deleted. Moving its content one level up in the documentation hierarchy.
Automated message: Drupal CI guide deleted. Moving its content one level up in the documentation hierarchy.
Automated message: Drupal CI guide deleted. Moving its content one level up in the documentation hierarchy.
Drupal.org does not track Git repository contents, we don’t have a quick way to programmatically know if a project has code or not. Some community projects use their Git repository for charters or other information, so a project having “code” is not necessarily a great check. Adding the ability to make projects without repositories would be extra work for little useful functionality and more edge cases.
I guess the fastest way is to opt-in into the advisory, even though there might never be a single line of code or stable release being tagged which would enlist it as covered.
This is the best way for these projects to move forward.
benjifisher → credited drumm → .
Those are now cleared from our CDN cache which was holding onto that content.
Yes, I think we can call this done.
I hope there’s more testing with 📌 Manually test TUF-enabled Composer projects Active before this is made generally available out of the box with Drupal core. But that and the rugged followups are all being tracked in their own issues.
Done, https://packagist.org/packages/drupal/artifact_deployment will be available shortly
That's now done
This fix is now deployed
This is now deployed and I rebuilt the XML for https://www.drupal.org/project/entityreference_dragdrop →
Before rebuilding the XML for every project with an & in its title, I'd appreciate a final confirmation that this is looking good in Drupal core now.
This is now deployed
Thanks, that helped me track down the actual regression at https://git.drupalcode.org/project/bluecheese/-/commit/2f52af5f2ed5a9dce...
Thanks for the research!
I don't understand the "BC" concern here. The primary client for these feeds, update.module, was written to assume properly encoded markup in the XML feeds, and is now "broken" by the double encoding. If other clients are already decoding twice, and we stop double encoding, what's the harm?
My only real concern is if core was ever double-decoding. And I hope every version of core does always filter on output, so this should be fine.
Looks good to me