🇸🇮Slovenia @miha.wagner

Yes that makes sense. I've gone ahead and changed that. If the other filters will also be doing it like this then I thought it
made sense to do the preparing of the value in the base class. What do you think about that change?

I've added a test case to test with a $value of FilteredMarkup. Though this begs the question, if the value is being cast to a string via an explicit cast, maybe it would also make sense to check if the value implements __toString() or implements \Stringable in the canFilter method?

miha.wagner → created an issue.

Since the issue seems to have been resolved and this issue is inactive for over a year, I will close it. If this happens again feel free to re-open this issue or create a new one. Thank you.

This was fixed in https://www.drupal.org/project/amazon_paapi/issues/3286059 📌 Automated Drupal 10 compatibility fixes Fixed , thank you again RyanCMcConnell.

I've added a composite primary key on the entity_id, entity_type and asin columns, which combined do offer a unique value. This fixes the warning and will be included in the next release.

Thank you for the report.

This solution will almost certainly throw an error if there are several products integrated in the same entity. Primary keys need to be unique, and the 'entity_id' column is not meant to be unique.

Thank you for bringing this up, I'll take a look at what can be done about this.

Could not reproduce this issue, and no activity for more than one year so will close it.

I've added a .gitlab-ci.yml file, basically using Drupal's template for the Drupal Gitlab. Also added support for ddev-drupal-contrib for easier development, the setup for which is described in CONTRIBUTING.md.

Basically with the ddev plugin phpstan and phpcs can run with all the dependencies, as if the module would be installed on a Drupal site. Added a phpstan baseline file since fixing all the issues regarding that is out of the scope of this issue.

Additionally if composer install is run and the ddev instance created as described in CONTRIBUTING.md, pre-commit hooks will be run warning you of any issues before pushing, so as to not have to rely on the pipelines for this.

Think this is a good way to improve the developer experience, as now all work can be done in the repository, instead of needing to have a project ready and then e.g. doing the work by adding the module through composer from source.

Using all this is not required though and the developer can still choose to just change the code and commit, and be warned only when the pipeline fails, but the option to develop locally in a fully working environment is there.

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

miha.wagner → changed the visibility of the branch 3493189-timestamp-last-available to hidden.

miha.wagner → created an issue.

This is why I should have tested on a more plain installation. So the issue is when the 'route' cache context is added. Also probably when 'url.path' is added though I did not test this.

Create a basic article on the site. Then this request can be used:

{"query":"query MyQuery {\n breadcrumb(\n path: \"<path-to-the-article>\"\n ) {\n title\n url\n }\n}\n","variables":null,"operationName":"MyQuery"}

The breadcrumbs builder do add the 'route' cache context to the response. So triggering this will always invoke the sub-request, though it should only trigger it once.

miha.wagner → created an issue.

miha.wagner → created an issue.

I've created a merge request and added patch that fixes the issue. Maybe it would be better still to check if the value is an array, but since it's defined in the schema to be a sequence I considered that too paranoid.

miha.wagner → created an issue.

Hi @ciprian.stavovei I installed amazon_product_widget 1.5.10 on Drupal 10.1.6 and I did not get this error. Not on install or any of the configuration pages.

We are using the module on a pretty big site and didn't experience this also when updating to the 1.5.10 version. Because I can't reproduce it on a fresh install, or on an active site I'm downgrading the priority to normal.

Did you get this resolved? If so, how? Was it a caching issue? If not, does it happen on config import / install, drush en, or where do you get this error? Site-wide?

Thanks and have a nice day.

Fix has been commited to 1.5.x and will included in the next release. Thank you Shubham Rathore for your contribution.

This patch has been commited to the 1.5.x branch and will be included in the next release. Thank you Adil_Siddiqui for your contribution.

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

Can also confirm this is an issue on parents with several hundred children.