Be able to push entities from a client site to a server site.

CommentFileSizeAuthor
#19 Nearly_compliant_websub.png304.56 KBFatherShawn
#4 entity_share-push_form-2856715-4.patch12.2 KBGrimreaper
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Grimreaper created an issue. See original summary.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Title: [D8] Push form » Push form
Version: » 8.x-1.x-dev
Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Assigned: Unassigned » Grimreaper
  • Creation of action plugin to have Views integration.
  • Use of plugin derivative to create plugins dynamically for "authorized" entity types
Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Status: Active » Needs work
FileSize
entity_share-push_form-2856715-4.patch12.2 KB

Uploading WIP patch.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented

Commited on the 8.x-1.x-push_form branch

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Related issues: +#2897230: [PP-1] Creating translations (via PATCHing entities?), +#2897257: Add test coverage to ensure it's possible to reference File entities
Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Related issues: +#2897545: Support PATCH operation

For the push of physical files. I am trying to use the JSON API file module. Opening issue #2897545: Support PATCH operation.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Status: Needs work » Postponed

Waiting for related issues to have responses.

michaelmallett’s picture

michaelmallett CreditAttribution: michaelmallett commented

In terms of pushing from the server to client websites, is this a related or seperate feature request?

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented

Hello,

The idea with the push form is to allow the client website to push on the server website.

If you want to push from the server website to the client webstie, the problem is that the server website is not aware of the client website(s).

The server website only exposes content.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Assigned: Grimreaper » Unassigned

Unassigning as the issue is postponed.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ as a volunteer and at OVHcloud commented

on #10, would integrating with the consumers module help?

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper as a volunteer commented

@nod_: Thank you very much for the suggestion.

That needs to be tested, I never used the consumers module, only read this article https://www.lullabot.com/articles/decoupled-drupal-hard-problems-image-s....

C13L0’s picture

C13L0 CreditAttribution: C13L0 commented

We have 1 main website and 21 subdomains which have emergency messaging, events, and news in common (content type and field machine names are identical). The main website needs to have the ability to push emergency messages to all subdomains at once. The main website also needs to be able to push individual events and news to their relevant subdomains. Our sites are hosted on Pantheon upstream.

I'm interested in an estimate/quote to create a patch to fix this issue.

edit* To be very clear, the patch has to be committed in order for us to use it.

edit,edit: We are going to try one more option using a rest endpoint on the main site and features from migrate 8.5.1 core. I will let you know the outcome

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Related issues: +#2794431: [META] Formalize translations support, +#2915662: Add support for PATCH Method

Updating related issue blocking this one.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Version: 8.x-1.x-dev » 8.x-2.x-dev
Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Category: Task » Feature request
FatherShawn’s picture

FatherShawn
Primary language English
Location New York
CreditAttribution: FatherShawn at Digital Pulp commented

Before we found Entity Share we were considering creating something similar that implemented the W3C WebSub protocol. There are base classes for this protocol in core dependencies. Entity Share is really nice work, but I think this idea still has merit. The advantages are:

  • The server knows about the clients.
  • The server pushes on change so only changed entities get synchronized.
  • Updates are automated and continuous.
  • If we push via JASON:API then we are on the proper side of the public/private API divide and are no longer affected by internal changes to JSON:API implementation.

If such direction is of interest, we are happy to collaborate and contribute here. We're also happy to try to figure out how to implement as an enhancement module, but this seems like such a core part of the architecture the route for that is not immediately obvious.

FatherShawn’s picture

FatherShawn
Primary language English
Location New York
CreditAttribution: FatherShawn at Digital Pulp commented
FileSize
Nearly_compliant_websub.png304.56 KB

Digging in more deeply to push based on WebSub I found a sticking point. We can't assemble a JSON version of the content and push to the JSON api endpoint and also comply with the WebSub protocol. The standard requires:

  • The hub to store
  • The content distribution notification MUST contain the full contents of the topic URL

I suppose we could alias such a unique url to one path as the subscription is setup, and then re-alias it to the appropriate JSON:API path after the subscription is verified. I'm attaching a flow diagram in case this sparks some direction, but also opened #3077976: WebSub Inspired Continuous Delivery as a way to adapt the ideas of the WebSub recommended standard to the existing architecture.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented

Thanks @FatherShawn for the suggestion.

Here is my feedback.

If the WebSub compliance should be done, It should be done in a non mandatory way. Maybe one or two submodules. As you said, it can automatically handle updated content, but some clients don't want automated changes.

Thanks for the diagram and your investigations.

If I understand the problem of unique URL. For any entity_type/bundle, the Hub should deliver to the same path?

Let's follow the discussion in #3077976: WebSub Inspired Continuous Delivery.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Related issues: +#3080629: Automatic notification of update changes

I have shared some though about another approach in the issue #3080629: Automatic notification of update changes.

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Version: 8.x-2.x-dev » 8.x-3.x-dev
Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented

Hello,

Now that there is code in https://www.drupal.org/project/entity_share_websub. I am considering to mark this issue has "Closed (works as designed)".

This will avoid to wait for all JSON:API limitations to be done.

FatherShawn’s picture

FatherShawn
Primary language English
Location New York
CreditAttribution: FatherShawn at Digital Pulp commented

That sounds reasonable. We have it working on pull that add-on

Grimreaper’s picture

Grimreaper
Primary language French
Location France 🇫🇷
CreditAttribution: Grimreaper at Smile commented
Status: Postponed » Closed (won't fix)

Thanks for the reply :)