>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3619960. --> Reported by: [mogtofu33](https://www.drupal.org/user/278510) Related to !555 >>> <h3>Problem/Motivation</h3> <p><code>SourcePluginBase</code> declares two typed properties with no default value:</p> <pre><pre>protected array $propDefinition;<br>protected string $propId;</pre></pre><p><code>setConfiguration()</code> only assigns them conditionally:</p> <pre><pre>if (isset($configuration['prop_definition'])) {<br>&nbsp; $this-&gt;propDefinition = $configuration['prop_definition'];<br>}<br>if (isset($configuration['prop_id'])) {<br>&nbsp; $this-&gt;propId = $configuration['prop_id'];<br>}</pre></pre><p>In normal usage this is never a problem, because <code>SourcePluginManager::getSource()</code> always builds the configuration through <code>SourcePluginBase::buildConfiguration()</code>, which unconditionally sets both keys (even to an empty array, when no prop/slot definition applies).</p> <p>But a source plugin is also a plain Drupal plugin, and nothing stops calling it the plain way: <code>$sourcePluginManager-&gt;createInstance($id, $configuration)</code> with a <code>$configuration</code> that only has <code>settings</code>. That is a legitimate, standard use of a plugin manager, and it is exactly how a kernel test wiring up a source in isolation would do it. When it skips <code>prop_definition</code>/<code>prop_id</code>, any call into <code>getPropDefinition()</code> or <code>getPropId()</code> throws:</p> <pre>Error: Typed property Drupal\ui_patterns\SourcePluginBase::$propDefinition must not be accessed before initialization</pre><p>Concretely this fires today through <code>ComponentSource::settingsForm()</code> &rarr; <code>getExpectedComponentIds()</code> &rarr; <code>getPropDefinition()</code>, but any source relying on <code>getPropDefinition()</code>/<code>getPropId()</code> outside the <code>getSource()</code> factory path hits the same wall.</p> <p>The class already defends its other two settable properties this way:</p> <pre><pre>protected $context = [];<br>protected $settings = [];</pre></pre><p><code>$propDefinition</code> and <code>$propId</code> are set through the exact same conditional pattern in <code>setConfiguration()</code>, they are just missing the declared default that makes the conditional safe to skip.</p> <h3>Steps to reproduce</h3> <ul> <li>Get any <code>\Drupal\ui_patterns\SourcePluginManager</code> instance.</li> <li>Instantiate a source plugin directly, without going through <code>getSource()</code>/<code>buildConfiguration()</code>: <code>$sourceManager-&gt;createInstance('component', ['settings' =&gt; [...]]);</code></li> <li>Call a method that reads <code>getPropDefinition()</code> or <code>getPropId()</code> (e.g. <code>ComponentSource::settingsForm()</code>, which calls <code>getExpectedComponentIds()</code>).</li> <li><code>Error: Typed property ...$propDefinition must not be accessed before initialization</code>.</li> </ul> <h3>Proposed resolution</h3> <p>Give both properties the same style of default already used for <code>$context</code> and <code>$settings</code>:</p> <pre><pre>protected array $propDefinition = [];<br>protected string $propId = '';</pre></pre><p><code>setConfiguration()</code> keeps overwriting them when the keys are present; this only changes what happens when they are absent, from a fatal error to an empty/safe default.</p> <h3>Remaining tasks</h3> <ul> <li>Review the MR.</li> </ul> <h3>User interface changes</h3> <p>None.</p> <h3>API changes</h3> <p>None. Both properties keep their existing type and visibility; only a default value is added.</p> <h3>Data model changes</h3> <p>None.</p>