Contrib.social

Deprecate "Only log entities for published content" setting and refactor hooks.

Open on Drupal.org →
Created on 20 December 2022, over 1 year ago
Updated 10 March 2023, over 1 year ago

Problem/Motivation

As the setting help text reads...
Depending on your content workflow, you may only want fastbuilds to work for published content. By checking this box only published content entities will be logged and available for Fastbuilds.

I can't think of any use case where unpublished content should be rendered in Gatsby. I've found this setting to be confusing and unpredictable and only applies to the hooks: gatsby_entity_update and gatsby_entity_insert. Particularly with gatsby_entity_update, if the entity is published and is default revision (if applicable), a build should be triggered. Since refactoring the module to always save a revision when clicking the preview button, I'm finding the existing logic around this setting in the mix is causing unnecessary builds for published entities that have a moderated state of "draft" which is an undesirable side effect.

User interface changes

Simplify the admin settings form. Remove this form element: Only log entities for published content

API changes

Modifications to the following hooks in gatsby.module:

  • gatsby_entity_insert
  • gatsby_entity_update
  • gatsby_entity_delete

Replace gatsbyPrepareData function in GatsbyPreview.php with 2 separate functions:

  • gatsbyPreparePreviewData
  • gatsbyPrepareBuildData

The logic for what gets sent to preview|build servers needs to be more granular as described:

  • hook_entity_insert: send to both preview and build servers ONLY if the entity is published.
  • hook_entity_delete: send to both preview and build servers. This accounts for anything published on build server and published and/or draft versions on preview server.
  • hook_entity_update: This one needed to be very granular because we don't want draft versions ever going to build server so there is alot of conditional logic added in this hook to determine what triggers build/preview.

** Notable - In some cases I've found an issue where a preview build is triggered to Gatsby cloud and the build on the preview server doesn't error out however the response returned to the preview iframe is a 404. This isn't a Drupal issue but rather seems to be an issue when gatsby cloud goes into "sleep mode" and the value of last_fetched is undefined which then triggers a full build on the preview server. My theory around this is that the original requested entity revision does not yet reside on the preview server so a full build is ultimately always going to lead to a 404 in these cases.

🐛 Bug report
Status

Fixed

Version

2.0

Component

Code

Created by

🇺🇸United States apmsooner

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024