🇭🇺Hungary @huzooka

Imho this can be solved without changing the return type at Drupal\facets\Plugin\facets\facet_source\SearchApiDisplay::getCount().

I hope we can get back the RTBC status 🥹

There they are!

https://git.drupalcode.org/issue/entity_print-3468563/-/jobs/3536971#L127

1 test triggered 2 PHP warnings:
1) /builds/issue/entity_print-3468563/entity_print.module:63
Undefined array key "entity_test_with_bundle"
Triggered by:
* Drupal\Tests\entity_print\Kernel\ExtraFieldsTest::testBundleableEntityTypeWithoutBundle
  /builds/issue/entity_print-3468563/tests/src/Kernel/ExtraFieldsTest.php:192
2) /builds/issue/entity_print-3468563/entity_print.module:63
foreach() argument must be of type array|object, null given
Triggered by:
* Drupal\Tests\entity_print\Kernel\ExtraFieldsTest::testBundleableEntityTypeWithoutBundle
  /builds/issue/entity_print-3468563/tests/src/Kernel/ExtraFieldsTest.php:192
OK, but there were issues!
Tests: 59, Assertions: 544, Warnings: 2.

Th test method I just added should reveal the problem we saw (see #6)

We just hit an error with this patch applied, checking what's going on (should be obvious imho):

php.WARNING: Warning: Undefined array key "webform_submission" in entity_print_entity_extra_field_info() (line 63 of <project-root>/web/modules/contrib/entity_print/entity_print.module)

Moving back to NW.

* Added a new config option to restrict print features to entity types.
* Added a config subscriber which resets entity field caches if config value is changed
* Updated hook implementations
* Added test coverage

Asking for review.

I also need the same feature (option to limit entity print to some specified types). I also discovered that extra fields are added to every single entity type, not just to content entity types.

Changing the category to feature request.

Should be perfect now 😬

I'm sorry, this is normal, since you can adjust the settings form by editing the config YAML.

Obviously perfect. RTBC!

Raising priority according to https://www.drupal.org/node/3156247#s-list-of-priority-options →

Render one feature unusable with no workaround.

Re @dxvargas, Yes, I did, and it WFM, I just forgot to leave a comment and set it to RTBC 😬 Doing so now.

Lowering priority according https://www.drupal.org/node/3156247#s-list-of-priority-options →

The return type is obviously wrong, but I would just remove the type hints now to not break compatibility with e.g. Private Message Flood Protection → .

Anyway, since there is some overlap in the maintainers of this module and private_message_flood, I'd let maintainers to decide.

Root of this bug is the same as the root of 🐛 MigMagLookup can unintentally strip out messages from non-SQL sources Active

I'm very sorry, but I won't go into this direction. Migrate Upgrate basically creates migraiton config entities from the plugin instances what you can customize later on, and I don't want to provide any kind of support for custom migrations.

https://huzooka.github.io/development/2020/05/03/drupal-migration-mistak...

Info yamls of test modules have different standards, look at the test modules inside core.
The userialize() calls are mostly copied from core.

Closing since CI does not report any issue.

Closing since CI does not report any issue.

Closing as duplicate of 📌 Automated Drupal 11 compatibility fixes for migmag Needs work .

Tests are green, going to merge and create a new release soonish.
I had to remove color and suppress tests using it because drupal/color has no Drupal11 compatible release yet. Added 📌 Re-enable testing of RollbackableColor plugin Active to not forget about restoring these temporary changes.

huzooka → created an issue.

huzooka → created an issue.

huzooka → created an issue.

huzooka → changed the visibility of the branch project-update-bot-only to hidden.

huzooka → changed the visibility of the branch 3433407-automated-drupal-11 to hidden.

huzooka → changed the visibility of the branch project-update-bot-only to hidden.

@jsacksick, Could you please check whether the 3465782-using-slash-json-parser branch (MR 102) in 🐛 Using "/" item_selector in Json parser plugin config does not work as expected anymore Needs review fixes the issue you have?

Created two MRs:
* 3465782-using-slash-json-parser (MR 102) restores support for "/" item selector.
* 3465782-full-bc-json-parser (MR 103) fully restores the previous behavior with (faulty) item selectors. (Look at the new test in JsonTest).

I don't think I can do anything for the "max PHP version" tests - seems that the phpunit.xml is build for a Drupal version which still had "HtmlOutputPrinter", but the actual artifact contains Drupal 11, which does not have the class anymore.

Asking for review (and further ideas).

huzooka → created an issue.

It is green, so try to get a review for now.

What I did so far:

1. I think that @Berdir's hint about the cacheability is right. I changed FlagViewsRelationship to implement CacheableDependencyInterface, and implemented the necessary methods:
   1. If we're asked for a per-user relationship and the configured flag is not global, then the cache context will be ['user]
   2. Left the cache max age -1 (permanent)
   3. ...but in the cache tags, we return with the flag's cache ID (so if the flag will be changed somehow to be non-global or vice versa, then the view be recalculated).
2. Installed flag_following on a vanilla Drupal (10.3.x) and copied the re-exported YAML back to the module (without the config hash parts)
3. Then I cleaned up the changes in the file to help reviewing the changes... But maybe we don't want this cleanup?..
4. Fixed the two PHP CS nits in the plugin class.

I don't know whether it is needed to add some test coverage for the relationship plugin, let's see a green result for first (and ideally, some community review or hits from maintainers).

Started working on this. So far, the view in flag_following seems to be quite dated, based on git blame.

huzooka → created an issue.

huzooka → created an issue.

MR12 shows that BC wasn’t restored yet.

@joegraduate, @heddn, Thank you! 🙏

huzooka → created an issue.

Test failures were caused by a new, non-BC Migrate Plus patch release: 🐛 Fix backwards-incompatible Json data_parser API change included in 6.0.3. Needs work , and are resolved (in the context of our tests) in 📌 Set up conflict with Migrate Plus 6.0.3+ Active .

Be aware of that even if EME does not depend on Migrate Plus, the migration set modules it generates are depending on it.
So if you're using Migrate Plus 6.0.3, your exports will brake.

huzooka → created an issue.

huzooka → created an issue.

This issue already has a workaround in 2.x, except of a tiny bug which makes it useless.

Moving to 2.x.

Moving to 2.x

huzooka → created an issue.

@silvi.addweb, please respect the issue queue etiquette

huzooka → created an issue.

huzooka → changed the visibility of the branch 3433398-automated-drupal-11 to hidden.

Blockers are addressed, ready for work.

huzooka → changed the visibility of the branch 3434654-automated-drupal-11 to hidden.

huzooka → made their first commit to this issue’s fork.

We only had some very tiny issues, so I fixed them in 📌 Create a release compatible with Drupal 11 Fixed