Thank you for your contribution!
dcimorra → created an issue.
New functionalities have been added to allow the module to communicate with the information contained in the Solr cluster.
By retrieving this information, the module is able to detect which collections have been configured for an alias and thus run the luke against all of them, retrieving all the fields that exist after an alias.
“This is necessary because Solr by default consumes the schema information of the first collection, skipping the rest.”
The above functionality has been unchanged.
dcimorra → created an issue.
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.