sashainparis → made their first commit to this issue’s fork.
Worked on better parsing in the same file.
So I didn't open another Issue.
Commited to V2 module version.
V3 needs to be done.
Please note: structure is made to converge with the WP API to make sure Components working on WP API should work out-of-the-box on Drupal.
This needs some controls too.
Branch 3232930-return-parsed-block: Gutenberg v3
Reopening the issue to integrate the JsonAPI Gutenberg Blocks module inside the Gutenberg module - as compatibility with JsonAPI Core module.
See JsonAPI Gutenberg Blocks → module I've just published.
JsonAPI Extras compatibility solved in 2.0.0-Alpha5: To use the path-prefix defined there.
Resolved 2.0.0-alpha4
Short answer: yes.
Long answer: it can be easily adapted to be a generic module that could be used in a controlled perimeter domain-oriented. On a dedicated package server with the right description format.
But: in between, patterns appeared to be a better way and cloud approach is limited to actual Gutenberg blocks. Which should be used only when you couldn't do the job with patterns.
In other words: You will use modules to declare a new block. And you will prefer composer to manage the reuse in your domain.
This is also true at community level through contributed modules. The main difference is: You wouldn't need to trigger a new delivery to make it available.
So: great architecture, but not the list optimized approach from a maintainability point of view.
Hope it helps a little bit.
I confirm: It appears to works fine with 2.8
Link to the patch:
https://git.drupalcode.org/project/cloudinary/-/merge_requests/23.patch
sashainparis → created an issue.
sashainparis → created an issue.
sashainparis → created an issue.
See Roadmap for v2.
sashainparis → created an issue.
JsonAPI Defaults is made to define default queries to JsonAPI: IMHO, it applies to collections.
Path alias hardly apply to collections of entities. So I'm not sure to link JsonAPI Aliases module to JsonAP Defaults.
JsonAPI Extras define its configuration to a dedicated page under the JsonAPI configuration page.
A dedicated configuration page should has its own tab under JsonAPI configuration page too: Mainly to define the endpoint.
At Resource level in JsonAPI Extras, one can consider to add a Aliases fieldgroup (after Resource, and before the fields): to enable/disable the resource.
Project page updated.
Yet still need better doc.
Hey,
I'm just getting this module to be maintained again.
From I've read in the code, it should understood as Redirect module JsonAPI oriented - based on the current Alias. Which is pretty cool but should not be considered as a JsonAPI resource itself. Though: Filtering and sorting don't make sense.
As you said it: JsonAPI Core do not allow to filter on the path.alias because it's a dynamic field. Some module proposed to create a real field that actually save he value in the DB - meaning it can be filtered. This approached is not so good from my point of view as updating batch of contents could be a huge issue if you intend to force this saving (writing during the batch vs missing some updates vs ...).
Alexandre
Commited and merged to branch 2.x
D9 only.
We need to make it work as a strategic feature in one of our project.
Priority is to make it work for D10 (too late to talk about D9 - D8 compatibility is considered nice-to-have).
Once stability is delivered, the module will be submitted to security coverage.
[Client is confidential for now]
sashainparis → created an issue.
Agree with #8 :-)
Seems to work fine.
Removing the concerned line in the constructor.
sashainparis → created an issue.
Update patch to consider the sort() added in between on these lines.
Using the module base path.
Hey!
Not part of the team that actually maintains the module but presently actively working on the way Gutenberg can bring a large benefit to the Drupal Contributor Experience.
Here what I think (sorry, it's a little straight):
- Gutenberg is an immersive editor: using it at field level doesn't make sense to me as the UX provides a place for native fields
- Using it on other Content Entities definitely make sense: Blocks, Taxonomies, Menus (with Extra module to allow fields), Profiles, etc.
- Paragraphs is a very specific Content Entity as it is used as a versioned Entity Reference: It is the much more complex Content Entity built since the node, the block system and the book router...: My main goal while using Gutenberg is precisely to get rid of Paragraphs
From my experience, to get the best from Gutenberg:
- Start building Patterns in a gutenberg.yml theme and add some beautiful styles
- Adapt the options
- Only when you're blocked: consider creating custom Gutenberg blocks
- Then you might consider using the Gutenberg Cloud module... to a private server that will serve static packages for better custom blocks delivery (yes with need to change a few lines and add a short admin page for that)
- Inspired by the WP pattern server, you can also install such a private server to allow easy sharing in your Entreprise (copy and paste on the go): Yes, some more work to be done for that too
Please share what you think about it.
Take care,
hestenet → credited sashainparis → .
@geoanders : would be great :-)
@bryanlund : could you do something about it, please?
There is no composer.json in the patch.
Might be that.
"Make it clear" means to me: in composer.json :-)
Regards,
ping list