🇺🇸United States @kevinquillen

What was the module?

kevinquillen → created an issue.

greggles → credited kevinquillen → .

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", &quot
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 →

Solved 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!

https://git.drupalcode.org/project/tvi/-/pipelines

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...