NY, US
Account created on 17 July 2003, over 21 years ago
#

Merge Requests

More

Recent comments

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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

🇺🇸United States drumm NY, US

And just parent pages to be deleted can be listed, I have automated deleting trees of book pages.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

(Updating to fix Drupal.org issue indexing, please disregard.)

🇺🇸United States drumm NY, US

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

🇺🇸United States drumm NY, US

I recommend using composer audit, which will include advisories from Drupal.org, and elsewhere for your non-Drupal dependencies.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

The new API at https://www.drupal.org/jsonapi/node/project_module does have field_active_installs now

🇺🇸United States drumm NY, US
🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

Remove outdated site

🇺🇸United States drumm NY, US

Automated message: Drupal CI guide deleted. Moving its content one level up in the documentation hierarchy.

🇺🇸United States drumm NY, US

Automated message: Drupal CI guide deleted. Moving its content one level up in the documentation hierarchy.

🇺🇸United States drumm NY, US

Automated message: Drupal CI guide deleted. Moving its content one level up in the documentation hierarchy.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US
🇺🇸United States drumm NY, US

Those are now cleared from our CDN cache which was holding onto that content.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US
🇺🇸United States drumm NY, US
🇺🇸United States drumm NY, US

This fix is now deployed

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

Thanks, that helped me track down the actual regression at https://git.drupalcode.org/project/bluecheese/-/commit/2f52af5f2ed5a9dce...

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

For Hide usage info for general projects Active , I set only module & theme projects to show their usage statistics on the project page. I wasn't aware that some profiles or distributions had working usage statistics. We can add that back for distribution projects.

🇺🇸United States drumm NY, US

This is now fully caught up

🇺🇸United States drumm NY, US

Marking all Drupal-7-compatible releases unsupported for the D7 end of life has required all those release nodes to be reindexed. So the indexing has fallen behind. It is now accelerated to catch up.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

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.

🇺🇸United States drumm NY, US

🐛 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.

Production build 0.71.5 2024