Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.RC4 of Panopoly is out, so is Drupal Core 7.22 and several contrib modules with new major versions.
I upgraded and thoroughly tested OA2 with it:
The latest Radix theme cleanup borks the fleximenu, so I'm staying one commit behind.
Also, the renaming of a function in message.module requires a minor adaptation in oa_messages.module.
But that should be it. From whatever I tested, it should be just fine.
| Comment | File | Size | Author |
|---|---|---|---|
| oa2-d7-22-upgrade.patch | 10.2 KB | Pancho |
Comments
Comment #1
mpotter CreditAttribution: mpotter commentedNice work on that! Huge help! Committed to b46a869.
Comment #2
PanchoWow, now we're really up to date!
What is actually your policy regarding upstream patches? Do we take whatever fixes a bug we hit on an OA2 install? Or do we want to search for relevant patches in upstream issue queues?
Would we do 20 or 30 patches? Or only a few major ones? Or only patches we don't expect to be committed upstream within the next weeks?
And what would be the workflow for bugs in Panopoly's dependencies? Obviously the upstream issue is most important, but would we start a tracker issue on Panopoly and then move it over to OA2 or the other way around?
Comment #3
mpotter CreditAttribution: mpotter commentedAll good questions!
Definitely first search for relevant patches in upstream issue queues. OA2 pushes the edge of many modules and we want to help fix any bugs in those modules whenever possible. Once a working patch is submitted to an upstream module, I can include that patch in the OA2 make file until it gets committed to the module itself. In general, adding patches to the OA2 make file should be a temporary fix as we should be encouraging the module maintainers to commit bug patches.
It really depends upon how major an issue we are dealing with. If it's relatively minor, then I'd probably just wait for the module itself to be updated. If it really impacts OA2 usability or functionality, then I'd add it to the OA2 make file. But I definitely don't want to have 20-30 patches in the make file.
If the module is something used in Panopoly then we'll we working closely with the Panopoly folks to get it committed there and added to their make files rather than putting it into OA2. I regularly send the Panopoly team a list of patches being used in OA2 so that they can get those added. Panopoly issues should *definitely* be tracked in the Panopoly Issue Queue and not here.
Basically, track the issue as far upstream as possible. But feel free to post an Issue here to bring my attention to any core or module patches that might be needed in OA2.