🇬🇧United Kingdom @Leo Pitt

Leo Pitt → created an issue.

Leo Pitt → created an issue.

Updated patch attached.

Thanks, new patch incoming.

Hi,

Sorry for the lack of reply. I contributed this issue while deeply involved in a project using Custom Elements, but I have since started on different work and so it hasn't been on my radar for a while.

I'm afraid I cannot remember why it was necessary to create an OEmbed Processor, as it's been a few months since I worked on this.

fago, I'm fine with your proposed option. If anyone else has a requirement for this, then they will be able to find and resurrect the issue.

Thanks

Patch attached:

• Add a scrub_fields field to module settings form.
• Pass scrub_fields to Rollbar init() method.
• Minor refactoring init() method for efficiency.

Leo Pitt → created an issue.

I find this confusing. So is hook_deploy_NAME() going to be added to Drupal core (as opposed to drush only)? And if so, does anyone know the issue where this is being addressed?

Patch included.

Leo Pitt → created an issue.

Additional patch attached for 8.x-4.2

Patch attached for 8.x-4.x-dev

Leo Pitt → created an issue.

Patch attached to work around this issue:

• Created a service to provide reusable methods.
• Replaced bulk of Onsite->getSagepayConfiguration() method with a call to the getSagepayConfiguration() in the new service
• Use the same service and method in CommerceSage->Secure3DBack() instead of the missing getPaymentConfigurations() method
• Also replaced some calls to address object properties with calls that use the dedicated address getter methods

Leo Pitt → created an issue.

Adding myself to Creditors on this as I raised the issue, wrote the ticket, advocated for it when it was initially declined, and suggested a solution :) E.g. "Creating a well-written issue that describes a problem" + "Proposing a solution (either in the form of a patch, or a text comment)"

https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →

Leo Pitt → created an issue.

Leo Pitt → created an issue.

@fago @mostepaniukvm

- entity_reference field items rendered as links by DefaultFieldItemProcessor similar to core's definition

I don't understand why we would by default render entity_reference items as links. Would it not make sense to render them according to whatever display settings have been chosen for the entity?

So, if my entity_reference field is configured to display the entity as a link, then render it as a link. But if I've configured it to render the referenced item as the full/teaser entity, I would expect it to be displayed as such, and not as a link.

I would expect this (entity_reference fields to respect the display configuration) to be quite a common requirement, and so something that one might expect to work "out of the box".

What do you think?

Please see updated patch attached. I have renamed the Processor to "EntityReferenceRevisionsFieldItemProcessor", as suggested.

@mostepaniukvm
I have been thinking about this some more.

It looks like there are three Processors for entity references that work in more or less the same way:
* ParagraphFieldItemProcessor.php
* EntityReferenceRevisionsProcessor.php
* MediaReferenceFieldItemProcessor.php

As discussed upthread, we could replace the paragraph processor with the more generic EntityReferenceRevisionsProcessor.

I am now wandering whether all three of these could in fact be replaced by a single entity reference processor.

Would that work?

Thanks for the feedback. Please see the attached updated patch. Please can you re-review?