🇺🇸United States @devkinetic

AFAIK setting 

$settings['cache']['default'] = 'cache.backend.redis';

will handle the location of the other bins, no need to explicitly define them.

Also see ✨ Create submodule to store PHP sessions in Redis RTBC

I'm not sure what exactly is the "correct" way to do this... on a recent project we simply did $settings['session_storage']['class'] = 'Drupal\redis\Cache\PhpRedis'; and it seemed to work pretty well! if anyone can provide a comparison or justification on the best approach, I would much appreciate it.

In general, for our project, which consists of mostly logged in users, we saw a ~600% increase in throughput under load between that setting and also adding $settings['session_write_lock'] = FALSE;. Managing sessions through Redis appears to be a boon for performance and it would be great if this got rolled into the "default" config and setup.

YMMV of course, as there are so many factors to consider.

I've been using my patch in production for 2 years with no issues, so I certainly support merging this in. A welcome addition before merging would be updating the linkchecker report to include this field by default instead of the existing entity link. This may require an update hook for existing installs

This is a upgrade blocker for D11 now.

Coming back to this, I don't disagree that the current implementation of only loading on specific pages is incorrect, and it does make the configuration more needlessly complex. I do feel that the premise is still valid though. The way JS in Drupal works normally is that assets are only added to the page when they are specifically needed, and it should happen dynamically.

I think that a new implementation should be planned out, whatever that may actually be. Currently, the assets are added to pages that do not require it.

+1 very relevant. This module currently uses custom headers, when in reality there are already standards in place for how API key auth should be setup in a request, and how the responses should be formatted.

I believe the true solution to this situation is two fold.

1. Roll in support for #3231779: Add support for Bearer authorization format →
2. When a user is not found, instead return a Symfony\Component\HttpKernel\Exception\UnauthorizedHttpException

For example:

if (!$key_auth instanceof UserInterface) {
  throw new UnauthorizedHttpException('Bearer realm(**YOUR-DOMAIN**)', 'Invalid consumer API key.');
}

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

devkinetic → created an issue.

The only other item cspell complains about is the drush command.

devkinetic → created an issue.

devkinetic → created an issue.

devkinetic → created an issue.

devkinetic → created an issue.

devkinetic → created an issue.

devkinetic → created an issue.

devkinetic → created an issue.

I haven't dug into this too much, is the container there for some type of ajax purpose? I also see this is already handled differently in 3.x where it returns an empty array, perhaps that would be the preferrable solution. I went ahead and applied the patch, so far in testing things are working, but I do have Bigpipe disabled for facets, if that's a potential factor.

Maybe instead of adding the file in the handler directly, we could leverage media via a reference field, and then grab the file how file_download_link does.

devkinetic → created an issue.

Version 2 to 3 of social_auth is primarily a switch to semvar. I've set the module accordingly in the composer.json.

devkinetic → created an issue.

devkinetic → created an issue.

I took another swing at this, rolling back the refactors while still addressing the issues. At this point, all that remains is the call to file_validate_extensions() but for that we should really just cut a new major branch for ^10.2 || ^11 support.

+1 working splendidly for me as well, thanks for this patch.

I made a pr that just falls back to the default functionality of \Drupal\image\Plugin\Field\FieldFormatter\ImageUrlFormatter if no use case was found to handle it.

devkinetic → created an issue.

I'm committed the patches to this point. Leaving open for continued updates.

devkinetic → created an issue.

devkinetic → created an issue.

This looks a lot like a duplicate of the following issues:

• 📌 Add Views EntityReference filter to be available for all entity reference fields Closed: duplicate
• ✨ Continuation Add Views EntityReference filter to be available for all entity reference fields Needs work
• ✨ Add Views EntityReference filter to be available for all entity reference base fields Active

IS updated and combined into single test.

I'm not sure exactly what you mean, there is nothing to patch on the UI side. My reply really only explains how properly construct your URLs. In the case of multivalue, you need to do something like this if your building your url from code:

// each integer is a entity target_id on the multivalue field
$x = [1, 2, 3];
Yaml::dump($x);

Which will produce the following YAML:

- 1
- 2
- 3

This can then be added as your query parameter, making the value of the token a urlencoded YAML string.

If your building your URL manually, you can do /node/add/article?field_multivalue=-%208%0A-%209%0A where the format is dash space VALUE newline dash space VALUE.

Here is also a patch against 10.3.x for anyone who needs it.

Updated the issue fork and rebuilt MR based on 11.x.

devkinetic → changed the visibility of the branch 3308432-the-link-on to hidden.

The patch in use is based on the issue fork, while the issue queue on 🐛 Invalid config structures can result in exceptions when saving a config entity Needs work has stopped using it and moved to posting patches. I tested #75 and it applies to 10.3.x. With that said we would need a D10.3+ release here as the composer.json needs to be updated.

This module uses YAML encoding. I was able to get multiple values working out of the box using something like this:

  $ids = []
  foreach ($entity->get('field_foo')->getValue() as $x) {
    $ids[] = intval($x['target_id']);
  }
  $route_options['query']['foo'] = Yaml::dump($ids);

This will produce a url like foo=-%208%0A-%209%0A where 8 and 9 are the values. On the EPP side it calls new Parser())->parse($yamlValue, ...); where is transformed back into an array.

The docs are severely lacking an example of how to do this. https://www.drupal.org/docs/contributed-modules/entity-prepopulate/entit... → only gives the hint of passing a one level array.

I second having to import the config twice, it's always drush cr; drush cim -y; drush cim -y.

This looks good to me, a simple but effective change.

I also ran into this. Adding the patch from 🐛 LanguageManager does not check against altered language_switch_links Needs review seems to help. I've not added the MR from this issue into my codebase. The issue only presents itself when logged out.

Furthermore, I've added a custom module the provides further link altering after this module, but found that I had to do two things to make it work:

1. Removed the typehinting within the function params. array &$links becomes &$links
2. Wrap my processor in a if (is_array($links))

So it seems that $links gets set to NULL instead of an empty array at some point by this module. As I said, I have not added this MR yest as it is not ready, but something to keep in mind when completing it, users may want to provide their own filtering afterwards!

function MYMODULE_language_switch_links_alter(&$links, $type, Url $url) {
  if (is_array($links)) {
    // custom code
  }
}

I ran into this bug as well, confirmed that the patch worked for me. I am also using "language switcher extended" module.

Thanks for the report. I've reviewed the patch and all looks well. marking as RTBC, and slated for merge.

I've put work into this topic over on 📌 Implement the current environment as a service and utilize plugins Active where current environment becomes a service and added a plugin manager to define the method of detecting the current environment. This way you can use whatever method you like, configure it, or even develop your own for more advanced scenarios. Unfortunately, it has not gotten any traction or feedback.

The pipelines are working correctly now, and I worked through the majority of the issues. I've also updated the issue summary with the remaining reported issues. What remains to fix could affect functionality of the module itself and warrants some real-world testing.

I've added the default gitlab ci file to the 2.x branch. Confirmed it is working now.

@james.williams I think I may have stepped on at least one of your changes from last night. I didn't realize you made a push before I applied my changes from local last night. Please review at your convenience.

Based on what is left, my major concerns revolve around the access logic and states where a method doesn't return anything. These could cause actual PHP errors and break the client side.

devkinetic → created an issue.

Thanks, this will improve the merge request process!

I've taken a first pass at the reported errors, and updated the issue description with what remains. I only updated stuff that should be non-breaking changes. What remains is mostly items that need to actually be tested in a working environment.

devkinetic → created an issue.

devkinetic → created an issue.

@james.williams Thanks for picking up the torch for this, glad my initial port is getting some love! This looks great so far. Couple of bigger picture things:

• We should cut a new branch using the new semvar format, deprecating the 8.x- prefix. Work there from now on.
• The new work needs to validated through coder/phpstan/phpcs.
• The next release should comprise of the above, and the 8.x branch should be set as unsupported.

I ran into this as well on a recent upgrade from Drupal 8 -> 9 -> 10. We ended up having to do a full database audit and found multiple issues, Before doing so we attempted the entire upgrade again so there is absolutely something missing in the upgrade path:

• batch table
  • missing primary keys
  • missing indexes
  • missing auto increment on bid
• block_content table
  • missing primary keys
  • missing indexes
  • missing auto increment on id
• block_content_* tables
  • missing primary keys
  • missing indexes
• some cache_* tables
  • missing primary keys
  • missing indexes
• users table
  • missing auto increment on uid

We solved the issue with the audit, and fixing the schema manually. I saw the referenced error about the users table, and can confirm that that update was ran but didn't fix things. I guess something to look out for when upgrading!

I just tested my previous patch against 4.0.17, which no longer works. Upon inspection, it seems to have been resolved by 🐛 Fix GIN Admin Toolbar Style: Secondary toolbar is overlapped by the 3px of the indicators border-top Fixed which I think this item is now a duplicate of and can be closed.

I have as well. This desperately needs a D10 release. It is the only item in my project without one, and has had 2 years to release these very basic fixes.

"repositories": [
        {
            "type": "vcs",
            "url": "https://git.drupalcode.org/issue/views_cm_current_state-3290445.git"
        },
        ...

composer require drupal/views_cm_current_state:dev-3290445-automated-drupal-10

I'd prefer to not bundle these changes together. The logger change should be a separate issue, and it should also use dependency injection.

Change record: Access checking must be explicitly specified on content entity queries →

Welcome and congratulations to @isholgueras! Thanks for opening this up in the first place to keep things rolling @e0ipso. Looking forward to getting this queue cleaned up.

devkinetic → created an issue.

Yes you are correct there is no field widget defined for IEF. You can try to create the file in the src folder and extend the existing widget. It's probably a lot like the others.

With that said I will create a branch for the work. But one thing I wanted to do was configure tugboat so it's easier to develop for all. I will try and do that tomorrow so we can get a test environment setup.

For anyone needing to upgrade to D10 now, I have created a fork on github drupal/field_label_plurals. It's just the latest 1.x with this patch applied.

"repositories": [
  {
    "type": "vcs",
    "url": "https://github.com/devkinetic/field_label_plurals"
  },
]

composer require drupal/field_label_plurals:dev-8.x-1.x

That is totally fine. It just had not been mentioned yet, and I assumed there were a few things needed to accomplish the migration that might warrant a ticket.

If I find some time I might take a crack at the simple stuff like documentation, updating the relevant files from the library, etc. I just started yesterday so I am not super familiar with this module or Splide itself.

With that said, rather than commit this to 1.0.x, it might be good to cut a new dev branch, and update this ticket so MRs will go against that instead.