Something in the way this patch handles UUIDs was causing fatal errors with Site Studio on importing new configuration with:
2024-12-19T15:10:04Z [notice] Finalizing configuration synchronization.
2024-12-19T15:10:04Z In ConfigImportCommands.php line 291:
2024-12-19T15:10:04Z The import failed due to the following reasons:
2024-12-19T15:10:04Z Unexpected error during import with operation create for media.type.vector_
2024-12-19T15:10:04Z image: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 's
2024-12-19T15:10:04Z ource_uuid' cannot be null: INSERT INTO "coh_usage" ("s
2024-12-19T15:10:04Z ource_uuid", "source_type", "requires_uuid", "
2024-12-19T15:10:04Z ;requires_type") VALUES (:db_insert_placeholder_0, :db_insert_placehol
2024-12-19T15:10:04Z der_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array
2024-12-19T15:10:04Z (
2024-12-19T15:10:04Z [:db_insert_placeholder_0] =>
2024-12-19T15:10:04Z [:db_insert_placeholder_1] => media_type
2024-12-19T15:10:04Z [:db_insert_placeholder_2] => media-mid
2024-12-19T15:10:04Z [:db_insert_placeholder_3] => field_config
2024-12-19T15:10:04Z )
2024-12-19T15:10:04Z Unexpected error during import with operation create for field.field.media.
2024-12-19T15:10:04Z vector_image.field_media_svg: SQLSTATE[23000]: Integrity constraint violati
2024-12-19T15:10:04Z on: 1048 Column 'source_uuid' cannot be null: INSERT INTO "c
2024-12-19T15:10:04Z oh_usage" ("source_uuid", "source_type", "req
2024-12-19T15:10:04Z uires_uuid", "requires_type") VALUES (:db_insert_placeholder
2024-12-19T15:10:04Z _0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placehol
2024-12-19T15:10:04Z der_3); Array
2024-12-19T15:10:04Z (
2024-12-19T15:10:04Z [:db_insert_placeholder_0] =>
2024-12-19T15:10:04Z [:db_insert_placeholder_1] => field_config
2024-12-19T15:10:04Z [:db_insert_placeholder_2] => d38bcb72-e5ae-4e9a-99b8-3298da041238
2024-12-19T15:10:04Z [:db_insert_p
These errors are very odd, because it implies UUIDs are NULL, when they aren't. So I went digging, and after removing patch #31, I couldn't get this error at all. Putting it back made it happen again.
I think it is because of this:
$originalUuid = $this->getOriginal('uuid', FALSE);
where it should be:
$originalUuid = $this->getOriginal('uuid', FALSE) ?? $this->get('uuid');
because according to getOriginal in Config:
* Original data is the data as it is immediately after loading from
* configuration storage before any changes. If this is a new configuration
* object it will be an empty array.
originalUuid was coming up NULL for new configuration objects, where $this->get('uuid') was returning the UUID stored in the configuration yaml file. I am not 100% on all the things this patch is doing, but I think this is a potential problem which was hard to track down, but we need the functionality this patch provides (Domain specific config).
Attached is an updated patch with that change.
Not sure what happened, but after removing the patch, clearing cache a few times, restarting ddev, re-applying the patch, the error does not occur anymore.
However it will still export with the same UUID until you have deleted all previously created records and flushed it out of Drupal, just a note.
Happens to me on a brand new site with the very first configuration export and then the next import. This does seem site breaking IMO, because its really easy to walk into that and then get stuck.
Patch #31 alone throws this error:
ArgumentCountError: Too few arguments to function Drupal\domain_config_ui\Config\ConfigFactory::__construct(), 4 passed in /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 and exactly 5 expected in Drupal\domain_config_ui\Config\ConfigFactory->__construct() (line 45 of /var/www/html/docroot/modules/contrib/domain/domain_config_ui/src/Config/ConfigFactory.php). #0 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\domain_config_ui\Config\ConfigFactory->__construct()
Visiting the site shows:
The website encountered an unexpected error. Try again later.
Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "domain_config_ui.factory", path: "options_request_listener -> domain.route_provider -> path_processor_manager -> path_processor_front -> domain_config_ui.factory -> exception.fast_404_html". in Drupal\Component\DependencyInjection\Container->get() (line 147 of core/lib/Drupal/Component/DependencyInjection/Container.php).
Drupal\Component\DependencyInjection\Container->get() (Line: 430)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 454)
Drupal\Component\DependencyInjection\Container->Drupal\Component\DependencyInjection\{closure}() (Line: 243)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 241)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable() (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)
on Drupal 11.0.9.
The module lacks a composer.json, so I cannot require a forked version via Composer.
Could we get these changes in so it is installable in Drupal 11?
+1
I've been using a lot more Playwright than Cypress lately. One reason was I needed to get up and run it in CI very quickly, which was not simple in the past with Cypress and do some multi device testing. It wound up being a lot easier to configure and reason about, and better on execution and performance. I think it would be a beneficial add.
Playwright also has a UI mode: https://playwright.dev/docs/test-ui-mode
You can also use the browser Recorder (dev console) to playback and export test specs from the interactions. They aren't always 100% perfect but can save a lot of time.
+1, is there someone who can review this?
Think this is all that is required to make it installable in Drupal 11.
kevinquillen → created an issue.
This looks good to me.
+1 from me, sounds good.
#10 the reason for this is to not break compatibility with Javascript deserializers written for JSON:API specification. The module can still include everything in the relevant areas as long as it does not drop 'attributes' 'relationships' etc. I suspect many libraries like JSONA simply expect them to exist with values. Without them, it cannot parse responses. You can see this here:
https://github.com/olosegres/jsona/blob/master/src/builders/JsonDeserial...
here is another example in another library:
https://github.com/SeyZ/jsonapi-serializer/blob/master/lib/deserializer-...
or another:
https://github.com/ShadowManu/jsonapi-deserializer/blob/master/src/index...
This would require frontend developers to write their own parsers which can take several dozens of hours or more. At least with the option the structure can be preserved without losing the additional features (including all resources possible).
Note that for Drupal 11 compatibility, the following change has to be made in SectionDataNormalizer, as $supportedInterfaceOrClass has been removed:
/**
* {@inheritdoc}
*/
public function getSupportedTypes(?string $format): array {
return [
SectionData::class => TRUE,
];
}
Otherwise, this patch will apply cleanly to Drupal 11 and works. I will try to re-roll this week when I get time.
+1
This issue is marked fixed, is the patch in 58 still needed?
Thanks Pavlos
For anyone landing here, I fixed this over here and avoid using nodes or blocks entirely. https://www.drupal.org/project/site_studio_webform_element →
kevinquillen → created an issue.
sahaj take a look at the branch (https://git.drupalcode.org/issue/ai-3479175/-/tree/3479175-reformat-plugin) and try it out. These are the changes:
https://git.drupalcode.org/project/ai/-/merge_requests/151/diffs
I brought in a change that pulls the HTML into the selected text instead of dumps it, which would affect all plugins. However, the prompt is also appended that enforces specific markup tags only in the response.
I think the trick here is not just reformatting or formatting HTML, but doing it in a semantic way or improving what is there to be more 'correct'. How can we validate that? Do you have some sample text/markup to share?
That was an experimental plugin that looked at submitted text and tried to 'correct' the HTML from before, the results varied a lot. Now that it can submit and respond with HTML (and understand text format HTML tag lists), maybe it is worth bringing back. I would expect the quality to be higher and also in line with what the text format(s) allow.
This module does not seem to install without this change. +1
I see no news or indication why the repository was straight up deleted, which is unfortunate.
We can fork the code for now to a repository and repoint composer.json to that public repository. I will work at that.
From what I could find on the form error with #ajax, it seems like it is similar to this. But its hard to know "what" other than something could be altering forms that we are unaware of.
🐛 'The container was serialized' error when specifying an #ajax callback for a form Active
There is a ton to unpack in that composer.json. Are you really using Site Studio, Panels, Page Manager, and Acquia Lightning altogether?
You'll have to provide details, your AI provider, and your composer.json on how to replicate this, as I have not seen this error in Drupal 10.3 or 11.
That patch is unrelated to the original issue and should be in its own separate issue.
But going back to the original MR, I have rebased it with upstream changes from 1.0.x. It should preserve everything that was selected now (HTML tags):
This has never been tried under Site Studio, at least not by me.
GitLab CI integration has been added, so if you create issues or issue forks it will run that automatically for you, and some established test cases exist in code. Feel free to contribute openly, every bit helps. Thanks!
Updated, waiting for test results.
General run through works on D10 (i.e. initial error described by OP). I think we are good to go here, thanks everyone!
I think we are good here for D10 and 11.
Tests now pass in D10 and D11
I think that was triggered from this in ConfigFormBase:
if (!$typedConfigManager instanceof TypedConfigManagerInterface) {
$type = get_debug_type($typedConfigManager);
@trigger_error("Passing $type to the \$typedConfigManager parameter of ConfigFormBase::__construct() is deprecated in drupal:10.2.0 and must be an instance of \Drupal\Core\Config\TypedConfigManagerInterface in drupal:11.0.0. See https://www.drupal.org/node/3404140", E_USER_DEPRECATED);
}
Tests fail under Drupal 9.5 (previous major) due to a missing core test trait. Though I am not sure we care about an EOL version of Drupal (and I don't see many reports of Drupal 9 not working, this could be a test-only failure).
Replicated locally, looks like this change is not D10.3 compatible:
https://git.drupalcode.org/issue/tvi-3470314/-/commit/ba741dab191fd7639d...
After removing the type, it passed. Re-running for D11.
Fails under Drupal: 10.3.6-dev, passes under Drupal: 11-dev
The tests pass locally in DDEV but not in GitLab CI.
kevinquillen → made their first commit to this issue’s fork.
Yeah looks like the only change PB offered was:
https://git.drupalcode.org/project/tvi/-/blob/2.0.x/tests/src/Functional...
Correct, this has not been merged.
This is true. The CKEditor integration has had a lot of advancements over there, including streamed HTML responses.
Great work here.
I just realized the config entities are the actual objects, but not all the possible ones (like Views not being listed out). This will need more work.
For reference - we have a headless POC where some values are dictated from 'theme settings' for lack of better storage. This could have easily been a vanilla settings object.
Either way, the concept is, if anything about that theme changes, trigger a build (likely contains something in the header or footer, or may dictate some color values, etc).
Working on this. It should support any content entity and any configuration entity (some may be using configuration values for headless content).
kevinquillen → created an issue.
The only thing is there is no generic 'throbber' - its just the text that indicates AJAX activity. I don't want to add a dependency on a whole module to manage throbbers from OP.
I tried adding a Drupal throbber manually via JS but it does not appear correctly (Gin). I had to apply inline style to see the spinner and or, its not correctly detecting when still under AJAX events. It also doesn't block out the screen.
I think text is fine for now unless someone can work this issue.
This was a bug in the way the JS code was interpreting the selection data. undefined is now treated as newline characters.
This is a short term fix, in the future the model should be preserved now that it can respond with HTML. Try out this branch.
kevinquillen → created an issue.
Nice work!
Disregard last comment, the saving issue was due to a change with Layout Builder iFrame Modal.
Well that fixes the reading, but saving is broken with Paragraphs.
If you use Paragraphs on a Block Type in Layout Builder, you will get a fatal error:
Error: Cannot use object of type __PHP_Incomplete_Class as array in Drupal\entity_reference_revisions\Plugin\DataType\EntityReferenceRevisions->setValue() (line 116 of modules/contrib/entity_reference_revisions/src/Plugin/DataType/EntityReferenceRevisions.php).
I traced it back to this patch.
Unfortunately the Paragraph class never makes it into the allowed_classes list. When it is listed, it works. Example:
/**
* Processes serialized block correctly.
*
* @return mixed
* Result of unserialize() function.
*/
protected function getUnserializedBlock(): mixed {
$base_class = $this->entityTypeManager->getDefinition('block_content')->getClass();
[, $bundle] = explode(PluginBase::DERIVATIVE_SEPARATOR, $this->getPluginId());
$bundle_class = $this->entityTypeManager->getStorage('block_content')->getEntityClass($bundle);
return unserialize($this->configuration['block_serialized'], ['allowed_classes' => [$base_class, $bundle_class, 'Drupal\paragraphs\Entity\Paragraph']]);
}
Although I am unaware at the moment how to get "Paragraph" into that list. The block type is block_content with an EntityReferenceRevision field on it pointing at a Paragraph bundle.