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

Command icon 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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

larowlan created an issue. See original summary.

AJV009’s picture

Use the third-party settings API to store node-type preview config, instead of a global settings object.

What do you exactly mean by third-party settings api?

AJV009’s picture

Assigned: Unassigned » AJV009
larowlan’s picture

There is some code in gatsby_form_alter that is editing node_type_edit_form

The submit handler gatsby_preview_form_submit reads and write to gatsby.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 :)

larowlan’s picture

There'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

AJV009’s picture

Ohh thanks a lot for the explanation, looks like a lot of points to cover!
Hmm Ill experiment and let you know

AJV009’s picture

I was recently trying to write something for this, but then I suddenly got some doubts.

* preview
* iframe
* target

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?

larowlan’s picture

See gatsby_preview_form_submit

AJV009’s picture

Alright, got it!
I wasn't observant enough! :)

AJV009’s picture

Status: Active » Needs review

Hey 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

third_party_settings:
  menu_ui:
    available_menus:
      - main
    parent: 'main:'
  gatsby:
    preview: 0
    target: window
    iframe: 1

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.

larowlan’s picture

Status: Needs review » Needs work

Code 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

larowlan’s picture

Here's the steps I took

  • drush si minimal -y
  • drush en -y gatsby node
  • drush uli to login as admin
  • As admin, add two node-types from admin/structure/types/
  • As admin, edit these node types and enable gatsby preview and configure settings
  • Run the core DB export script php core/scripts/dump-database-d8-mysql.php|gzip > modules/gatsby/tests/update/fixtures/minimal-9-2-update-3160476.php.gz
  • Write the update test
  • Write the update hook

Also found #3204457: Show Gatsby fields on the node_type.add form while I was at it.

Remaining tasks:

  • Add the missing schema per above
  • Make the test pass - ran out of time locally to get it working today
larowlan’s picture

Oh, the test might pass once we add a schema

There was 1 failure:

1) Drupal\Tests\gatsby\Functional\PreviewSettingsUpdateTest::testUpdatePath
There should be no errors in configuration 'node.type.article'. Errors:
Schema key node.type.article:third_party_settings.gatsby.preview failed with: missing schema
Schema key node.type.article:third_party_settings.gatsby.iframe failed with: missing schema
Schema key node.type.article:third_party_settings.gatsby.target failed with: missing schema

Failed asserting that Array &0 (
    'node.type.article:third_party_settings.gatsby.preview' => 'missing schema'
    'node.type.article:third_party_settings.gatsby.iframe' => 'missing schema'
    'node.type.article:third_party_settings.gatsby.target' => 'missing schema'
) is true.

https://dispatcher.drupalci.org/job/drupal8_contrib_patches/65042/testRe...

larowlan’s picture

Issue summary: View changes
Status: Needs work » Needs review
larowlan’s picture

Issue summary: View changes

Pushed the schema

larowlan’s picture

Issue summary: View changes

Ok, 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)

  • larowlan committed 9cca73c on 8.x-1.x authored by AJV009
    Issue #3160476 by AJV009, larowlan: Use third party settings API for...
larowlan’s picture

Status: Needs review » Fixed

No-one else came forward to review, putting this in and moving forward

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

larowlan’s picture