@Gashunk, I added a empty() check so that this warning should disappear.
Thx - I fixed the documentation.
Without the patch a username in PhpRedis can be configured by using:
$settings['redis.connection']['password'] = ['user' => '...', 'pass' => '...'];
But it makes totally sense to have a meaningful wording, a consistent configuration and a reporting for PhpRedis and Predis - which the patch offers.
We have tested the patch with PhpRedis sentinel and it worked!
We tested with the old settings (see above) and the new settings (see below).
$settings['redis.connection']['password'] = '...';
$settings['redis.connection']['username'] = '...';
+1 RTBC
@Gashunk, Can you please merge 1.0.x into your branch to trigger the tests?
Harlor → changed the visibility of the branch project-update-bot-only to hidden.
I applied the suggested changes - this time using gitlab :D
I reverted to the variant with two parameters and interchanged the parameters.
@catch, @pradhumanjain2311, We need the $is_new variable because the status message is generated after $comment->save(); and the comment is no longer new.
Sorry, I forgot to interchange the parameters :S
Harlor → created an issue.
I merged 11.x into the MR's branch - and the tests succeeded.
Harlor → changed the visibility of the branch 3346218--patch-b83b to hidden.
Harlor → changed the visibility of the branch 3346218-d11-fix-comment-update-message to active.
I committed the changes as suggested ;)
Thx Guys!
Nice find!
I'd prefer that we just provide the created date on the node add form ;)
THX
The redis client does not necessarily have databases. For instance the redis cluster cleint ✨ Implement initial RedisCluster client integration Needs work does not have databases.
How ever with redis_flushdb=FALSE one actually does not need the DB index anyway - So I would suggest to move the redis index/DB safety checks and the ->select into the flushdb block.
Caching with the new redis cluster implementation seems to work fine on our Drupal 10!
Only the recently added flush logic ( 🐛 Currently Drush Cr or Cache Clear UI does not flush Redis cache Fixed does not work. If I am not mistaken there are no databases in the cluster implementation - so the check for the database does not make sense for redis cluster right?
Could one o the maintainers please specify what is missing to use the current state of this issue as a base for a CKE5 compatible version of this module?
@anfor, Yes it should be clear that this module only works with CKEditor 4.
But does it make sense to prevent users from using this module on Drupal 10 with the contrib CKEditor 4 ( https://www.drupal.org/project/ckeditor → )?
For those who want to try 2.0.1 with D10:
That's what I meant.
Oh this issue causes a Fatal on Drupal 10 :S
user_password() does not exist in Drupal 10 anymore.
I'm really surprised, that upgrade status did not report this.
The reasons seems to be that the function was found in UserPasswordFixture.php
The Draft MR currently contains changes that allow to push translations to the new REST endpoints of l10n_server ( https://www.drupal.org/project/l10n_server/issues/3395508 📌 New endpoints for l10n_client_contributor Needs review ).
The new concept for the authentication as described in https://www.drupal.org/project/l10n_client/issues/3395488 📌 Localize client authentication with d.o infrastructure Active still needs to be implemented.
Ah, I think understand what we're doing here. We're wanting to authenticate from random drupal sites to submit (as authenticated d.o users) translations.
Yes - That's the idea.
We certainly don’t want to be using keys which have access to authenticate as the user everywhere else on *.drupal.org. That would be unnecessary risk.
Yes - I hope we find a solution with have access-tokens/api-keys that can be used for the contribution endpoints authentication only.
Btw. we started working on the server endpoints:
https://www.drupal.org/project/l10n_server/issues/3395508
📌
New endpoints for l10n_client_contributor
Needs review
And the corresponding adjustments in the l10n_client:
https://www.drupal.org/project/l10n_client/issues/3395327
📌
Replace xmlrpc for new localize.drupal.org
Needs work
I manually tested these changes with a Drupal 10. And it seemed to work just fine!
Even though I made the last changes to the MR I set this to RTBC - my changes where purely cosmetic and coordinated with sanduhrs.
@mikegodin, THX for your help!
I asked one of the maintainers(sanduhrs) about this and w decided to bring back the deprecation annotations because these functions are not static in 2.x and 3.x.
I also moved the helper method from the tests to a trait so we don't need to duplicate it.
This looks good to me!
Maybe n1k wants to have a look too. But I set this to RTBC for now.
Is there a major issue with a Drupal 10 compatible 1.x version?
How realistic is it to have a stable Drupal 10 compatible release by end of Nov (d9 EOL)
If there are too many open issues with the 3.x version - is there a major issue with a Drupal 10 compatible 1.x version?
📌 Automated Drupal 10 compatibility fixes Closed: won't fix
A stable Drupal 10 compatible version of this module would be nice indeed.
Does anyone keep track of all the reported issues and whether they block a stable release?
Thx!
Back to RTBC
Sorry, I closed my obsolete MR.
@Kaushik1216 Could you please close https://git.drupalcode.org/project/drupal/-/merge_requests/3982? It seems that I don't have the permission to do that.
I'm not sure if the site_studio stuff should contain a UUID - I left it there for now.
Can we rerun the Jenkins pipeline?
Done
I couldn't figure out how the branch could be fixed so I created a new branch from 10.1.x and cherry-picked the relevant commits...
I also added the doc-block for the getStatusMessage method
We started working on a similar module for drupal 8+
LGTM
Sorry it seems the issue was caused by a config for an entity type that does not have bundles. Which is not supported - or is it?
I'm not sure if one should use the same sandbox parameter for all entity types. Using a different sandbox parameter seems to fix the issue: https://git.drupalcode.org/issue/entity_type_behaviors-3387281/-/commit/...
LGTM