Thanks! My core version is 10.2.7.
I should have clarified that the patch in #12 contains the fix for me as it simply adds :array to the end of the signature. Please see the error message which is about compatibility unlike that in the OP which is about access level.
Like #12 I also needed to apply a patch which adds : array. It resolves a 500 error when creating a custom block.
This is with the core fix from 📌 Revisit the redirect to 'add block' form in the 'add block content' form Fixed .
Error is:
PHP Fatal error: Declaration of Drupal\panels_ipe\Form\PanelsIPEBlockContentForm::actions(array $form, Drupal\Core\Form\FormStateInterface $form_state) must be compatible with Drupal\block_content\BlockContentForm::actions(array $form, Drupal\Core\Form\FormStateInterface $form_state): array in D:\--\web\modules\contrib\panels\panels_ipe\src\Form\PanelsIPEBlockContentForm.php on line 18
Perhaps a new issue should be opened...
@ben.hamelin - Thanks for your help! And sorry about the username switcharoo. :D
What you say makes sense except that media and paragraph entities attached to the node are being updated when the node is saved.
I'm reluctant to turn that setting off because it will trigger more builds than is reasonably necessary.
I don't work with Drupal as much as I'd like to these days but I do believe a menu link is a content entity and so should theoretically be treated the same as a paragraph or media entity.
I think I just ran into this while testing on a staging site where we didn't have Build Webhook URL(s) (or any of the URL fields) configured because ordinarily we don't want to trigger builds unless we're actually testing this functionality. We also disabled the preview functionality after moving off of Gatsby Cloud.
While testing incremental builds locally against staging, it took me a bit to figure out why our content updates weren't generating any Fastbuild entries!
othermachines → created an issue.
@sl45sms Super but this was already addressed in #67.
Sorry, my brain is tired from all of the Drupal 10 migrations!! I think another version check may still be needed on the second occurrence of toInt() (line 203).
@tolibg Same problem here. We think that all file formats are affected but PDFs possibly more forgiving. A coworker is checking into it.
Also we need to remove \Drupal\Component\Utility\Bytes::toInt() (change record linked below) for Drupal 10 compatibility. Uploads are failing for us without this change.
@crmn Assuming you are using , the patch still won't be recognized when you run your code update. You will also need to require mglaman/composer-drupal-lenient then run:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/video_embed_facebook"]'
The way I understand it, doing the above is instructing composer to be lenient with the version constraint when considering this package.
Hi! Since Drupal 9 will be end-of-life in a matter of days can we get a release with this patch please?
Hi! Since Drupal 9 will be end-of-life in two days can we get a release with this patch please?
Thanks for the commit!
I'll certainly test if I can. Our set-up is a bit unusual in that the embeds generated by this module are rendered only for admins/authorized users (it is a decoupled site). I'll try to have a look in the next week or so.
I did a lot of research (mostly reading about others' experiences) and took copious notes before and during the application submission process, which was approved within minutes, so if you're still aiming for app approval I may be able to help.
Here's a patch.
othermachines → created an issue.
My bad was assuming the fix was applied to the 1.x branch. Not sure why I didn't see an error sooner, but fortunately this all happened locally. Ended up rolling back to 1.23 and reapplying the patch in #2945017: Warning on Message settings page → until I am able to update to 2.x.
Sorry for the noise! Might as well close this.
Apologies, I should have searched for the error instead of just checking recent issues. I see it is related to a patch in 📌 Support JSON API, REST, GraphQL and custom normalizations via new computed field Fixed which was fixed. I did remove this patch in a previous update, and this error only came up today when updating to 1.26. So I'm a little confused, but probably something I need to fix on my end.
Related issue: 🐛 After update the metatag module, an error arise from the taxonomy image_type metatag field Closed: works as designed
othermachines → created an issue.
Also trying to upgrade to CKEditor 5 while still on 9.x (which is strongly recommended in the 9.5.x release notes) - Is there a workaround while we wait for a fix?
Thanks! I left a couple of comments on the merge request. At least I think I did. :) Not used to doing things that way so it's practice for me.
+1 Agree that this is a more sensible default, and also that modifying the existing transition is sufficient. Will come back to review.
Fixed with patch from: https://git.drupalcode.org/project/gatsby/-/commit/148cba8a6f10d39481757...
Sorry for the noise!
More info:
$entity->original is null, which triggers the error.
This does not occur when deleting content that is published.
othermachines → created an issue.
We are also seeing this with 4.0.2.
I wondered why paragraphs added to the layout were no longer appearing as translatable after setting up content moderation!
This patch fixes the issue. I can translate paragraphs again. Thanks!