#Needs steps to reproduce

Hello,
I've just removed my proposition as I'm documenting the process on my own to understand it, and I was confused in the managed entities. On the case of inline_block_usage, I understood that the required entity is the parent node, not the block itself.

Ok #13 solves in D11.1.1.

Fixes should be in MRs to see tests run.

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

Closing per #28

@quietone, are you saying you cannot view the "test-only" output here? https://git.drupalcode.org/issue/drupal-3263208/-/jobs/3498941

You don't need to reproduce the issue. The "test-only" run reproduces it for you, lines 48-54 of that job output. That's what it's there for.

I found one wee doc error in the MR and used the suggestion feature to fix that.

The proposed resolution should describe the change so that a reviewer/committers know what to expect in the MR.

I am among the many here, include the views maintainer, that are not able to reproduce this issue. The steps to reproduce is missing the step to install config_inspector and the link to view the report is a 404 for me. Is there other steps missing? I imported the view from #32 🐛 Missing schema for fields and filters on views with aggregation Needs work which is supposed to include the error and again, there are no errors with the config inspector.

Since this is important to Drupal CMS is there a tag to use? There is one for 'Drupal CMS release target' but I can't find an issue for the Drupal CMS release plan.

I've updated credit and leaving at RTBC due to the connection to Drupal CMS.

Nine months has lapsed.

No update since then.

Closing.

#13 reroll for D11.1

I tried applying patch #16 on Drupal 11.1.1 but the problem is not solved.

This has been sitting as postponed for the last 13 years.

It looks like it was reported for Drupal 7.

Issue was only reproduced with specific data.

Looks like the original reporters account is no longer active.

Seems like a potentially related issue is fixed.

@giordy: I am currently using patch from #16 in D11.1.1

Re #33 🐛 Ajax error ajax.$form.ajaxSubmit() is not a function RTBC :

@alexpott I was debugging this because of 🐛 Create a new blog post JS error Active which was thought to be caused by autosave_form. From my observations the attach behaviors (including the ones from <code>ajax.js and autosave_form.js) are executed before the $.fn.ajaxSubmit function is being initialized / set by jquery.form.js.

However as suggested in the issue I add core/internal.jquery.form as a dependency to drupal.ajax then first the $.fn.ajaxSubmit function is being initialized and then the Drupal attach behaviors called.

This indicates that there is difference in how stuff called and

$element['#attached']['library'][] = 'core/internal.jquery.form';
$element['#attached']['library'][] = 'core/drupal.ajax';

is not equal to declaring core/internal.jquery.form as a dependency to drupal.ajax.

I was able to achieve the behavior of initalizing the function without declaring an explicit dependency but just by setting a similar weight to the jquery.form.js file as to the jquery.min.js and now the function is initialized before the attach behaviors are called.

Attaching a patch for that as I think this is the less intrusive change and would not load the core/internal.jquery.form when it is actually not needed.

If we want to still add a test for this then it might have an ajax behavior that checks the ajaxSubmit function being already registered when it is called. Without this patch the test will be failing. Someone wants to write it? :)

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