WP_Scripts::add :: "divi-dynamic" enqueued with style handle "divi-style-parent-inline" as dep (WP 6.9.1+ notice)

[s-a-s-k-i-a]

Environment

• Divi 5.3.1
• WordPress 6.9.4 (the check that emits this warning was added in 6.9.1)
• PHP 8.3, WP_DEBUG=true, WP_DEBUG_LOG=true
• Child theme active (relevant — see below)

Symptom

Every frontend render emits this E_USER_NOTICE into wp-content/debug.log:

PHP Notice:  Function WP_Scripts::add was called incorrectly. The script with
the handle "divi-dynamic" has been enqueued with unregistered dependencies:
divi-style-parent-inline. Please see Debugging in WordPress for more information.
(This message was added in version 6.9.1.) in /wp-includes/functions.php on line 6131

Two things are wrong:

1. divi-dynamic is enqueued through WP_Scripts::add (i.e. as a script), but its dependency list contains divi-style-parent-inline, which is a style handle. Script-to-style dependencies are not a thing in WordPress — WP_Scripts::$registered and WP_Styles::$registered are separate registries, and _doing_it_wrong() fires because array_diff( deps, array_keys( registered ) ) in WP_Dependencies::add() can never find the style handle inside the script registry.
2. Even if we ignore the cross-registry issue, divi-style-parent-inline is only registered conditionally by Divi/functions.php (the "Load Dynamic Stylesheet In-line" path) — so the dep is frequently missing at the time divi-dynamic is enqueued.

Reproduction

1. WordPress 6.9.1+ (for the warning itself), Divi 5.3.1, WP_DEBUG=true.
2. Activate any child theme (is_child_theme() === true) — the warning mentions divi-style-parent-inline, so the parent/child suffix logic is involved.
3. Render any frontend page:

   curl -sk https://example.tld/some-page/ -o /dev/null
   tail wp-content/debug.log
   

4. Notice appears on every uncached render.

On a stack with WP_DEBUG_DISPLAY=true the notice is rendered inline in the HTML, which makes it visible to admins during Theme Builder work.

What I traced

• divi-style-parent-inline is registered in wp-content/themes/Divi/functions.php line 525 only when the site has "Load Dynamic Stylesheet In-line" enabled and the contents could be read:

  if ( false !== $stylesheet_contents ) {
      wp_register_style( 'divi-style' . $child_theme_suffix . '-inline', false, array(), $theme_version );
      wp_enqueue_style( 'divi-style' . $child_theme_suffix . '-inline' );
      wp_add_inline_style( 'divi-style' . $child_theme_suffix . '-inline', $stylesheet_contents_replaced );
      …
  }

  $child_theme_suffix === '-parent' when is_child_theme(), so the full handle becomes divi-style-parent-inline.

• DiviPackageBuild.php:253 explicitly prepends 'divi-style-parent' (without the -inline suffix) to style deps of package builds:

  // Maybe prepend 'divi-style-parent' to the package css dependencies.
  if ( $this->_is_divi_parent_theme && …) {
      array_unshift( $generated_style['deps'], 'divi-style-parent' );
  }

• I could not find a literal 'divi-dynamic' string anywhere in the Divi PHP source — grep -rn "['\"]divi-dynamic['\"]" Divi/ returns nothing. Closest matches are divi-dynamic-data, divi-dynamic-prop-value-sync, etc. This suggests the divi-dynamic handle — and the divi-style-parent-inline dep in its deps array — is assembled at runtime somewhere in the builder-5 asset pipeline, most likely by stripping a suffix from a package name, or by a helper that copies style deps into a script's deps list (the only way a style handle could end up in WP_Scripts).

Suggested fix direction

Two separate issues to address:

1. Stop mixing style handles into script deps. Whichever code path builds the divi-dynamic script's deps array is sourcing style handles (e.g. from $generated_style['deps']) and passing them to wp_enqueue_script(). It should filter them out, or use wp_enqueue_style( $script_handle, $src, $script_deps + $style_deps ) pattern only when the handle is actually registered as a style.

2. Register divi-style-parent-inline unconditionally, or stop referencing it as a dep when the "Load Dynamic Stylesheet In-line" option is off. Right now the handle's existence depends on whether $stylesheet_contents could be read, but other code assumes it's always there.

Minimal patch to silence the notice immediately (without fixing the underlying mix-up): guard the dep injection at the package-build level so only registered handles are passed to wp_enqueue_*:

$deps = array_filter(
    $deps,
    function ( $h ) {
        return wp_script_is( $h, 'registered' ) || wp_style_is( $h, 'registered' );
    }
);

That's a workaround; the proper fix is to not treat a style as a script dep in the first place.

Why it matters

The warning is cosmetic today (E_USER_NOTICE), but WordPress promotes these to errors eventually. It also fills debug.log with one line per page render, which obscures real problems during development. And if Divi 6 or WP 7 ever turns this into an E_USER_ERROR, every Divi child-theme install with WP_DEBUG=true will break at once.

Happy to provide a PR once the right approach is confirmed — in particular, whether the team prefers (a) tightening the dep construction at package-build time or (b) always registering divi-style-parent-inline so the reference is valid.