🇷🇴Romania @bbu23

Thank you!

That would be a great help!
Thank you, I will post the updates on the issues when I have a patch.

That's excellent news! I'm really glad to hear that the fix worked and resolved both the main issue and the related one.

Regarding the API key changing unexpectedly on your end, I honestly don't know why that would have happened. On my side, during development and testing, I've sometimes accidentally regenerated keys, so I know it can occur. However, if your experience was different and you didn't manually regenerate it, it's intriguing, I'll have to check what other opensolr actions can lead to this.

I'll keep both issues open for now. My goal is to prevent similar crashes from happening and to ensure that if any failures do occur, the module provides clearer status messages so issues like this are easier to diagnose in the future.

Thank you for your collaboration while we worked through this. I'm really glad I could help!

Sure!

Interesting. Yes, please. Try updating the key to match the one in your opensolr account and let me know if you can edit the Server after that.

Thanks, I'll check this issue out after fixing #3533991 🐛 TypeError: Unsupported operand types: array + null Active , to see if it's still needed.

Could you confirm the following:
1. You were not using the key module when you initially defined your opensolr credentials
2. You've recently installed the key module
3. If you navigate to opensolr config form /admin/config/search/search-api/opensolr you see the secret key select with an empty value set to "- Select a key -"

Hi, thanks for reporting this issue, and providing detailed information.
It seems that the index selector field might be affected.
I'll look into it.

Currently having difficulties with writing the tests, as DB connections are not populated properly throughout the entire test phase.

Add information about defining the plugin schemas introduced in version 4.0.3

Add information about schema definition added in 4.0.3

Looks good to me!
Let's wait for others / Project Moderator to take a look.

Thanks! 👍 Changes look good to me, except for the inheritdoc comment on NodeSwapperConfirmForm constructor. It should be completely removed or defined, not inherited (this is super minor).

And I also noticed that the config schema defines the old_node_unpublish as boolean, but the default value from the config install folder is set to integer. It should match the defined type.

Changing the status because of the schema issue.

Question: now that the main branch is 1.2.x, should I update this issue's description to include that information?

You didn't have the main branch mentioned in the description, so that's up to you. What's important is that the default gitlab branch is set to 1.2.x as expected.

Remove "please" from sentences.

And just noticed that your default branch is main. That should not be the case, it should probably be 1.2.x for your latest tag release.
See https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine... →

The module is missing the composer.json file.

Use dependency injection for loading Path Aliases and Nodes

FILE: /var/www/html/web/modules/custom/node_swapper/src/Service/NodeSwapperService.php
------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 4 WARNINGS AFFECTING 4 LINES
------------------------------------------------------------------------------------------------------
  90 | WARNING | PathAlias::load calls should be avoided in classes, use dependency injection instead
  97 | WARNING | PathAlias::load calls should be avoided in classes, use dependency injection instead
 124 | WARNING | Node::load calls should be avoided in classes, use dependency injection instead
 125 | WARNING | Node::load calls should be avoided in classes, use dependency injection instead
------------------------------------------------------------------------------------------------------

And actually, you should use ParamConverter in routing file to get node objects directly instead of loading them in the buildForm method. You can get inspired from other node route definitions.

In src/Form/NodeSwapperConfirmForm.php line 88, the param type for $entity_type_manager should be \Drupal\Core\Entity\EntityTypeManagerInterface, though the __construct() method does not require any function description anymore, so unless you want to keep it, the whole description block can be removed.

$src_node->title->value should be $src_node->label(), same for destination node.

yep, +1 RTBC

Oh yeah, that's true! Great catch! 💪
Glad u solved it!

Hi, try removing the langcode key from your affected configs in config/install folder. E.g. https://git.drupalcode.org/project/sobki_profile_bootstrap/-/blob/11.0.x...

Looking at the config_object core definition, there is this:

config_object:
  type: mapping
  mapping:
    _core:
      # This only exists for merging configuration; it's not required.
      requiredKey: false
      type: _core_config_info
    langcode:
      requiredKey: false
      type: langcode
  constraints:
    # The `langcode` key:
    # - MUST be specified when there are translatable values
    # - MUST NOT be specified when there are no translatable values.
    # Translatable values are specified for this config schema type (a subtype of `type: config_object`) if the
    # `translatable` flag is present and set to `true` for *any* element in that config schema type.
    LangcodeRequiredIfTranslatableValues: ~

bbu23 → created an issue.

Hi. Responsive images can be achieved by using the Responsive Image core module. See https://www.drupal.org/docs/mobile-drupal-sites/responsive-images →

Hi,

Thank your for reporting this issue, but I am unable to reproduce the behaviour.
Since version 2.0.1, the Swiper formatter is not applied anymore when there is only one slide, and instead a warning is shown to inform the user about it (if logged in).

Since this issue is recent, could you please clarify the steps to reproduce this so we can analyze the behaviour if it still applies?

Moved the provided patch to a merge request as this is the recommended way, and it's easier to review.
Thank you for reporting the issue and for your contributions, I tested and it works as expected.

bbu23 → changed the visibility of the branch 3488425-slides-per-group to active.

bbu23 → changed the visibility of the branch 3488425-slides-per-group to hidden.

bbu23 → changed the visibility of the branch 3488425-slides-per-group to hidden.

Thank you both for providing details and use cases.
A bit late, but I provided a fix in the MR. Let me know if this works for you.

Hey @shortspoken, thank you for this, I have linked the provided documentation to the module's project page.
Step by step, it can be populate by us and whoever wants to contribute to it now that it's easily accessible.

Thank you @chrisolof for your contribution, the changes look great!
The provided solution is a great improvement by sticking to the expected return type and adding a fallback foreach at the end.
I tested this with the ECK → module and confirm that it works as expected.

Update listing images to match latest changes in version 4.0.2

Fixed in version 4.0.2.

Fixed in version 4.0.2.

Fixed in version 4.0.2.

Fixed in version 4.0.2.

bbu23 → created an issue.

The remaining outdated pages have been updated and improved.

Update and improve the page

Replace outdated Configuration Entity names

Improve the text of the documentation page.

Update outdated screenshots and replace outdated Configuration Entity names

Finish updating outdated information and improve text.

Part 1 of updating outdated information from this page and improving text.

bbu23 → created an issue.

bbu23 → created an issue.

Tested with Drupal Core 10.2, 10.3, 10.4, 11.1 and 11.2.

I've also been using this approach for a long time, initially inspired from the content_moderation core module. I think it's better to provide arguments than asking someone to their comment, it's healthier and more productive.

bbu23 → created an issue.

Hehe ^^ I'm glad that everything works well now!

To me it was important to have both available: Drush & GUI. Your feedback was very valuable, reason why now we have Drush commands that can export/import menus directly and commands that can export/import using configuration entities. The GUI was worked based on an initial feedback where there was a request for downloadable exports, which couldn't have been achieved with Drush only.

Thanks again for your involvement in making the module much better!

I have encountered a similar issue, but non-related to AJAX.

My problem seems to happen in validateDatelist and not valueCallback whenever a datelist field that does not have a default value has its access set to FALSE.

IRL Example:
- Have a user entity that has a field_birthdate that uses date list
- The field_birthdate is required, and the user that I am testing with does not have a value set yet for that field
- Using the simple_pass_reset module, I intend to reset the user's password
- The simple user pass reset form is after all a User entity form where all fields except for the password fields have the #access set to FALSE.
- When attempting to change the password for this user, the form throws a validation error for the datelist field (birthdate) saying it's required even though the field is not visible.
- This does not happen for users that have the field_birthdate already set (default value present)

As a quick fix, I've added an extra check to the $input_exists to also check if the field exists but it's not accessible. The existance of the input is verified by form state values which are present, so I don't know at the moment if the root cause is somewhere else or not.

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

Patch #4 works for me (in combination with another patch from #3092568 that was for something else). Thanks!

New issues should target latest dev version.

Hi @chrisolof,

Thanks for reporting this issue, great catch!
I'll investigate.

Thanks for reporting and providing an MR for this issue.
We'll review and get back to you if needed.

bbu23 → created an issue.

The original issue has been fixed. The links now point to the correct major version of the external library.
For any other issues, feel free to open a different ticket.
Thank you for your contribution!

bbu23 → changed the visibility of the branch 1.0.x to hidden.

bbu23 → changed the visibility of the branch 3470178-links-to-swiper to active.

We've decided to keep PHP 8.1 as a minimum requirement as long as the Drupal Core dependency has the minimum version requirement lower than 11.
PHP 8.3 will be enforced only when the core minimum version requirement will be set to 11.
Thank you for your contribution!

bbu23 → changed the visibility of the branch 2.0.x to hidden.

I have the following setup:

1. A configuration entity that builds the add form using ajax. The field that triggers ajax is a plugin select list.
2. When a plugin is selected, the form includes subforms of the plugins, using ajax. All okay.
3. If one of the plugin's form (the subform) is using ajax, then the error can appear when attempting to retrieve values from the SubFormState in the build form area. The ajax calls within the plugin form will also have the form state of the parent.

It seems like ajax inside subform of an ajax loaded parent form does not work well.

Thanks so much for confirming, reporting and helping with testing!

Thanks.