@xenophyle I think that's how it worked when I tried this out the first time yes, I didn't have to change anything to switch to using the collection.
Created MR from the patch in #14 against the latest 2.0.x.
brunodbo → made their first commit to this issue’s fork.
I am seeing the same error as mentioned in #8. As @rajdip_755 says in his comment, the fix for that problem (i.e., changing the dispatch() method's argument order, as mentioned in #9) is already in the 4.0.x branch (see https://git.drupalcode.org/project/forward/-/commit/322887d1df607c30fa2b...), so I think all that needs to be done is roll a new release that includes the fix. Raising this to critical as this prevents the module from functioning currently.
brunodbo → made their first commit to this issue’s fork.
brunodbo → made their first commit to this issue’s fork.
brunodbo → changed the visibility of the branch 3165072-split-purgers-by to active.
brunodbo → changed the visibility of the branch 3165072-split-purgers-by to hidden.
brunodbo → changed the visibility of the branch 3165072-split-purgers-by to hidden.
I ran into this as well. For anyone else hitting this, you can disable the "Restore Client IP Address" option with drush config:set cloudflare.settings client_ip_restore_enabled 0. That made requests cached by Cloudflare work again for me.
brunodbo → created an issue.
I ran into this while running migrations: migrations would slow down and eventually run out of memory as described in
🐛
File migration slows down and eats more and more memory, eventually stops
Needs work
. I ended up using
https://www.drupal.org/project/migrate_boost →
to disable hook_post_action's hooks, which allowed migrations to complete.
Just noting I'll be looking at https://www.drupal.org/project/google_analytics_counter → to replace ga_stats in our D10 build.
brunodbo → created an issue.
Oops patch didn't upload.
This patch adds an option to set the draggable option on the modal.
As described in #105, I downloaded the patch from the MR, saved it to a file, then tried applying it using https://github.com/cweagans/composer-patches, but that failed. The patch in #60 did work. I was using Drupal 10.1.6 when testing.
Using a checkout of core's 10.1 branch, I applied the patch from the MR manually, and it produced the following output:
18:53 $ git apply -v 4278.diff
4278.diff:145: trailing whitespace.
l#Y¢lE�,
4278.diff:176: trailing whitespace.
Ȕ��4�k���"x��G���t\|[�K8Ven��+^#[X�e~�+���:���i��6OW��B3G�8e���ޱ�3xҾp��j��Tz��
4278.diff:214: trailing whitespace.
��`�(��!�MC����#��}�n��nBR ���-5�������U/�����4��jcc��@/��Jv���I:���b�"uI_칌�!���߇�r
|ı��k�'n�-�.�g�P|��i�Z}k5���$�C8hB��{
4278.diff:221: trailing whitespace.
���3$h��* �c��)��F�%�O��5�E
4278.diff:238: trailing whitespace.
}m���D�Ok���)���ӥ1��"�#�1MT�uJ�y)}����'��j{�0[�_���'��]�PLT<�L���E}��p:
Checking patch core/modules/forum/forum.install...
Checking patch core/modules/forum/forum.post_update.php...
Checking patch core/modules/forum/tests/fixtures/update/drupal-10.1.0.empty.testing.forum.gz...
Checking patch core/modules/forum/tests/src/Functional/ForumIndexUpdateTest.php...
Checking patch core/modules/forum/tests/src/Kernel/ForumIndexTest.php...
Applied patch core/modules/forum/forum.install cleanly.
Applied patch core/modules/forum/forum.post_update.php cleanly.
Applied patch core/modules/forum/tests/fixtures/update/drupal-10.1.0.empty.testing.forum.gz cleanly.
Applied patch core/modules/forum/tests/src/Functional/ForumIndexUpdateTest.php cleanly.
Applied patch core/modules/forum/tests/src/Kernel/ForumIndexTest.php cleanly.
warning: squelched 1 whitespace error
warning: 6 lines add whitespace errors.
Could this be an issue with https://github.com/cweagans/composer-patches not handling the test fixtures properly?
First attempt at a patch. Leaving as "Needs work" for test.
brunodbo → created an issue.
This is a reroll of #62 for 11.x, which also applies to 10.1.x. I'm getting an error when trying to create an interdiff that I'm unable to figure out at the moment (interdiff fails to process the patch files for some reason). This patch a straight reroll of the patch in #62. The only change is that I omitted the Drupal version number in the changes to file_requirements(), and in the comment for file_progress_implementation().
Do we need the file_requirements() at all? There is no system information to display anymore on the status report, so we could remove that message.
Leaving as needs work for tests.
Could this be a duplicate of 📌 Unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in Drupal\Core\Entity\Sql\SqlContentEntityStorage Needs work ?
This might be related to this core issue: 📌 Unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in Drupal\Core\Entity\Sql\SqlContentEntityStorage Needs work
Thanks for the quick response. I wasn't seeing an option to disable the sitemaps in v3, and couldn't see any of my sitemaps after updating to v4. I ended up uninstalling Simple Sitemap v3 and starting again from scratch on v4, all in all pretty quick since I just had a single sitemap to deal with.
The Context dependency in composer.json is for Context v4.1, which is incompatible with Drupal 10. We'll have to update that to Context v5, which is compatible with Drupal 10.
brunodbo → created an issue.
brunodbo → created an issue.
Rerolled patch in #2 against latest 2.x branch, and attempted to address #3 (catching \Throwable).
Glad to see this merged, thanks!