Live feed

@jose reyero I created the merge request for you - https://git.drupalcode.org/project/drupal/-/merge_requests/12121

Re-titling and moving back to active.

zubair-rana → created an issue.

alexpott → opened merge request !12121

The fallback component will not, I assume, have any props -- but it will render child slots, presumably to keep as much of the layout intact as possible.

was also still wrong in the issue summary — see #69 and earlier for why that's not the case.

Hello @marcus_johansson and @divyansh.gupta
The issue is already in RTBC for making the AI assistant field require:
Please check this Issue link : https://www.drupal.org/project/ai/issues/3520273 🐛 Make an AI Assistant select list field required on AI Chatbot block configuration page Active

Thank you!

wim leers → closed merge request !1029

(note: I am not a maintainer but) I do have some architectural concerns as well.

What happens if the jobs are purged? See tmgmt_cron().

This, also jobs can be deleted manually.

Currently, the block shows the message if there is an accepted/completed job item for the given entity type, ID and language.
But what about the revision? should that be taken into account?
Also, what if the entity was translated with tmgmt but using another source plugin?
To me this looks more like some business logic that could vary greatly depending on the site.

Maybe this can be implemented as a base field (revisionable, translatable) in the entity.
But of course it would need to be set on the translation upon save. I did find ✨ Hook to allow modules to alter translation entity being created RTBC which may help on that.

Upgrading to 1.4.0 solves the problem

FWIW does this actually happen on 10.5.x? I think state cache collecting only was turned on by default in 11.x. - anyhows no harm in the tests being aligned.

Committed 7aa2683 and pushed to 10.5.x. Thanks!

🐛 Cannot delete JS components due to component depending on them Active is in!

🐛 Cannot delete JS components due to component depending on them Active is in!

Next up:

• 📌 Handle update and delete of Block component config entities Active
• 💬 ComponentNotFoundException: Unable to find component Active

Cross-posted with @lauriii's #66.

You're right, @lauriii, that behavior was changed 👍 But the docs still said that was the behavior until a few seconds ago. And @penyaskito also got confused by the code — so docs in the relevant code have been clarified too 👍

Yep, +1 for a follow-up on that. And +1 for postponing that until we have made decisions around what the data model is going to be.

Done: ✨ [later phase] Provide API for finding and UI for surfacing dangling/dead component subtrees — aka garbage clean-up Postponed .

Getting this into 11.x early in the 11.3.x cycle to wrangle out any issues and work on the follow-ups.

Committed 4815dcc and pushed to 11.x. Thanks!

wim leers → credited lauriii → .

jsacksick → created an issue.

Confirmed by @lauriii that we want this at 📌 `BlockComponent::validateComponentInput()` allows garbage to pile up Active .

Plus, this is at minimum postponed on 📌 [PP-1] Consider not storing the ComponentTreeStructure data type as a JSON blob Postponed and 📌 [PP-1] Spike: Explore storing a hash lookup of component inputs Postponed .

wim leers → created an issue.

My votes:
- Will Huggins (zoocha-will)
- Marine Gandy (Mupsi)

Hello

We implemented the suggested fix and have tested in our production environment and the fix has resolved our issue we are no longer seeing the error in our accessibility reports.

Thanks again for the quick solution.

Hello, i have tested this and have few observations as below.
I added a menu item with and set to expanded and added a sub item below it - After applying the MR the expand collapse functionality worked fine.
The patch 26 fails to apply so styling could not be checked.

Next, I also checked by adding menu item with a normal link, and set to expanded and added a sub item below it and checked, the menu item is not correctly show.

Added screenshots for reference.

Crediting people who contributed to 📌 Transactions should be allowed to be committed explicitly Needs work - ie. c960657 and anybody.

Please all the peeps from this issue.

alexpott → credited c960657 → .

alexpott → credited anybody → .

After running the failed tests the pipeline is green now.

Automatically closed - issue fixed for 2 weeks with no activity.

Hello,
I've tested MR with below fields:

Label Field Type status
1. Image Image Translatable
2. link Link Not Translatable
3. Media image Entity reference (type:Image) Not Translatable
4. Text long Text (plain, long) Translatable
5. List List (text) Translatable
6. Taxonomy Entity reference(taxonomy) Not Translatable
As I noted like reference fields are not translatable.

Thank you!

bserem → opened merge request !2

bserem → created an issue.

This MR elevated the importance of 📌 Constraint slot names allowed by XB in its component tree Active .

@penyaskito seems to have struggled to understand the same bits of the MR as me — good reassurance — so I got his +1s for some of the comment/docs additions 😊🙏

The subtler/trickier bits of the Fallback plugin made me discover a bug in the block component source: 📌 `BlockComponent::validateComponentInput()` allows garbage to pile up Active .

Epic work here, everyone — especially @larowlan & @f.mazeikis!

I think the essence of this issue is best described by

• docs/components.md#3.4 Fallback for architecture and end-user impact
• the ComponentInterface::setSource() docblock for details wrt when "changing the source" is appropriate

wim leers → credited penyaskito → .

I am noticing a similar issue in definitions/relationships/properties/roles/properties/data in the /jsonapi/user/user/resource/schema endpoint (which is not a config entity resource type, but relates to one):

Nevermind, this is supposed to be an array because it's describing a list of all the roles the user has.

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

I am already using "drupal/media_contextual_crop_iwc_adapter": "2.0.x-dev@dev"

The revision log message formatter should allow the same list of tags are we do in \Drupal\node\Controller\NodeController::revisionOverview()

        $column = [
          'data' => [
            '#type' => 'inline_template',
            '#template' => '{% trans %}{{ date }} by {{ username }}{% endtrans %}{% if message %}<p class="revision-log">{{ message }}</p>{% endif %}',
            '#context' => [
              'date' => $link,
              'username' => $this->renderer->renderInIsolation($username),
              'message' => ['#markup' => $revision->revision_log->value, '#allowed_tags' => Xss::getHtmlTagList()],
            ],
          ],
        ];

Automatically closed - issue fixed for 2 weeks with no activity.

In this case we need to change the formatter for the revision log message to be able to use basic html. Then we can use it in views. If you look at the revision page after doing a revert the log message is perfectly rendered em tags and all.

Hi @jimmynash,

I have just realize on this problem with Webform.
Could you please tell to me which patches have I to apply to solve it?

My error:

Object { message: "\nAn AJAX HTTP error occurred.\nHTTP Result Code: 500\nDebugging information follows.\nPath: /admin/structure/webform/manage/questionari_conxeiments_tic/element/add?parent=flexbox\nStatusText: error\nResponseText: The website encountered an unexpected error. Try again later.TypeError: substr(): Argument #1 ($string) must be of type string, int given in substr() (line 44 of modules/contrib/media_contextual_crop_iwc_adapter/media_contextual_crop_iwc_adapter.module). media_contextual_crop_iwc_adapter_form_alter() (Line: 552)\nDrupal\\Core\\Extension\\ModuleHandler->alter() (Line: 839)\nDrupal\\Core\\Form\\FormBuilder->prepareForm() (Line: 285)\nDrupal\\Core\\Form\\FormBuilder->buildForm() (Line: 73)\nDrupal\\Core\\Controller\\FormController->getContentResult()\ncall_user_func_array() (Line: 123)\nDrupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->Drupal\\Core\\EventSubscriber\\{closure}() (Line: 638)\nDrupal\\Core\\Render\\Renderer->executeInRenderContext() (Line: 124)\nDrupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)\nDrupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->Drupal\\Core\\EventSubscriber\\{closure}() (Line: 181)\nSymfony\\Component\\HttpKernel\\HttpKernel->handleRaw() (Line: 76)\nSymfony\\Component\\HttpKernel\\HttpKernel->handle() (Line: 53)\nDrupal\\Core\\StackMiddleware\\Session->handle() (Line: 48)\nDrupal\\Core\\StackMiddleware\\KernelPreHandle->handle() (Line: 28)\nDrupal\\Core\\StackMiddleware\\ContentLength->handle() (Line: 116)\nDrupal\\page_cache\\StackMiddleware\\PageCache->pass() (Line: 90)\nDrupal\\page_cache\\StackMiddleware\\PageCache->handle() (Line: 50)\nDrupal\\ban\\BanMiddleware->handle() (Line: 48)\nDrupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle() (Line: 51)\nDrupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle() (Line: 36)\nDrupal\\Core\\StackMiddleware\\AjaxPageState->handle() (Line: 51)\nDrupal\\Core\\StackMiddleware\\StackedHttpKernel->handle() (Line: 741)\nDrupal\\Core\\DrupalKernel->handle() (Line: 19)\n", name: "AjaxError", stack: "@https://test.net/core/misc/ajax.js?v=10.4.3:196:32\n@https://test.net/core/misc/ajax.js?v=10.4.3:1935:3\n" }
​
message: "\nAn AJAX HTTP error occurred.\nHTTP Result Code: 500\nDebugging information follows.\nPath: /admin/structure/webform/manage/questionari_conxeiments_tic/element/add?parent=flexbox\nStatusText: error\nResponseText: The website encountered an unexpected error. Try again later.TypeError: substr(): Argument #1 ($string) must be of type string, int given in substr() (line 44 of modules/contrib/media_contextual_crop_iwc_adapter/media_contextual_crop_iwc_adapter.module). media_contextual_crop_iwc_adapter_form_alter() (Line: 552)\nDrupal\\Core\\Extension\\ModuleHandler->alter() (Line: 839)\nDrupal\\Core\\Form\\FormBuilder->prepareForm() (Line: 285)\nDrupal\\Core\\Form\\FormBuilder->buildForm() (Line: 73)\nDrupal\\Core\\Controller\\FormController->getContentResult()\ncall_user_func_array() (Line: 123)\nDrupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->Drupal\\Core\\EventSubscriber\\{closure}() (Line: 638)\nDrupal\\Core\\Render\\Renderer->executeInRenderContext() (Line: 124)\nDrupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)\nDrupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->Drupal\\Core\\EventSubscriber\\{closure}() (Line: 181)\nSymfony\\Component\\HttpKernel\\HttpKernel->handleRaw() (Line: 76)\nSymfony\\Component\\HttpKernel\\HttpKernel->handle() (Line: 53)\nDrupal\\Core\\StackMiddleware\\Session->handle() (Line: 48)\nDrupal\\Core\\StackMiddleware\\KernelPreHandle->handle() (Line: 28)\nDrupal\\Core\\StackMiddleware\\ContentLength->handle() (Line: 116)\nDrupal\\page_cache\\StackMiddleware\\PageCache->pass() (Line: 90)\nDrupal\\page_cache\\StackMiddleware\\PageCache->handle() (Line: 50)\nDrupal\\ban\\BanMiddleware->handle() (Line: 48)\nDrupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle() (Line: 51)\nDrupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle() (Line: 36)\nDrupal\\Core\\StackMiddleware\\AjaxPageState->handle() (Line: 51)\nDrupal\\Core\\StackMiddleware\\StackedHttpKernel->handle() (Line: 741)\nDrupal\\Core\\DrupalKernel->handle() (Line: 19)\n"
​
name: "AjaxError"
​
stack: "@https://test.net/core/misc/ajax.js?v=10.4.3:196:32\n@https://test.net/core/misc/ajax.js?v=10.4.3:1935:3\n"

Thanks

The thing is I'm not sure this is the right fix as the label method has the following signature:

  /**
   * Gets the label of the entity.
   *
   * @return string|\Drupal\Core\StringTranslation\TranslatableMarkup|null
   *   The label of the entity, or NULL if there is no label defined.
   */
  public function label();

The label method can return NULL, so modules dealing with labels should account for that, so to me this is a won't fix.

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

@jana_najdi01 could you provide a full repeatable scenario from a fresh Drupal 11 install ?

Otherwise we won't be able to help much.

Your problem is most probably not related to this current issue.

You're welcome @dydave! And thanks to you as well, for committing yet another improvement, however small -- it all adds up, to making Admin Toolbar a leaner and more manageable unit, since there are fewer elements to keep track of.

Eventually, all these seemingly marginal gains coalesce into having a large cumulative effect, allowing Drupal to really take off 🚀

Note: BlockListBuilder extends ConfigEntityListBuilder and that ’s probably worth looking out for, rather than the special case of blocks.

ptmkenny → closed merge request !87

FrankenPhp is going to the PHP GitHub org:
https://externals.io/message/127347 with some of the doc moving to PHP.net

Made the Ai assitant field required:

Please review.

Automatically closed - issue fixed for 2 weeks with no activity.

I think we should fix the table to allow html. It means all the existing messages will work.

I noticed the docs in doRender() were not adjusted:

     // Set the bubbleable rendering metadata that has configurable defaults, if:
     // - this is the root call, to ensure that the final render array definitely
     //   has these configurable defaults, even when no subtree is render cached.
     // - this is a render cacheable subtree, to ensure that the cached data has
     //   the configurable defaults (which may affect the ID and invalidation).
-    if ($is_root_call || isset($elements['#cache']['keys'])) {
+    if (isset($elements['#cache']['keys'])) {

They still mention that doRender() can be the root call, and from the MR it seems that doRender() should no longer be concerned with any of that. Tackle this in a tiny follow-up?

Thanks a lot @ressa!

Worst case: we don't necessarily need to wait for Eric's (@ericmulder1980) feedback:

Mostly, what remains for this issue:

Let's get the patch validated (RTBC-ed if possible)?
Were you able to test the patch from the merge request above MR!122, check the wording, check the message and feature (display of the error message)?

Anything that could help validating and confirming the changes so they could be pending merge for the next stable ...

Basically, if you could test the patch:
On a Drupal Core version above 10.3, apply the patch, then enable the admin_toolbar_links_access_filter module.
Just check the message displays as expected and whether you think the wording is clear enough....

That should be enough for us to RTBC the issue and get it merged quickly after 👌

I wish Eric (@ericmulder1980) could have replied on this, but if we can't get a reply before the next release, then it would be great if you could maybe take a very quick look at this one, just to confirm everything is in order 🙂

The impact of this MR is very limited, so it should be very safe to merge 👍
Bear in mind all of this should be trashed once the admin_toolbar_links_access_filter module can be removed from the code base (when support below 10.3 is dropped).

Let us know if you catch anything or have more suggestions or comments on any aspects of this ticket or the merge request, it would definitely be very helpful! (as always @ressa 😉)
Thanks in advance!

@almunnings →
I am getting the below error after applying the patch.
Method 'getCacheId' not found in AlterableComposableSchema

The website encountered an unexpected error. Try again later.<br><br><em class="placeholder">Error</em>: Call to undefined method Drupal\graphql_compose\Plugin\GraphQL\Schema\GraphQLComposeSchema::getCacheId() in <em class="placeholder">Drupal\graphql\Plugin\GraphQL\Schema\AlterableComposableSchema-&gt;getSchemaDocument()</em> (line <em class="placeholder">116</em> of <em class="placeholder">modules/contrib/graphql/src/Plugin/GraphQL/Schema/AlterableComposableSchema.php</em>). <pre class="backtrace">Drupal\graphql\Plugin\GraphQL\Schema\SdlSchemaPluginBase-&gt;getSchema(Object) (Line: 254)

Changed my mind on this and decided to commit the update hook after testing it on a site experiencing this. Thank you!

ptmkenny → reopened merge request !87

ptmkenny → closed merge request !87

This handler doesn't prevent submissions as far as I know. Are you sure the 'Disable saving of submissions' option is not enabled on your webform? Are submissions being saved when you remove the handler?

Playing around with this a little and the following working “pseudo code” (i.e. please don’t actually use this as is - it is just to test ideas) gives the idea of what I’m thinking:

function xx_form_alter(&$form, FormStateInterface $form_state, $form_id) :void {

  // Get out of here if it is not an admin form.
  if (!\Drupal::service('router.admin_context')->isAdminRoute()) {
    return;
  }

  // We need an actual object rather than just a jumble of array items.
  $form_object = $form_state->getFormObject();

  // Assume forms have no config to begin with.
  $has_config = FALSE;

  // Does the getEditableConfigNames method exist on the form?
  if (method_exists($form_object, 'getEditableConfigNames')) {
    $has_config = TRUE;
  }

  // Are we editing an entity that has config form for it's setup?
  if ($form_object instanceof EntityForm) {
    $entity = $form_object->getEntity();
    if ($entity instanceof ConfigEntityInterface && !$entity->isNew()) {
      $has_config = TRUE;
    }
  }

  // Permisions being permissions.
  if ($form_object instanceof UserPermissionsForm) {
    $has_config = TRUE;
  }

  // Blocks being blocks.
  if ($form_object instanceof BlockListBuilder) {
    $has_config = TRUE;
  }
  // Okay, warn people.
  if ($has_config) {
    \Drupal::service('messenger')->addWarning(t("This form is likely to alter the running configuration of the site and, therefore, changes should probably go through the development quality processes."));
  }

}

definitions/attributes/properties/third_party_settings is missing "type": "object"

@symbioquine and @wimleers are correct: type is no longer missing, but it is not correct. It should be object instead of array.

I am noticing a similar issue in definitions/relationships/properties/roles/properties/data in the /jsonapi/user/user/resource/schema endpoint (which is not a config entity resource type, but relates to one):

Notice how it declares "type": "array" instead of object, and includes an items array. Just like in the third_party_settings example.

This does feel related to #3324824: Schema incorrect for config entity "fields" that are Maps and Sequences → as @wimleers pointed out ( https://www.drupal.org/project/jsonapi_schema/issues/3324824#comment-148... → ). I wonder if we should close this as "outdated" and work on fixing config entity normalization generally over there.

2. Some of the properties like: langcode, theme, region, … are incorrectly under definitions and they should be under definitions/attributes/properties/

This appears to be resolved in 8.x-1.x. Not sure when it was fixed, but they are all under definitions/attributes/properties/ now.

My experience is the same as of @ronttizz
After some debugging, the issue is caused by the way translation is created in AiTranslateController::insertTranslation():

  public function insertTranslation(
    ContentEntityInterface $entity,
    string $lang_to,
    array &$context,
  ) {
    $translation = $entity->addTranslation($lang_to);

compared to how it is done in core's ContentTranslationController::prepareTranslation():

    $target_translation = $entity->addTranslation($target->getId(), $source_translation->toArray());

i.e. in AI, translation is created with empty defaults, while in core it is prepopulated by the source entity values.

Adding the source values in AI

  public function insertTranslation(
    ContentEntityInterface $entity,
    string $lang_to,
    array &$context,
  ) {
    $translation = $entity->addTranslation($lang_to, $entity->toArray());

solves the issue for me. Can someone confirm if this works?

harlor → made their first commit to this issue’s fork.

The environment is fixed.

Ok working on it!!

vishakhaambekar → made their first commit to this issue’s fork.

I have created an MR based on the patch in #4 with some additional changes
1. Got the following error for blocks
When a #lazy_builder callback is specified, no properties can exist; all properties must be generated by the #lazy_builder callback. You specified the following properties: #prefix, #suffix, #access

So updated the lazybuilder callback to include the #access, #prefix and #suffix properties. But the Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\BlockComponentTest::testRenderComponentLive fails as #prefix and #suffix are not included in the assertion. Should the test be updated, or is there a better approach?

Thanks a lot @ressa once again for the prompt and positive feedback! 🙏

This is rather minor, but since we're at it, we might as well try squeezing in as much clean-up as possible before the release 😅
Just like you did with the Admin Toolbar Search settings form path 👍

I personally think the comment linked in the IS to the related issue, sums up very well the different options and removing the file 'CHANGELOG.txt' probably seems like the simplest option for this module right now 🙂 (and for its maintainers 😅)

Following your confirmation, I went ahead and merged the changes above at #5: another issue Fixed for this release 🥳

Let us know if you spot any other "small" changes that could help further polishing the module before its release (in a week🤞), I would certainly be glad to take a closer look very quickly 👌
Thanks again for all the great help reviewing and testing these issues!

hamza_niazi → changed the visibility of the branch 3431150-d11-update to hidden.

Automatically closed - issue fixed for 2 weeks with no activity.

It does look unrelated, @sandip you can always try to run that specific failing test again, to make it go green?

Also, adding the GIF's in the Issue Summary, to show visually what this issue is about.

dieterholvoet → opened merge request !12