Account created on 8 March 2022, over 2 years ago
#

Recent comments

I believe that in any case we should override the pager with parameters from the EntityReferenceSelection plugin.

And the implementation of what is described in the problem will cause confusion for users who want to determine the limit of results at the widget level.

I opened a new merge request that solves the problem where if a view doesn't have a pager set, all results are displayed.

#54 appears to have dropped a good portion of the original patch

And this removal brought back the problem when the pager is not set, in which case the view returns all the results, instead of the specified limit in the widget.

Is there any hope that this issue will be addressed by the maintainers?

and adding information about installing the patch as a reference to this version of the module on the module page.

The library bug "patrickbussmann/oauth2-apple" has been fixed, so you don't have to worry about patches

After this fix, a white background appeared on pages with small content height

This module does not restrict access to private files, but only adds another option for accessing private files. This is the idea following from the implementation. In your case, it is better to find another solution.

I'll close this in favor of this " #3443946 Switch to Gitlab CI Switch to Gitlab CI Needs review " fix, it fixes the tests and enables the switch to Gitlab CI.

You can easily override the Drupal session factory via *services.yml to the Redis session factory (a component that Symfony provides).

services:
  redis.client:
    class: Redis # Your Redis client class.
    factory: [ '@redis.factory', 'getClient' ]
  session_handler.storage:
    class: Symfony\Component\HttpFoundation\Session\Storage\Handler\RedisSessionHandler
    arguments: [ '@redis.client', { prefix: 'drupal_session:' } ]

I'm not sure if there are any downsides to this approach. If not, then mentioning this feature in the README would be helpful.

kksandr changed the visibility of the branch 3440045-add-gitlab-file to hidden.

kksandr changed the visibility of the branch 3384228-remove-chosen-js-support to hidden.

Can it be explained why this code needs to be removed?

The if (... || $target.attr('autocomplete') == 'off') condition was added to support "chosen-js" here #3211296 . This broke jQuery Datepicker as it has autocomplete="off" and this was solved by adding another condition if (... || ($target.attr('autocomplete') == ' off') && !$target.hasClass('bef-datepicker')) here #3224329 .

Therefore, removing support for "chosen-js" allows you to remove these additional conditions. I cannot write a more detailed explanation.

I added a new version of a module that is used on my sites to the merge request (2.x branch).

This version is compatible with version 4 of Social Auth; to work, you also need to install a patch for the patrickbussmann/oauth2-apple library from here https://github.com/patrickbussmann/oauth2-apple/pull/47 (patch). I would be glad if someone joins in solving the problem in the library.

composer.json is written according to the template from here .
README.md is written according to the template from here .
GitLab CI/CD is also configured.

Minimum requirements for Drupal ^9.5 || ^10, and the minimum PHP version is 8.0.

I suggest posting it as a separate alpha version 2.0 to start distributing and adding information about installing the patch as a reference to this version of the module on the module page.

This is a global problem for all dialog boxes in which the content is not a form element, which themselves are indented.

Setting indents for each such form is a bad solution; we need to solve the problem for all dialogs of this type.

This is a core library issue 3418863 🐛 Setting width for sticky-header is broken Fixed for the sticky header. You can try a patch from there and help solve the problem in the kernel.

This merge request includes migration to Gitlab CI and standards bug fixes to successfully complete pipelines.

Apart from some minor trouble in the patch

The solution you quote is already used in this module. The patch just moves this string constant into a class constant for easy reuse.

This issue is still relevant, I have opened a merge request for the current version of the module.
I also added a test that reproduces the problem.

I would like the module to move to Gitlab CI or fix Drupal CI for automated testing.
Because the default tests fail via a deprecation error:

---Errors---
You are using the deprecated option "--no-suggest". It has no effect and will break in Composer 3.

Yes you can do it with this module.

You need to create a link to an unoccupied path.
The path /node is already occupied by the Frontpage view from the core.

You can use any other path, for example /front and set in "Basic site settings" as "Default front page".
Next, you must add paths to "Redirects" that have access restrictions by role. For example, different views with a configured role restriction.

No need. Testing version 3 occurs in the phpunit test by default, since the latest version itself is installed from the development dependencies.
Two (^1, ^2) additional runs of phpunit lower the version to 1 and 2, respectively.
I left a note about this in .gitlab-ci.yml

kksandr changed the visibility of the branch 8.x-1.x to hidden.

I think this question should be closed as a duplicate in order to concentrate all efforts on one thing.

  • In issue #3306677 Intercompatibility with Group module new versions Needs work , all patches are already posted as merge requests, allowing for automated testing.
  • In the same patch I see the use of the extension.list.module service to determine the version of the group module, but this service is still considered internal and it may change ( #2940481 ).

I added support for group version 1 in merge request #20. That is, it now supports all versions of groups.

Does anyone have any ideas on how to cover this with tests? That is, run tests with different versions of groups.

Having looked at the group code, merge request #20 should work fine with groups 2 and 3.

The only difference between versions 2 and 3 is the machine name of the relationship entities: group_content -> group_relationship.

The group integration from #20 uses the GroupRelationship (2, 3) class, the group_relation_type.manager (2, 3) service, and the group entity method addRelationship (2, 3). All of them are in versions 2 and 3. That is, the machine name is not used directly to load relationship entities.

I moved the latest patch to the merge request. Also fixed a bug due to which allowed_values_function was not called, since the values were taken directly from the configuration, and not through the options_allowed_values function.

Since the maintainer never responded, I forked this module and added Drupal 10 support.

You can find it here: Year/month widget

To quickly switch to using the new widget, replace the widget's native name date_month_widget with year_month_widget in your configuration and import it.

I've opened a merge request that fixes the schema.

To solve this problem, the module should provide a configuration schema for its translatability.

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

Perhaps you are talking about this problem? Primary local tasks not rendering on entity routes due to striptags filter 🐛 Primary local tasks not rendering on entity routes due to striptags filter Fixed
I rebased the changes from the current development branch and my action block returned:

@genius.ha could you please explain your answer? If my proposal does not suit you, I will find alternative solutions.

Thanks for the answer. However, I was able to solve my problem even without removing this code.

Since the comment is outdated, the solution is not relevant and the problem can be closed.

The active link is more highlighting with background color.

This is not a fix, but an improvement. I restored it to the way it was before the breakdown.
I think design changes should create a separate issue.

Production build 0.69.0 2024