If this issue is resolved only by requiring external systems, I agree with @fgm to not mark this as duplicate.
The module shared by @codebymikey in the comment #29 implements some of the ideas from here, and can be augmented with other ones.
Listing some of the ideas gathered here so far for a quick recap:
- work within an early http.middleware service.
- ensure a consistent order for the query parameters.
- ignore query parameters based on an allow/disallow list.
- read this allow/disallow list set by the routing definition, gathered by a Routing listener service into KV records for quick checks.
- perform a single (1 per request?) preemptive (DB table size [better IMO] OR rows count) check before inserting an item into the cache, and (ignore until the next cron run OR prune) if full, instead of pruning AFTER the limit was exceeded.
- partial pruning using a popularity index, instead of the current max rows approach.
Maybe some of them have been addressed in the recent core releases.
Hello. :) The updated fix looks good for me. Much simpler indeed. :D Many thanks for the hard work.
Tested on 10.3.7.
I confirm this does not happen with ckeditor5 from Drupal's core.
It happens with the contrib module ckeditor, the one created temporarily for the migration between cke4 and cke5.
My advice is then to enable the core ckeditor5 module, then switch all your text formats using the old editor to CkEditor5.
If you have errors when saving the text format, you may need to update your contrib modules which provide plugins for ckeditor.
dakwamine → created an issue.
Updated patch #101 due to $this->entityManager that should be $this->entityTypeManager instead in CommentManager. This blocked search_cron, thus blocking remaining cron hooks. The fix in interdiff was tested on 10.3.7.
I tried to update the patch #99, but it was based on another code base (older core), so I focused on the latest patch only.
Partially fixed in 1.6.0-rc0.
Fixed in 1.6.0-rc0.
dakwamine → created an issue.
dakwamine → created an issue.
dakwamine → created an issue.
dakwamine → created an issue.
dakwamine → created an issue.
Symfony 6 compatibility issue was addressed in 1.5.1-rc11.
Fixed issues about the limit parameter handling which caused error logs and incorrect limit value use.
Hello, I also have the same issue on 8.x-7.0-alpha3.
When using cloud.elastic.co, the only way I could connect to it using the official elasticsearch client is by using the elastic cloud ID + API key.
Documentation for context: https://www.elastic.co/guide/en/elasticsearch/client/php-api/current/con...
This is a strange issue because we can connect on the cluster from the browser by Basic authentication, but not from the official client unless we use the API key authentication method.
This one is a fix over the field deduplication during the query building. Before, the deduplication resulted in ES returning an error about invalid string key. This happens when two fields of the same "source field" are retrieved, and only when they are not placed at the end of the field list, causing a "hole" in the index: key 0, key 1, key 2, key 4.
By reindexing the array, it makes the query work again.
This one contains the fixes from #21 about the timestamp fields.
The attached patch is the #18 + the patch #19 made compatible with PHP7 (replaced str_starts_with with strpos).
I made a side patch (i.e. use it on top of the base patch you are using) which fixes a bug about the date field views plugin, especially when a non timestamp value is indexed (like strict_date_optional_time). When not using this patch, views fails to render the results when a non timestamp date is offered to the views plugin.
The patch worked on 8.x-7.0-alpha3 with the #13 base patch (it should work on other base patches).
@ralphvdhoudt I see a removed file in the interdiff of #19. Was it intentional?
We've detected an incompatibility with Symfony 6 due to the change to the default value argument handling in $request->query->get(). ("only scalar types are allowed" error)
This should be addressed for D10 compatibility.
Dakwamine → created an issue.