This will be done in 13.0.0. The work is ready not yet in a tagged version, once that lands I'll mark this as fixed and we will stop supporting both themes on drupal.org
ronaldtebrake → created an issue.
ronaldtebrake → created an issue.
The merge request should fix:
Error: Class "Drupal\social_pwa\Controller\CacheableJsonResponse" not found in Drupal\social_pwa\Controller\ManifestOutputController->generateManifest() (line 84 of /modules/contrib/social_pwa/src/Controller/ManifestOutputController.php).
and fix the manifest json part of it.
ronaldtebrake → made their first commit to this issue’s fork.
ronaldtebrake → created an issue.
viniciusrp → credited ronaldtebrake → .
Just wanted to confirm in here we're happy with the ones provided for Open Social's advisories. Thanks for all the efforts in here!
Thanks for the issue and patch;
Instead we reverted the changes from https://github.com/goalgorilla/open_social/pull/4177/files which shouldn't have made it in 12.4.x in the first place
This will be in the next 12.4.x release through: https://github.com/goalgorilla/open_social/pull/4223
Thanks for that, I'll see if I can get someone to work on this one as well and also release that as hotfix!
https://www.drupal.org/project/social/releases/12.4.7 →
Let me know if that did the trick
Thanks for the input in both issues.
I think the actual issue is that the cherry picked code in the referenced issue:
https://www.drupal.org/project/social/issues/3487220
🐛
User groups list does not work for hashed content types
Needs work
is created with group version 2 in mind, which is part of the 13.x release, so that doesn't work for 12.4.6 which still is on group version 1.
I will revert that commit and make sure that this is part of the next 12.4.7 release.
+1 on this, think this will be great to have a also to provide as proof of how valuable the end users are finding this
Coming from a Drupal Distribution we've found most of these issues to be the reason why we had to separated it to a different module.
Especially now with the move to project browser a lot more is very vanilla composer based, behind a UI, for site builders to use. The more you deviate from regular composer, the harder that will be to maintain I'd imagine. See for example: https://www.drupal.org/project/project_browser/issues/3300061 📌 [policy, no patch] Determine Composer validation rules for installing through Composer Fixed
We also have used hook_requirements for this in Open Social, basically because back than we still had people installing it without composer and we needed to have them install all the right packages. That could work I'd imagine, but means the DX suffers a bit, not sure how bad that is.
Potentially eventually recipes might help splitting this up in separate packages, to just have a set of packages running together.
E.g. if you want you can just have Milvus and Open AI working together, and only have them installed, helping the maintenance of those using the ai module as well. But I can imagine that's quite the topic to open, just thought i'd pitch that in here as well.
I see this added the "probots-io/pinecone-php": "^1.0" requirement.
This comes with a php 8.2 requirement that basically stops allowing us to use it on Drupal 10.2 where 8.1 is still supported.
Is this truly a hard requirement?
marcus_johansson → credited ronaldtebrake → .
ronaldtebrake → created an issue.
ronaldtebrake → created an issue.
ronaldtebrake → created an issue.
No worries, thanks for the quick fix and can confirm it works again!
ronaldtebrake → created an issue.
Just thought I'd circle back here;
I've just tested ai_ckeditor on Drupal 10.2 it seems the only change that really breaks is the fact we use ViewModel in
https://git.drupalcode.org/project/ai/-/blob/1.0.x/modules/ai_ckeditor/j...
Where for Drupal 10.2 and the version of CKEditor 5 shipped in there it's still Model instead of ViewModel.
As per:
https://ckeditor.com/docs/ckeditor5/latest/updating/guides/update-to-41....
We renamed the export of Model from the @ckeditor/ckeditor5-ui package to ViewModel.
Changing that makes it work nicely on Drupal 10.2, but can imagine that's not necessarily something you'd want to support.
robertragas → credited ronaldtebrake → .
robertragas → credited ronaldtebrake → .
ronaldtebrake → created an issue.
Will be in alpha 9
Will be in alpha 9
Will be in alpha 9
Will be in alpha 9
Will be in alpha 9
robertragas → credited ronaldtebrake → .
In 13.0.0-alpha8
In 13.0.0-alpha8
Released in alpha 7!
In alpha 7
LGTM
In 13 alpha6
In 13 alpha6
In 13 alpha6
In 13.0.0-alpha5
In 13.0.0-alpha5
In 13.0.0-alpha5
In 13.0.0-alpha5
In 13.0.0-alpha5
In 13.0.0-alpha5
ronaldtebrake → created an issue.
ronaldtebrake → created an issue.
Can also confirm this did the trick for us
In 13.0.0-alpha4
In 13.0.0-alpha2
For now we've added the administer taxonomy permission back again for SM.
As we encountered some scenarios where the permission wasn't correctly assigned for the individual vocab/terms.
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Released in 13.0.0-alpha2
Release in 13.0.0-alpha2
In 12.4.2 / 12.3.5 and alpha 2 releasing today.
In 12.4.2 / 12.3.5 and alpha 2
In 12.4.2 / 12.3.5 and alpha 2
In 12.4.2 / 12.3.5 and alpha 2
Will be in alpha2!
Will be in alpha2
ronaldtebrake → created an issue.
code LGTM