Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Configuration that depends on node-types should be stored in the node-type itself, using the third-party settings api.
Using gatsby.settings to store configuration relating to node-types means if those node-types are removed, the config is out of date.
Proposed resolution
Use the third-party settings API to store node-type preview config, instead of a global settings object.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork gatsby-3160476
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
AJV009What do you exactly mean by third-party settings api?
Comment #3
AJV009Comment #4
larowlanThere is some code in
gatsby_form_alter
that is editingnode_type_edit_form
The submit handler
gatsby_preview_form_submit
reads and write togatsby.settings
As you'd be aware, we just added a schema for that file based on the config form.
But this submit handler writes to keys that we didn't specify (by design) as follows:
* preview
* iframe
* target
These are per-node type.
Instead of abusing the global
gatsby.settings
, this should be writing to node.type.*.third_party_settings.gatsby.*A good example of this is e.g. builder_notes module.
Instead of using a global config object, it writes to each node type.
Firstly it adds a schema entry for node-types
Then it uses an entity builder instead of a submit handler.
Then in the entity builder we save the values into the node-type itself.
The beauty of this is, if the node-type is deleted, the config lives in that node-type and is gone too.
With how its currently implemented in gatsby, those settings persist.
We'll obviously need to update how we read those values back in a few places.
We'll also need to write an update path for this, which is getting pretty deep once we add a test for it.
But if you get through this, really you could take on any issue in any module or core queue :)
Comment #5
larowlanThere's an old lightning talk I did on this available on our website https://www.previousnext.com.au/blog/lightning-talk-drupal-8s-third-part... - full disclaimer it may be out of date now
Comment #6
AJV009Ohh thanks a lot for the explanation, looks like a lot of points to cover!
Hmm Ill experiment and let you know
Comment #7
AJV009I was recently trying to write something for this, but then I suddenly got some doubts.
I never saw these keys anywhere in the config! And how do you know about it? Is there a way to inspect them? Hmm like using devel or something like that?
I just saw your video, the examples you shared and also some blogs from a quick google search. Another example I got from web -> https://kevinquillen.com/using-thirdpartysettings-api-drupal And i guess I understand the whole thirdpartysettings thing, maybe not exactly but fair enough to implement it! So maybe if I can understand more about the problem that we are trying to solve now in more depth will help, I maybe able to write all the code required to make this big change, and It could be fun I guess!
Most of the examples I saw were simply trying to store a single value. Which form values are we exactly expecting to use with thirdpartysettings?
Comment #8
larowlanSee gatsby_preview_form_submit
Comment #9
AJV009Alright, got it!
I wasn't observant enough! :)
Comment #11
AJV009Hey Lee, it was way easier than I thought. I tested it with different configs on different CTs then exported them.
this is what it looks like in schema
I feel sorry for taking such long time I was delaying this issue because I though it was some kind of difficult thing as it was super new.
But the resource you shared were far enough to understand the implementations and the aim, just had to take some time to understand the flow.
Comment #12
larowlanCode looks great, now the fun starts
Next step is we need a config schema entry - here's an example for a node-type, we'd be doing similar for ours.
Then it starts to get a bit hairy, because we need an upgrade path and an upgrade path test.
Because existing sites have this config in their gatsby.settings.yml, we need to migrate it for them.
I'm happy to help guide on that, because its not simple.
I'll try to find some time this afternoon
Comment #13
larowlanHere's the steps I took
php core/scripts/dump-database-d8-mysql.php|gzip > modules/gatsby/tests/update/fixtures/minimal-9-2-update-3160476.php.gz
Also found #3204457: Show Gatsby fields on the node_type.add form while I was at it.
Remaining tasks:
Comment #14
larowlanOh, the test might pass once we add a schema
https://dispatcher.drupalci.org/job/drupal8_contrib_patches/65042/testRe...
Comment #15
larowlanComment #16
larowlanPushed the schema
Comment #17
larowlanOk, I think this is ready now, but would be good to get another reviewer who didn't work on it (@AJV009 and I have both worked on it)
Comment #19
larowlanNo-one else came forward to review, putting this in and moving forward
Comment #21
larowlan#3210105: Gatsby Preview iframe isn't included when viewing nodes