kevinquillen → created an issue.
I thought I could get away with this by creating a link template for my custom entity and specifying that in the matcher. While that was working, I wanted the link element to also have additional attributes added automatically (because this specific entity match should open in a modal window) - i.e. let JS take over. Without requiring any additional action from the editor. I could not figure out how to modify the element before it was added into CKEditor to have that.
I guess my only option because I am crunched for time is to add in https://www.drupal.org/project/editor_advanced_link → and add a custom checkbox or two and work the rest from JS.
kevinquillen → created an issue.
Test failure seems related to parent Domain module. But the change resolved the fatal error we were seeing on save.
kevinquillen → created an issue.
Just came across this issue when trying to figure out how to resolve this for frontend developers on a project where invalid libraries syntax was not caught.
I located a schema here: https://json.schemastore.org/drupal-libraries.json
After hooking it to my IDE, it started noting incorrect syntax or keys in library files.
It would be nice if Drupal could also catch this and gracefully degrade (in our case, a missing 'css' key threw an exception on the site).
kevinquillen → created an issue.
According to the README, UUID should not be copied into any domain.config* file. This seems like it could be a simple addition to the Domain module to prevent that from happening with:
declare(strict_types=1);
namespace Drupal\mymodule\EventSubscriber;
use Drupal\Core\Config\ConfigEvents;
use Drupal\Core\Config\StorageInterface;
use Drupal\Core\Config\StorageTransformEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
/**
* Listen for configuration events and remove UUIDs from domain.config entities.
*/
final class ConfigExportSubscriber implements EventSubscriberInterface {
/**
* Handle the storage transform export event.
*
* @param \Drupal\Core\Config\StorageTransformEvent $event
* The event.
*/
public function onStorageTransformExport(StorageTransformEvent $event): void {
$this->removeDomainConfigUuid($event->getStorage());
}
/**
* Handle the storage transform import event.
*
* @param \Drupal\Core\Config\StorageTransformEvent $event
* The event.
*/
public function onStorageTransformImport(StorageTransformEvent $event): void {
$this->removeDomainConfigUuid($event->getStorage());
}
/**
* Remove UUIDs from any domain.config configuration entity.
*
* @param \Drupal\Core\Config\StorageInterface $storage
* The storage interface.
*/
protected function removeDomainConfigUuid(StorageInterface $storage): void {
$domain_configs = $storage->listAll('domain.config');
foreach ($domain_configs as $domain_config) {
$config = $storage->read($domain_config);
if (isset($config['uuid'])) {
unset($config['uuid']);
}
$storage->write($domain_config, $config);
}
}
/**
* {@inheritdoc}
*/
public static function getSubscribedEvents(): array {
return [
ConfigEvents::STORAGE_TRANSFORM_IMPORT => ['onStorageTransformImport', -99],
ConfigEvents::STORAGE_TRANSFORM_EXPORT => ['onStorageTransformExport', -99],
];
}
}
is there any reason why this does not exist, or why I should not do this? The domain_config_test module includes several YAML files that also have no UUID with them.
#14 so you are saying you have to delete the UUID manually every time from a domain.config.* file? The issue you linked to goes to a 404.
The proposed change would add filter-ability similar to what Node and Users get in Views along with "Current Domain" options. This makes it easier OOTB for those who have or implement custom entities to work with Domain.
kevinquillen → created an issue.
Did you try the dev branch?
What was the module?
kevinquillen → created an issue.
I tried looking at other examples of outbound processors in core and contrib, but I could not locate any that themselves called Url::fromUserInput
. The only route I can think of is to at least try/catch here so it prevents the OP from occurring and offers some way of recovering and fixing the data.
This was really hard to replicate - somehow my issue (and assume OP issue) was that $path
was passed as NULL (or ''). Which should not happen, and the how it happened... not quite sure. But a try/catch won't harm anything here.
I ran into this with a misconfigured Site Studio component and a Link field that was returning "" because it could not look up the user input value, it did not resolve to any entity in the database.
The problem was here:
/**
* {@inheritdoc}
*/
public function processOutbound($path, &$options = [], Request $request = NULL, BubbleableMetadata $bubbleable_metadata = NULL) {
// Load the active domain if not set.
$active_domain = $options['active_domain'] ?? $this->getActiveDomain();
// Only act on valid internal paths and when a domain loads.
$external = $options['external'] ?? FALSE;
if (is_null($active_domain) || $path === '' || $external === TRUE) {
return $path;
}
// Set the default source information.
$source = NULL;
$options['active_domain'] = $active_domain;
$entity = NULL;
// Get the current language.
$langcode = NULL;
if (isset($options['language'])) {
$langcode = $options['language']->getId();
}
// Get the URL object for this request.
$alias = $this->aliasManager->getPathByAlias($path, $langcode);
$url = Url::fromUserInput($alias, $options);
I think at a minimum the lines:
// Get the URL object for this request.
$alias = $this->aliasManager->getPathByAlias($path, $langcode);
$url = Url::fromUserInput($alias, $options);
should be wrapped in a try catch. Log the path, request, options, alias and return $path
. That gives someone a chance to trace back where the input came from, potentially, and lets pages load.
I could not access the Content admin, URL Alias page, URL Redirect page, or the Admin Content view or areas like that until I resolved this.
To get back up and going to debug the problem for your specific local database, you can do:
if ($path == '') {
return $path;
}
// Get the URL object for this request.
$alias = $this->aliasManager->getPathByAlias($path, $langcode);
$url = Url::fromUserInput($alias, $options);
in DomainSourcePathProcessor.php. That will prevent the pages from crashing so you can trace back the error. In my case, I snagged a database, fixed the content issue, and pushed the database back under maintenance to get the site back online.
Updated patch, removes newline.
Without the change(s) the module version is not usable in Drupal 11.
kevinquillen → made their first commit to this issue’s fork.
kevinquillen → created an issue.
kevinquillen → created an issue.
kevinquillen → created an issue.
kevinquillen → created an issue.
Merged to 2.0.x.
kevinquillen → created an issue.
kevinquillen → created an issue.
kevinquillen → created an issue.
kevinquillen → created an issue.
Looks good to me.
kevinquillen → created an issue.
kevinquillen → created an issue.
kevinquillen → created an issue.
kevinquillen → created an issue.
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.