Plan for new Pathologic releases

Two quick roadmapping/planning thoughts!

1. We've started adding multilingual test coverage in 🐛 8.x-1.0-alpha3 breaks images in multi-language sites. Fixed . That test coverage should probably be in place before we sort out 🐛 Internal URL handling (language prefixes, base://, ...) Needs work , and maybe 📌 Convert tests/src/Functional/PathologicTest.php to a Kernel test Fixed should be done before that, in case conclude that we can include multilingual test coverage in the Kernel test.
2. We could stet a target date for putting out 2.0.0-alpha1 (which would include jsut the D10 compatibility work already merged into 2.x) so that folks waiting on that to land for Drupal 10 updates can plan better.

Great questions, thanks!

1. Yes, those all seem like the top priorities to me. My preference would be to improve the tests before we do much else. 😅
2. Sounds good. The big question is should we already revert ✨ Convert href to the aliased url if possible Needs work or not before we tag alpha1. Maybe 2.0.0-alpha1 that's exactly as broken on multilingual as 8.x-1.0-alpha3 is better than waiting for the dust to settle on all the issues in point 1? But part of me wants to fix point 1 before we make any more releases at all...

Meanwhile, there are currently only 7 open bugs for 8.x-1.x and 2.0.x → , and one of them is postponed on getting more info from the reporter. Two of those are from point 1. That leaves only 4 real open (modern) bugs that we know of:

• 🐛 Dynamic routes in image styles break under pathologic Needs work (which is basically duplicate with 🐛 Internal URL handling (language prefixes, base://, ...) Needs work -- it's trying to only solve a subset of the problem)
• 🐛 Internal URL handling (language prefixes, base://, ...) Needs work
• #2781783: Pathologic breaks form embed →
• #2846270: Path processing just runs on URLs which are registered in Drupal already →

It's possible there are some real bugs still lurking in the 7.x queue, but I haven't spent any time trying to triage all that.

Haven't started triaging 8.x/2.0.x task issues, but that's next on my list for this roadmap...

Taking a look at tasks...

These are the ones I care about:

• 📌 Convert tests/src/Functional/PathologicTest.php to a Kernel test Fixed
• 📌 Remove usage of "whitelist", use better terms instead Fixed (both on principle, and because there's a settings update that needs to happen so it's kinda an "API change")

Then we've got a few that mostly seem like busy-work issue credit farming (a bunch of different users all "contributing" 1 patch, usually insufficient, and then disappearing):

• 📌 Fix coding standards violations Needs work
• #3315947: Replace README.txt with README.md →
• 📌 Implement hook_help() RTBC
• 📌 Don't use t() within classes Fixed

It would be nice to have phpcs happy and reporting no errors, but IMHO not worth holding up releases over any of these...

- - - End of Triage - - - 😉

So, I think the next step is to update the summary with a specific draft proposal of blockers for each of our next few releases.

TL;DR: The "modern" queue is actually in better shape than I feared. 😅 Only ~4 bugs and 2 tasks that really "Should" happen in the near future...

Very quick skim of the 7.x open bugs → :

1. There are 20 issues to triage
2. Only 1 has been updated in the last 2 years. For most, it's been more like 5-8 years. 😅
3. The D7 vs. D8/D9 codebase is pretty similar, so I'm assuming some of these are actually still valid.
4. Only 4 have had any real work done (2 NR, 2 NW), everything else is lingering in "Active".
5. If no one cares about any of these, I'm happy to close them as "outdated" or something, and invite anyone who does still care to open new issues for 2.0.x with modern steps to reproduce, etc.
6. That said, if anyone is inspired to do a more thorough triage and try to reproduce anything in the modern versions, that'd be most welcome. I just don't have the bandwidth for that right now...

TL;DR: The "modern" queue is actually in better shape than I feared. 😅 Only ~4 bugs and 2 tasks that really "Should" happen in the near future...

Woohoo! Feels manageable!

I'd done something similar to 📌 Remove usage of "whitelist", use better terms instead Fixed in Layout Builder Restrictions' #3179983: Replace remaining language of 'whitelist'/'blacklist' in Layout Builder Restrictions module → , which also involved "API changes," so I've assigned myself to that issue.

The big question is should we already revert #2692641: Convert href to the aliased url if possible or not before we tag alpha1. Maybe 2.0.0-alpha1 that's exactly as broken on multilingual as 8.x-1.0-alpha3 is better than waiting for the dust to settle on all the issues in point 1? But part of me wants to fix point 1 before we make any more releases at all..

After thinking about this a bit, I think we should revert that change before doing the 2.0.0-alpha1 release, under the reasoning that it's a behavioral change in how the links are rendered that affects all sites, even if it only *breaks* things on multilingual sites.

@mark_fullmer:

#6: Thanks for taking #3216612 forward! Agreed the queue is manageable.

#7: Yeah, good point. So I think we really do want to finish up point 1 before point 2.

Updated the summary with a 1st draft on a release plan. Thoughts?

Thanks again!
-Derek

@mark_fullmer: p.s. I pinged you in Drupal Slack to try to discuss some of this in real time. Are you ever on there? Lemme know. Thanks again!

p.p.s. I did some initial minor updates to the project page to reflect reality in 2023. 😅 More help needed there, but it's a start. Part of that was marking the 7.x-2.x branch unsupported. 😂 I did leave 7.x-3.x both supported and "recommended" (for the sake of the core Update Manager), but I'm not planning to support it unless someone wants to fund my time to do so...

Tested the dev version. Good to release.

I am also in support of adding a new alpha(?) release with D10 support, so sites can move along with the migration to D10. The remaining bugs are already in the 8.x-1.0-alpha3 release anyway, so at least it doesn't block a D10 upgrade.

Good morning, I'm here to add my voice in support of a D10-compatible release. An alpha or beta release would be fine, just something other than a dev build, since we have recently run into a technical limitation using a dev build based on a specific commit hash. We found that you can't rely on getting the same thing every time you do a Composer build without modifying the site's root `composer.json` file, which isn't an option for us with the architecture of our Pantheon custom upstream.

We are on schedule to upgrade ~100 sites from D9 to D10 in May, and this is one of the last remaining contrib modules in our standard distribution that does not have a D10 compatible release. I appreciate all the fine work folks are doing here, and hope this can get pushed over the finish line soon. Please let us know if there is any further labor that can be contributed to the effort in specific issues.

Some updates to the plan per the discussion w/ Mark referenced at #3270030-35: 8.x-1.0-alpha3 breaks images in multi-language sites. → ...

Meanwhile, the 2.0.0-alpha1 release should be out in a few hours.

Refresh the plan to add a "Released" section now that the next round of alphas are out. 🎉

Yehey for the Drupal 10-compatible release!!! 🎉 🎇 🎋 🎏 🧧

Adding a note that at this point, we have nothing user-facing for 8.x-1.0-alpha5, so it's not really worth another release there, even though all the planned issues are now fixed. 😅

I'm still trying to sort out if 🐛 Dynamic routes in image styles break under pathologic Needs work is duplicate with 🐛 Internal URL handling (language prefixes, base://, ...) Needs work or not. 😉

Adding 📌 PHP 8.1 deprecation notice for passing NULL to explode() Fixed to the lists...

Hello,
Thank you for your hard work!

Can we release version 2.0.0-alpha2? There are 5 fixed issues.

Yes, but 4 of the 5 are test-only fixes. That doesn't seem worth troubling everyone with a new release about. 😅 Only once we fix some more user-facing stuff is it worth a new tagged release (IMHO).

Thanks,
-Derek

@dww I think now It's worth to release a new version 2.0.0-alpha2 which will include 🐛 Option to keep language prefix in URLs Fixed and PHP 8.1 fixes. I'm forced to temporally move this module to modules/custom folder because my customer doesn't allow dev versions on their composer.json and we need the language prefix fix.

@rcodina: Good point. I pushed a 2.0.0-alpha2 tag, the pipeline was happy (happen enough 😅), so I created the release: https://www.drupal.org/project/pathologic/releases/2.0.0-alpha2 →

Thanks,
-Derek

@dww Thanks!