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.
kksandr → created an issue.
Thanks for the credit((
kksandr → created an issue.
Is there any hope that this issue will be addressed by the maintainers?
kksandr → created an issue.
kksandr → created an issue.
kksandr → created an issue.
kksandr → created an issue.
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
kksandr → made their first commit to this issue’s fork.
kksandr → created an issue.
kksandr → created an issue.
After this fix, a white background appeared on pages with small content height
Move changes from #71 to merge request
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.
kksandr → created an issue.
kksandr → created an issue.
kksandr → created an issue.
kksandr → made their first commit to this issue’s fork.
kksandr → created an issue.
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.
Fixed in Diff should typehint DateFormatter interface rather than a specific implementation 🐛 Diff should typehint DateFormatter interface rather than a specific implementation Fixed
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.
kksandr → created an issue.
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.
kksandr → made their first commit to this issue’s fork.
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.
kksandr → made their first commit to this issue’s fork.
@acbramley I hid all my unsuccessful attempts, sorry.
kksandr → changed the visibility of the branch 3336994-stringformatter-access-r5 to hidden.
kksandr → changed the visibility of the branch 3336994-stringformatter-access to hidden.
kksandr → created an issue.
kksandr → created an issue.
This merge request includes migration to Gitlab CI and standards bug fixes to successfully complete pipelines.
kksandr → created an issue.
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.
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've moved patch #18 to the merge request.
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.
Please add a new release with this fix.
Link to a stable alternative with Drupal 10 support: Year/month widget →
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.
Reroll for module version 1.17
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.
kksandr → created an issue.
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.
kksandr → made their first commit to this issue’s fork.
I moved the fix from patches to the merge request