dcimorra → created an issue. See original summary → .
dcimorra → created an issue.
Thank you for your contribution.
The proposed solution is adapted to what was requested in the incident, providing new functionalities such as the log output format.
Once again, thank you very much.
Thank you stadoom for your contribution. It is already merged. I close this issue.
The requested changes have been resolved, thank you for taking the time to review my request.
I mark this issue as completed. Thank you very much.
Thanks for your contribución
dcimorra → created an issue.
Thanks for your contribution. Merged with 1.x branch.
dcimorra → created an issue.
Thank you for your contribution. Please use the “issue forks” system for future occasions.
dcimorra → made their first commit to this issue’s fork.
Hi, I just added a fork with the port to Drupal 10.
The module in this version only allows to make a massive flush of all image styles since by default in this version is already allowed to make an individual flush for each image style.
Thanks.
dcimorra → made their first commit to this issue’s fork.
Okay, I'll wait.
However, it does not seem reasonable to me that a module that is active in the community should be abandoned just because the person who proposes to maintain it is not included in the security advisory coverage.
The community gives life to Drupal.
dcimorra → created an issue.
Absolutely. I was looking for similar issues but did not find it. I didn't look hard enough.
Thanks for the heads up.
dcimorra → created an issue.
Thank you for your contribution.
dcimorra → created an issue.
dcimorra → created an issue.
dcimorra → changed the visibility of the branch 1.0.x to hidden.
dcimorra → created an issue.
dcimorra → created an issue.
Thank you for your contribution. Merged with 1.0.x branch.
dcimorra → created an issue.
Multi-entity support
My apologies, I am re-uploading the patch again. The dependency injection for routeMatch was missing. Patch attached.
Pending to PR. Meanwhile, the patch is attached.
dcimorra → created an issue.
This problem is caused by having applied the patch (in my case) https://www.drupal.org/files/issues/2023-10-30/2856720-support-for-inlin... → .
Removed the patch, it works correctly.
penyaskito → credited dcimorra → .
dcimorra → created an issue.
dcimorra → created an issue. See original summary → .
dcimorra → created an issue.
dcimorra → created an issue.
Merge with the development branch.
dcimorra → created an issue.
Yes, I think the use case that would be better understood would be when you have several portals and you want to be able to display the content of all of them in addition to the content of the portal through which it is accessed in the same view (as a general search engine), being able to maintain compatibility with the facets and the autocomplete search engine, so that when you click on each of them, there is a redirect that sends you to the original content or is retrieved through API to represent it in the portal itself as if it were its own content.
In other words, content syndication.
When you have a core solr configured that queries other cores through shards, drupal is not able to retrieve the schema fields of all of them because it only retrieves the fields contained in the core, which in this case is 0 because the core only queries the content of other cores.
The functionality that I propose to integrate retrieves these shards to retrieve the schema fields of each of the configured cores. The interesting thing at this point would be to be able to transform or map the retrieved fields directly from the shards to drupal entities, although I do not think this is possible.
Pull-request: https://github.com/mkalkbrenner/search_api_solr/pull/94
dcimorra → created an issue.
dcimorra → created an issue.
Preventing a role from not being able to be assigned the admin privilege does not limit it from not being able to be assigned permissions that can lead to security breaches. The administrator role, like any other permission has to be assigned with care, but removing it is not a solution.
The best solution, I think, would be to delegate the administrator privilege to that role, as proposed in the related issue 540008, and that only through this role, you have this privilege.
dcimorra → created an issue.
dcimorra → created an issue.
dcimorra → made their first commit to this issue’s fork.