Out of the box they would be considered duplicates. But you can write your own plugin that would take into account both the file hash, and the geolocation data.
The plugin system that does the duplicate detection takes the entire Media object. You'd be able to write a comparison plugin that addresses your needs and use that instead of the default.
At that point, the standard duplicate detection response would kick in. It doesn't give you all the options in your issue, but it does tell you which media item is conflicting, so you can go an update it if required.
Does this solve your issue?
I believe this is ready for review.
nterbogt → created an issue.
nterbogt → created an issue.
@mparker17 I'm pretty sure this bug affects elasticsearch_connector also.
nterbogt → created an issue.
Available in next release.
Initial code is complete and awaiting review.
This has been outdated by ✨ Drush improvements Active . While it doesn't specifically address the issue; the entire architecture has changed and if this is still required we can start again on the changes.
nterbogt → created an issue.
I feel this is a self-created issue. While I agree that taking over the namespace of an existing package is a supply chain issue... the package probably shouldn't have existed in the first place. The underlying problem is that pseudo packages were created (that actually work) rather than a "This is not the package you seek" type response.
I think it's worth discussing changing the way it works now, rather than letting the problem get worse over time.
Cross posting a possible solution from another issue discussing the same problem.
After doing some research into the composer schema, would it not be better to use "abandoned": "drupal/[submodule]" in submodules, suggesting the main module? This would allow a user to find submodules through composer, but also guide them to installing the package correctly. And when a submodule is moved out, it can become a 'real' package and override the abandoned definition.
I do find this counter intuitive that Drupal.org allows me to create a top level project that conflicts with the namespace of a submodule in composer.
The current solution is that the new project gets the namespace drupal/data_pipelines_elasticsearch-data_pipelines_elasticsearch in my example.
Would it not be more intuitive if the submodule got drupal/data_pipelines-data_pipelines_elasticsearch in my example? I assume there is an underlying package manager reason why we need it in the first place; but I can't see it magically causing an issue on an existing site without the developer actually running composer require [package].
We needed to split out the module to support two different APIs concurrently, depending on the site, so there are valid use cases for doing what I did to the modules.
nterbogt → created an issue.
Will be available in the next release.
nterbogt → created an issue.
This is now fixed. It will be rolled out in the next release.
Can I please have a review of this one?
Closing issue.
Adding contributors from previous issue.
Issue has migrated to ✨ Allow analyzers to be specified for elasticsearch pipelines Active .
nterbogt → created an issue.
kim.pepper → credited nterbogt → .
nterbogt → created an issue.
nterbogt → made their first commit to this issue’s fork.
The original changes were merged. What is in the MR now is a duplicate of another issue project bot created.
This conversion is complete. Should unblock the submodule creation for elasticsearch and opensearch... or at least reduce the amount of rework we have to do in the future.
nterbogt → created an issue.
This is ready for review.
nterbogt → created an issue.
The module supports views. You can override the path with a view of your creation, with your own filters. That's how we use it.
I'm happy with the changes. The remaining phpstan issues are fixed by 📌 Automated Drupal 11 compatibility fixes for data_pipelines Active .
nterbogt → created an issue.
This ticket is best placed on the admin_toolbar module rather than core.
That said, you can't currently override a deriver as far as I'm aware. The code to do that doesn't exist, see ✨ Allow base plugin definition to be altered before derived Active .
You can however override the menu links by using a module hook. Here is an example from our codebase.
/**
* Implements hook_menu_links_discovered_alter().
*/
function MY_MODULE_menu_links_discovered_alter(&$links) {
foreach ($links as $route_name => $link) {
// Remove all the individual views from the menu.
if (\str_starts_with($route_name, 'admin_toolbar_tools.extra_links:views_ui') && !\in_array($route_name, ['admin_toolbar_tools.extra_links:views_ui.add', 'admin_toolbar_tools.extra_links:views_ui.field_list'])) {
unset($links[$route_name]);
}
}
}
Finished the changes. Not sure I have permission to create a merge request.
nterbogt → created an issue.
Deployed in release 1.1.0-rc1.
Merged to 1.1.x. Release to follow.
Can someone have a look over this. Should be no functional changes, just making the whole build pipeline green.
nterbogt → created an issue.
Tests seem to be running as expected on current versions of Drupal. Can re-open / create a new ticket if this comes back.
Agree. Created a 1.1.x branch for 10.3+ Drupal version support.
I've merged to 1.1.x for now... have to make a few other changes before I can roll a release. So will confirm if composer restrictions are working as expected.
larowlan → credited nterbogt → .
I ran this on a site with 31 entities and 1039 fields and it took 1.9 seconds on my local machine. I'm not sure this qualifies it as slow; it's certainly not slow compared to rebuilding node access as an example.
This has been merged and will be in the next release.
nterbogt → created an issue.
Merged. Sorry, forgot the commit message.
Will go out with the next release.
I agree with the sentiment behind this ticket; but not necessarily the implementation.
I'd like to see the code automatically leverage the cache `url.query_args` bubbleable metadata, so that implementing it correctly in a block or similar, automatically enables that argument in the page cache ignore.
I haven't quite worked out how to do that yet.
But both options have merit and it would be worth doing an analysis over which route should be taken (pun intended) :)
Merged and will be available in the next release.
nterbogt → created an issue.
nterbogt → created an issue.
Merged for next release.
nterbogt → created an issue.
This has been merged and will be available in the next release.
nterbogt → created an issue.
This has been merged and will be available in the next release.
nterbogt → made their first commit to this issue’s fork.
This has been merged and will be included in the next release.
nterbogt → made their first commit to this issue’s fork.
nterbogt → created an issue.
Merged to 1.x.
Merged to 1.x.
nterbogt → created an issue.
nterbogt → created an issue.
Is this still an issue? Can you confirm whether the fix recommended by pookmish solves the problem?
Closing this issue now.
Ready for review.
Ready for review.
nterbogt → created an issue.
nterbogt → created an issue.
nterbogt → created an issue.
Can we update the target branch of the merge request to 2.x please? I'm not sure how to do it or I don't have permission.