Meeting will happen in #d10readiness on drupal.slack.com.
| Gábor Hojtsy (he/him) |
I believe this was raised by @Kristen Pol (she/her) last meeting |
| Gábor Hojtsy (he/him) |
https://dev.acquia.com/drupal9/deprecation_status?result=Not%20explicitl... is the list of modules not yet compatible |
| Gábor Hojtsy (he/him) |
This is still 4.3k projects. |
| Gábor Hojtsy (he/him) |
We originally planned to make the project update bot start to commit patches generated by itself where the community RTBCed. |
| Gábor Hojtsy (he/him) |
But initiatial estimates showed that would only cover hundreds of projects not thousands. |
| Gábor Hojtsy (he/him) |
That issue was #3168047: Commit Project Update Bot patches to under-maintained projects for Drupal 9 compatibility for reference |
| Gábor Hojtsy (he/him) |
Then @mixologic suggested we pivot to create an alternate composer endpoint instead that would allow people to install projects that are not otherwise compatible. |
| Gábor Hojtsy (he/him) |
That is at #3227031: Add a major-version-agnostic façade endpoint for stranded d8 projects. and @mixologic is working on it. |
| Gábor Hojtsy (he/him) |
Additionally to this we need a maintainer drive though to commit and make releases and any other bright ideas are welcome! :) (edited) |
| Kristen Pol (she/her) |
Oh... cool idea with the facade! |
| Kristen Pol (she/her) |
This is definitely a better approach than the auto-commit... it's a little more work for the developers but makes it very clear which modules are the "unmaintained" ones :wink: |
| mixologic |
developers can do this now, except they have to do it one by one, and for every project they want to override.. this gives them a way to shortcut a bunch of effort so that they can just use composer patches. |
| Kristen Pol (she/her) |
I'm still getting clarity/approval for some paid time to port some modules... hopefully will sort that out by next week |
| Kristen Pol (she/her) |
@mixologic I'm confused by what you wrote"developers can do this now"maybe I'm misunderstanding but I thought that when you tried to patch an D8 module with the autogenerated (or handcrafted) patch that composer wouldn't let you add the project because of the compatibility issue |
| Gábor Hojtsy (he/him) |
Well they can use the git repo like your post with @benjifisher;) |
| Kristen Pol (she/her) |
Sorry, yeah... had a brain melt |
| Kristen Pol (she/her) |
haha |
| Kristen Pol (she/her) |
ignore me... haven't been myself for the last week |
| mixologic |
Although, I was just helping somebody in #composer and it occurred to me that if a project lacks a composer.json to begin with, then the git repo step also needs to have a composer.json generated for it as part of the issue fork, so this makes that simpler as well. |
| benjifisher |
I have used a repository with {
"type": "vcs",
"url": "https://git.drupalcode.org/issue/ISSUE_FORK"
},for at least four modules. Those modules all have composer.json already, so I did not run into that problem.For the sake of lurkers: https://fruition.net/about/blog/developer-tips-testing-a-drupal-8-module... |
| Kristen Pol (she/her) |
Relevant thread with some instructions here as wellhttps://drupal.slack.com/archives/CDDD98AMN/p1630354200014300?thread_ts=... |
| hotwebmatter |
Hi all! I'm late to the party, but these are the instructions I wrote up. I'm planning to expand this into a blog post, then a Lunch & Learn presentation, and submit it as a presentation to some upcoming DrupalCamps.-------Here's an example of an issue fork I just created to provide a D8/D9 transitional module:https://www.drupal.org/project/select_registration_roles/issues/3148726#... My process is like this:
- run "Upgrade Status" module to identify D9-incompatible projects
- click on "Issues" to go to the issue queue
- look for an issue called "Automated Drupal 9 compatibility fixes"
- apply the latest patch to my project using cweagans/composer-patches
- click the green button to "Create issue fork"
- in a Terminal, git clone the repo and git fetch the Issue Fork branch
- copy and paste code from the patched module (in D8 project) to the Issue Fork
- in some cases, this is enough for compatibility
- in other cases, there are a few more issues flagged by Rector and/or PHPCS.
- apply all the fixes and commit changes, and git push upstream to Issue Fork
- make a Merge Request with instructions on how to use Issue Fork as repo in projects
- test my instructions by pasting the code into my composer.json
- be certain to remove the composer-patches patch at this time (it's no longer needed)
- if the new repo works, rejoice! :yay2:
- if it does not work, often that is because the repo does not contain a composer.json
- create a valid composer.json by executing this command:
composer show -a drupal/workflow_state_config 1.0.0-alpha2 --format=jsonremove anything that specifies the version (source, dist, and path)
That ought to do it! |
| hotwebmatter |
There are a few sections that could use more detail. In particular, the last step (cleaning up auto-generated composer.json) needs a bit more detail for clarity. |
Comments
Comment #2
gábor hojtsyComment #8
gábor hojtsyComment #9
gábor hojtsyFix complicated formatting in one of the messages.