- π§πͺBelgium kriboogh
Although this patch (#24) works, it implicates the json-api extra settings need to be "opened" up, client side in order for the route to be known so it can be constructed. Otherwise you get a unknown route error on your client.
// Build route name
$routeName = sprintf('jsonapi.%s--%s.individual', 'block_content', $configuration['block_bundle']);// Since we're calling Url::fromRoute() on the importing site, we need to replace the host with the remote's host
$self_link = Url::fromRoute($routeName, ['entity' => $configuration['block_uuid']], ['absolute' => TRUE])->toString(); - Assigned to Grimreaper
- π«π·France Grimreaper France π«π·
- Creating MR
- testing patches since the last time I did it
- updating patch - Merge request !95Issue #3084184 by Oscaner, cit-china-dxp-cicd@ciandt.com, anmolgoyal74,... β (Open) created by Grimreaper
- Issue was unassigned.
- π«π·France Grimreaper France π«π·
I have tested on a Core 10.2.7 with the following patch: #2942975-255: [PP-1] Expose Layout Builder data to REST and JSON:API β
Enabling the field enhancer on both client and server sites. And enabling the "Layout builder" processor in the config import.
It is working well.
Now that a MR had been created, code review and rebase will be easier.
- π§πͺBelgium kriboogh
Currently MR95 causes a deprecation error, when using >PHP8.2:
Deprecated function: Creation of dynamic property Drupal\entity_share_client\RuntimeImportContext::$tmpEntityJsonData is deprecated in Drupal\entity_share_client\Plugin\EntityShareClient\Processor\LayoutBuilder->prepareImportableEntityData() (regel 59 van /home/fedpol_webplatform/public_html/web/modules/contrib/entity_share/modules/entity_share_client/src/Plugin/EntityShareClient/Processor/LayoutBuilder.php)
- Status changed to Needs work
5 months ago 7:55am 29 July 2024 - Status changed to Needs review
5 months ago 9:36am 29 July 2024 - First commit to issue fork.
- Merge request !96Issue #3084184 by Oscaner, cit-china-dxp-cicd@ciandt.com, anmolgoyal74,... β (Open) created by mariacha1
- πΊπΈUnited States mariacha1
I added a slight change to https://git.drupalcode.org/project/entity_share/-/merge_requests/95 to allow non-inline blocks to also be shared. So if you created a block at
/block/add
and then pulled that in.Diff for patching is here: https://git.drupalcode.org/project/entity_share/-/merge_requests/96.diff
I've also got a merge request open against the original MR, where you can see what's changed:
https://git.drupalcode.org/issue/entity_share-3084184/-/merge_requests/1... - πΊπΈUnited States mariacha1
One more small change in MR 96:
https://git.drupalcode.org/issue/entity_share-3084184/-/merge_requests/1...
This keeps non-line blocks from being added to the `inline_block_usage` table. I was seeing errors like this:
Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '66' for key 'PRIMARY': INSERT INTO "inline_block_usage"
- πΊπΈUnited States mariacha1
And another change at https://git.drupalcode.org/issue/entity_share-3084184/-/commit/bab5b0573... which was preventing the opposite problem: Trying to insert an inline block into the reusable block table even when it wasn't one of the block types being shared via the jsonapi.