Account created on 2 February 2013, over 12 years ago
#

Merge Requests

More

Recent comments

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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?

🇷🇴Romania bbu23

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.

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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.

🇷🇴Romania bbu23

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.

🇷🇴Romania bbu23

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.

🇷🇴Romania bbu23

Update listing images to match latest changes in version 4.0.2

🇷🇴Romania bbu23

The remaining outdated pages have been updated and improved.

🇷🇴Romania bbu23

Update and improve the page

🇷🇴Romania bbu23

Replace outdated Configuration Entity names

🇷🇴Romania bbu23

Improve the text of the documentation page.

🇷🇴Romania bbu23

Update outdated screenshots and replace outdated Configuration Entity names

🇷🇴Romania bbu23

Finish updating outdated information and improve text.

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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.

🇷🇴Romania bbu23

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!

🇷🇴Romania bbu23

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.

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

New issues should target latest dev version.

🇷🇴Romania bbu23

Hi @chrisolof,

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

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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!

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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!

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

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.

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

Thanks, I also confirm that the issue has been fixed.

@kumkum29 yes, we are planning a release as soon as we have a stable dev. We're getting very close to it.

P.S. If you're experiencing "same content slides", please use the patch in https://www.drupal.org/project/swiper_formatter/issues/3488101 🐛 Display as "Swiper Entity" shows the same image in all slider elements Active until merged.

🇷🇴Romania bbu23

Hi,

I updated the MR. Please let me know if this fixes both issues.

🇷🇴Romania bbu23

@juagarc4 thank you for providing the detailed steps. I'll try to reproduce as soon as I get the chance.

🇷🇴Romania bbu23

Thanks for reporting this, but this issue is very similar to the related one. Closing it as duplicate. Please provide the information in the other ticket, since the behaviour of the output has the same problem. Thanks!

🇷🇴Romania bbu23

@kerrymick in this case, please describe the exact steps to reproduce your case, and when I get the time I'll check. Thanks

🇷🇴Romania bbu23

Did you clear the caches after applying the patch? @the_turk

🇷🇴Romania bbu23

Update outdated information after 4.0.1 release.

🇷🇴Romania bbu23

Hi, thanks for reporting this. We noticed issues with Views just recently. Could you please confirm that this is happening with Views only? Thanks

🇷🇴Romania bbu23

Patch files are no longer recommended, use merge requests instead .

Added the proposed patch to MR, and fixed small coding standards.
Tested and works as expected.

🇷🇴Romania bbu23

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

🇷🇴Romania bbu23

I have provided a fix for this, thanks again for reporting this issue.

We made a small typo mistake when porting from version 1 to version 2. Please try out the patch and let us know if everything okay now.

Regarding the Proposed steps, 8 & 9 are not necessary, but of course can be tested. This bug can be reproduced for any entity reference, and in this particular example after step 7 the block can be added directly to the block layout and will have the same behaviour.

🇷🇴Romania bbu23

Update outdated reference

🇷🇴Romania bbu23

Update outdated information after release 4.0.1

🇷🇴Romania bbu23

Update outdated information after release 4.0.1

🇷🇴Romania bbu23

Update remaining information after release 4.0.1

🇷🇴Romania bbu23

Start replacing outdated information after release 4.0.1

🇷🇴Romania bbu23

Though from your screenshots it might look like the keys are empty, so yes, in that particular case, the cache keys array will only contain the same key for all which is incorrect. Makes sense, I'll investigate.

🇷🇴Romania bbu23

Hi,

Thanks for reporting this issue, I'll try to reproduce it when I get the chance.

The cache keys is an array of parts. In the case of node, a example is "['node', 5, 'teaser']". This means that the teaser representation of the node will be cached, but in Swiper's case it was a conflict because swiper is altering the representation. By adding the "swiper-slide" key we are creating two different "cache keys" depending on the scenario. And in theory, they are supposed to be unique. Randomising is not an option, so I first need to try to reproduce your scenario and investigate what happens to understand better.

More information about the original issue here: https://www.drupal.org/project/swiper_formatter/issues/3395406 🐛 Swiper formatter fails to wrap row in swiper-slide div intermittently Active

Production build 0.71.5 2024