@davps

Unfortunately, there is no convenient way to use sorting programmatically in custom queries.

The correct solution would be to add a custom tag to the query and modify the original query in it by adding sorting. The current sorting logic you can check here https://git.drupalcode.org/project/nodeorder/-/blob/3.x/src/NodeOrderLis...

We need to re-check this case to confirm problem on 3.x

I rechecked the described behavior on version 4.x and it looks like this problem is no longer relevant for the latest version of the module.

I checked on another provider, not on Facebook

1. added a second language (Spanish)
2. went as a user (anonymous user) in incognito mode to the site and switched to Spanish
3. clicked on the social network icon in the social auth block
4. logged in to the social network
5. the user was returned to the site in Spanish

Perhaps the problem may be relevant for 3.x. or older versions.

Yes, @adinan cenci described the essence of the problem.

I will assign the issue to myself and try to prepare a solution.

@svena, feature added to 3.0.2. Update the module to the new version and you will be able to configure it through the settings

Glad to hear that. Thanks for the feedback.

@svena, there is no such possibility. The only solution at the moment is to override the NodeOrderListBuilder with your own and add custom fields there.

Check these methods:

• \Drupal\nodeorder\NodeOrderListBuilder::buildRow
• \Drupal\nodeorder\NodeOrderListBuilder::buildHeader

There is an issue in the core that is not resolved yet ✨ 3rd-party should be able to alter the EntityListBuilder rows Needs work .

Technically, as a temporary solution, I can add hooks that will allow data modification.

@virginiegodfrin, this is strange behavior. I'll re-check this issue and come back with updates soon.

I did a dirty hack in the NodeOrderListBuilder.php on row 127.
$paged_query->limit(300);

@svena, yes, this hack works.

I saw the proposal for 8.x #3132575: Allow users to set max number of entities to prevent pagination → , I think it's time to prioritize this task and add this feature.

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

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

@kknoer, these changes provide access to the client and allow alter client's config in custom modules.
Check this issue ✨ Add referer header for Algolia API restriction Closed: works as designed , an example of use here #3133304-6: Add a way to access the algoliaClient → .

In the mentioned task, we are updating the used SDK.

The code style is not a problem of the current task. I partially fixed some of the errors in this task, the rest can be fixed in other issues.

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

Same problem as in the 🐛 Subscribers list table not showing all columns Active .

Let's discuss the problem in the 🐛 Subscribers list table not showing all columns Active . I'll close the current task as a duplicate.

@kubrt,check the comment #3471052-2: Subscribers list table not showing all columns → , maybe you can provide details.

This happens if there were problems importing/updating the views.view.simplenews_subscribers.yml configuration.
A simple solution is to re-import the views.view.simplenews_subscribers.yml configuration.

Can you describe in more detail what caused the problem?

I added a basic implementation and one operation "Delete subscriber" for example.

We need to discuss what other operations are needed. Maybe new operations can be done in other tasks so as not to block the current one.

davps → created an issue.

Results with fixes

Same behaviour when trying to translate field simplenews_issue for Newsletter Issue content type: /admin/structure/types/manage/simplenews_issue/fields/node.simplenews_issue.simplenews_issue/translate

davps → created an issue.

The problem here is related to the version of PHP and Drupal9.

It looks like you have a version below 8.0 because trailing comma in parameters list is only available since PHP 8.0.

According to the documentation, starting from Drupal 9.1.0 you can use PHP 8.0 - https://www.drupal.org/docs/understanding-drupal/how-drupal-9-was-made-a... →

I'm returning it back to the status "needs work" because the tests are failing - https://git.drupalcode.org/issue/simplenews-3477438/-/jobs/2896810

@berdir, the example with nodes is not appropriate here, since the modules with which the node has integrations are part of the core and are installed explicitly when the core is installed.

I'm just saying that it's bad practice to do this in contrib modules and with semver versions. If you as a maintainer don't see anything wrong with this, then none of this matters.

@berdir,

Plugins and tests aren't mandatory. Dev dependencies specifically exist to run tests.

Regarding the use of dev dependencies fo autotests, I can agree, since tests are not launched on production, but regarding plugins - I don't agree.
The module provides a plugin for integration with drupal/monitoring and does not specify the drupal/monitoring as an explicit and mandatory dependency. Running composer install with --dev on prod is bad practice.

A more correct solution here would be to move this integration to a submodule and specify an explicit dependency on the module for the submodule.

Dropping D9 is also not a major change and can be done in a minor release. D9 is long EOL

This is about the 4.x branch, not the core. If we drop supporting d9 for the 4.x branch, then only 3.x branch will be compatible with d9, but based on description on the main page of the module, 3.x will not be supported anymore - It is not receiving new fixes.

Now back to 4.x. Considering that support for Drupal 9 is currently declared, many users may be using the 4.x version on Drupal 9, and after dropping support in a minor release, users will face the problem that they will not be able to upgrade to the new minor version due to core and code incompatibility.

Now let's see what semver (https://semver.org/) tells us.

Given a version number MAJOR.MINOR.PATCH, increment the:

...
MINOR version when you add functionality in a backward compatible manner (
...

As a result, we get that any minor release within a major version guarantees compatibility, otherwise it is a major change.
Of course, we can do what we think is right for the contrib module, but that does not mean it is a good approach.

In any case, these are just recommendations, let the maintainer decide what solution he wants to see.

A very strange story with the module drupal/monitoring. The module is specified as a dev dependency, but there are places in the code (plugins, tests) that need this module, which makes it mandatory to use.

We need to decide what to do with this module.

If we specify it as a mandatory dependency, we will be blocked by 📌 Automated Drupal 11 compatibility fixes for monitoring Needs work and we will need to wait until it becomes compatible with the d11.

If we leave it as a dev dependency, we will need to remove all places related to it.

@adamps, are you sure that you want to drop supporting for d9? This decision looks more like a major change and then it will be necessary to support 3.x branch (port patches from 4.x to 3.x) and if you look at the statistics, 3.x is needed for 6k users.

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

MR's branch reset to last stable commits and rebased on to 4.x. Ready to review.

Codebase updated. Ready to review.

Code base updated. Ready to review.

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

These changes can be merged after 🐛 Fix tests for 4.x branch Active

I added the scheme. Other tests are fixed in the 🐛 Fix tests for 4.x branch Active .

davps → created an issue.

Quite a long time has passed since this issue was opened and it is no longer relevant today.

For Drupal 9.3 and newer versions, I recommend using CKEditor 5 provided by default in the core.

@nemanja grubic, have you read the comments in #3306633: Turning off index in local environment will remove all indexed data that already exists → ? Have you tried the suggested solution in the comment?

Could not reproduce the issue in either 4.0.0-alpha2 or 4.0.0.

@freelylw, need more information and try checking again in 4.0.0, maybe the issue will no longer be relevant.

@adamps, we can use own access plugin for views. MR !66 contains this solution.

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

MR !64 contains the proposed solution. These changes applicable to 3.x and 8.x-2.x branches too.

davps → changed the visibility of the branch 3472814-broken-subscriberlink-views to active.

davps → changed the visibility of the branch 3472814-broken-subscriberlink-views to hidden.

davps → created an issue.

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

davps → created an issue.

@fjgarlin, you were right. The problem was related to the errors reported by phpstan

All jobs are green and passed now.

Comments on changes:

- default_argument_skip_url: *
The Views setting default_argument_skip_url has been removed since version 10.2.0 - https://www.drupal.org/node/3382316 →

Test was run in child process and ended unexpectedly
The reason why the tests failed was because the test couldn't include the module due to a change in the constructor parameter declaration - https://git.drupalcode.org/project/domain/-/jobs/2511587#L57

	scanDirectories:
		- ../../../../vendor/drush/drush/src-symfony-compatibility

Fix for https://git.drupalcode.org/project/domain/-/jobs/2511587#L47

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

I looked at the code and decided to refactor it.

MR !106 main changes:

1. Methods getSelectedDomainId and getSelectedLanguageId strictly return NULL or a non-empty string. Both for the language and for the domain, an empty string is not a valid case.
2. Rewrote the code for getting data from a request or session to make it more readable, based on the current solution.
3. Added tests.

davps → created an issue.

Nice catch, @hanoii. LGTM, moving issue to RTBC status.

davps → created an issue.

davps → created an issue.

I think it would be nice to add token's scopes validation to the module. The minimum set of rights (scopes), as it seems to me, should be as follows:

• search
• addObject
• deleteObject
• listIndexes
• recommendation (autocomplete?)

@VasyOK, it looks like your API key doesn't have permission to delete objects from the index.

Check access control list (ACL) here - https://www.algolia.com/doc/guides/security/api-keys/#access-control-lis...
You can manage api key's ACL here - https://dashboard.algolia.com/account/api-keys/restricted

@radheymkumar, you shouldn't install algolia/algoliasearch-client-php separately.

You must install drupal/search_api_algolia via composer and the library will be installed automatically.

The 8.x branch is outdated. You can use the 3.x tag and it is compatible with Drupal 9.

@ivrh, they don't want to add a custom header to the default client config and that makes sense - https://github.com/algolia/algoliasearch-client-php/pull/713#issuecommen....

They suggest modifying the config for the client and this is a good solution. We need to wait for 📌 Add a way to access the algoliaClient Needs review and then we can use the hook alter to add own headers in custom modules:

use Algolia\AlgoliaSearch\Config\SearchConfig;

/**
 * Implements hook_search_api_algolia_search_client_config_alter().
 */
function my_module_search_api_algolia_search_client_config_alter(SearchConfig $config) {
  $config->setDefaultHeaders([
    'Custom-Header' => 'any value',
  ]);
}

MR !27 contains changes that allow altering the search client configuration. Now we can use hook alter. Here is an example:

use Algolia\AlgoliaSearch\Config\SearchConfig;

/**
 * Implements hook_search_api_algolia_search_client_config_alter().
 */
function my_module_search_api_algolia_search_client_config_alter(SearchConfig $config) {
  $config->setConnectTimeout(15);
  $config->setDefaultHeaders([
    'Custom-Header' => 'any value',
  ]);
}

@hongqing, can you check if the problem is repeated with branch 2.0.x?

If the problem is reproducible, please write steps to reproduce it, as I can't reproduce the problem on 2.0.x branch.

This issue is outdated. All Drupal 10 compatibility fixes have been merged into the 2.0.x development branch.

This issue is outdated. All Drupal 10 compatibility fixes have been merged into the 2.0.x development branch.

This issue is outdated. All Drupal 10 compatibility fixes have been merged into the 2.0.x development branch.

This issue was fixed in 🐛 SwitchForm compatibility with Drupal 10 Fixed

This issue was fixed it this commit https://git.drupalcode.org/project/domain/-/commit/fb5aa79ea6377efe000d5...

Updates on this issue:

• deprecation in SwitchForm was fixed in 🐛 SwitchForm compatibility with Drupal 10 Fixed
• deprecation in domain_source.module was fixed with refactoring in 🐛 Fatal error trying to display Domain Source field on node with no domain Needs review

The last deprecation remains. The proposed changes look good, but I would rather suggest refactoring the method, given that there is a comment that the method requires refactoring.

@agentrickard, what do you think about this updates?

This issue was fixed in 📌 Configure and fix Eslint issues Fixed

The issue was fixed in https://www.drupal.org/project/domain/issues/3457913 📌 Fix GitLab failures Fixed .

@agentrickard, I updated the merge request and resolved the conflict. Ready to review.