🇺🇸United States @Fool2

+1 on #8, makes the most sense for this and follows the standard set in core

Fool2 → created an issue.

I know it needs rebasing so I won't change the status but I want to add my +1 as tested the diff as a patch and it works great. I was able, for instance, to create a view display where we pass UUID as an argument to match the relationship and plop it in the node edit form to show users quickly if a node has subscriptions:

views_embed_view('syndicated_content', 'embed_1', $entity->uuid->value);

Just a thought, what if we pulled in each channel item as entities and provided them to a view? Would it be too much overhead? Then sitebuilders could customize the import action completely and integrate it in many different ways.

Something like a "stub" entity or even an "Import status" entity for entities that haven't been imported yet.

Then the module could provide a default view (just like all the other views)

The stub could track uuid, remote, channel, title, and maybe last modification date on the remote. If we were to extend import status, we could also track the local relationship as well for imported entities. Then we provide the views plugins to access this entity and its relationships, we could rebuild the filters for the pull page as views filters.

This also has the opportunity to make the pull page asynchronous, so that the list of content has a manual "refresh" button where the stubs are imported via the remote channel feed(s)

This way, anyone could customize the UI by editing the view, they could create multiple UIs for different use cases, etc.

I don't see why not. My concern is that entity_import_status does not track the reference in a meaningful way. So in order to do this (whether in a different contrib module or not) we would need to:

• Figure out which references are attached to the deleted entity
• Figure out if any other entities reference that entity (should it only count published?)
• Perhaps add some metadata to the import status so it is clear what the current status is

There are several conditions that will make this not-so-straightforward, especially for some of the more advanced plugins like entities embedded in a wysiwyg instead of populating a reference field. I don't have confidence that unpublishing or deleting references will be 100% reliable, perhaps things would have to be more deliberately configured.

I am curious about this-- why is it better to keep the major version on 1.x and move the backwards compatible stuff to 2.x? I think that is backwards. A new major version should signify the breaking of backwards compatibility. Are there any other examples of modules doing it the other way? Does the official Drupal documentation support that strategy?

I made an issue fork so that we could include the patched version using composer for testing purposes, I did it by adding this to composer.json repositories

"views-evi-custom": {
            "type": "package",
            "package": {
                "name": "drupal/views_evi",
                "version": "1.1",
                "type": "drupal-module",
                "source": {
                    "type": "git",
                    "url": "https://git.drupalcode.org/issue/views_evi-3290469.git",
                    "reference": "3290469-automated-drupal-10"
                }
            }
    },

The suggested logo does not meet the requirements on this page:

https://www.drupal.org/docs/contributed-modules/project-browser/module-m... →

I tried to convert it and resize it and compress it but the gradient made it hard for the png algorithm to sufficiently compress at 512x512... got to around 50k at the smallest; it needs to be 10k.

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

We do have an element that has its own validation, feeds_uri but is the validator there enough? I can easily feed it garbage. Maybe we can set #allowed_schemes in the $form['source']? That way it can be limited not to access any local resources or other funky things? I am not an expert in what should be limited.

That being said, OPs url should be encoded. I do not think the url form element as it stands is converting those characters to urlencoded, it is just validating it. Your url should look something like this in the text field:

http://newapi.omnicasa.com/1.8/OmnicasaService.svc/GetPropertyListXml?js...

Have applied #332 to a dev site on 7.56 successfully. Fixed the immediate problem with my view that led me here (simple optional entity reference use case)

For future reference (and google-foo) the way I originally noticed this issue was that I was testing a view on two different browsers-- one logged in as admin and the other as a less privileged user, and suddenly the less privileged user was missing rows in the view when I added the reference. This is likely because admin user skips node access checks altogether.

The worst part about this bug is that I think I have run into it before and thought I was doing something wrong, causing me to abandon/change my approach to what I was working on. As others have stated it is hard to detect and non-intuitive. I am wondering if there is anything we can do to make this more likely to be committed to D7 core. If it cannot be committed to core, it might be worthwhile adding warnings/language or making mandatory the "require this relationship" checkbox when the conditions are right for this bug's behavior to emerge.