🇭🇺Hungary @huzooka

Re #5,
Thank you for testing this! I also addressed the issue you found, and added it as a test case.

I'm asking for a second round review.

Created a patch on top of 6.2.x.

I addressed review feedback, created 📌 Convert FieldConfigFormAlter and BundleEntityFormAlter to a single service Active as a follow-up; also added some comments for our future selves.

huzooka → created an issue.

huzooka → changed the visibility of the branch 3362124-3.x to hidden.

I was wondering why this issue only affects horizontal tabs - and found out that in case of vertical tabs, Drupal core handles this in misc/vertical-tabs.js with handleFragmentLinkClickOrHashChange(). So I changed the approach, and added the code to 3362124-4.x branch. I think that's the right way to solve this issue.

Could you please check this new MR (https://git.drupalcode.org/project/field_group/-/merge_requests/110) before I align also the other one for 3.x ?

We also need this feature. Our only problem is that the selectors used in Javascript are part of the markup delivered by the error message theme functions / elements (also JS!: Drupal.theme.message), and we need this to work in multiple themes simultaneously.

I want to work on this a bit to make it theme-agnostic.

huzooka → created an issue.

I also created a patch which can be applied on Webform 6.2.9; uploading it here if anyone is interested.

CS and Eslint violations are preexisting imho.
Asking for a (quick) review and about further tasks.

huzooka → created an issue.

Checked and also tested !15, I found no problems, it's perfect.

To me the widget config looked a bit weird when I first saw the exported display config, but actually it also makes sense - the first level "settings" key belongs to Drupal's form widgets, but the second "settings" key is actually a Slim Select (object) constructor property, like here https://slimselectjs.com/settings#openPosition

...
field_tags: 
  type: slim_select
  weight: 3
  region: content
  settings:     
    settings:       
      allowDeselect: true
      closeOnSelect: false
      openPosition: top
  third_party_settings: {  }
...

Indeed, this version was probably a copy / paste leftover.

I was about RTBCing the MR, but I just noticed that the cache max age of the view was also changed from 0 (no caching) to -1 (cached permanently), so I'm leaving this to the maintainers; maybe they remember why they used 0 initially.

Forgot to unassign

I see a test failure with the next minor core release, but imho it is a preexisting issue.

* Updated (created) issue summary.
* Changed category to feature request.
* Changed priority to normal.

Feel free to change them if you disagree.

My team uses preinstalled Drupal instance for testing and in case of a time-based caching workaround, I need to be able to mock (request) time.

Re #3

The idea is good, but we cannot rely on ::time() as we are so low level that we need to work within the bootstrap container as well and request() needs the request, which does not exist at that time.

What if we follow the same logic as we have at ::debug()? So, trying to return \Drupal::time()->getRequestTime() and if it fails, fall back to the actual logic (int) $_SERVER['REQUEST_TIME'] ?? time();

Also,

1. It is unclear to me why this issue is postponed - maybe it was just stuck in this state accidentally?
2. My suggestion is to change this to a task (or to a feature request). Imho this is not a bug anymore.

I want to share my local path with you.

Pipelines are green, also added test coverage.

Next time please give us a bit more time to work on such things than 1 minute.

@ankitsingh0188 please respect issue queue etiquette

Here is the warning we see at every bundle entity form:
https://git.drupalcode.org/issue/rdf_sync-3518353/-/jobs/4922955#L446

huzooka → created an issue.

huzooka → created an issue.

Thank you again. I will probably move the changes to another ticket since this task was about tests and the code was already released.

Thank you!

Seems to be OK this way, I hope you forgive me 🥹

I have this idea to not have any dependency on the Migrate module, which I don't want to break. I'd make an attempt to remove the MigrateDestinationInterface base form RollbackableInterface... Visually it doesn't seem to be necessary.

Added a test to reproduce the issue.

huzooka → changed the visibility of the branch 1.8.x to hidden.

huzooka → changed the visibility of the branch 3393493-error-interface-drupalmigratepluginmigratedestinationinterface to hidden.

Also found and reported 🐛 PHPStan baseline removed before generating a new one from test results Active .

I also looked at the docs here https://project.pages.drupalcode.org/gitlab_templates/jobs/phpstan, didn't found anything whick made me think my config is not valid anymore.

huzooka → created an issue.

huzooka → created an issue.

huzooka → created an issue.

huzooka → created an issue.

This was already added to 2.x (but there aren't any stable 2.x release yet)
✨ Support exporting entities per bundle Needs work

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.