Just merged this and will be tagging a new release.
This happened to me after installing our profile and logging into the page and navigating to the content overview page. After rebuilding the caches the error goes away.
@benstallings I've opened a follow-up and pointed to your MR - 📌 Drupal 11 support Active
Maybe working a little bit through the issue queue or even providing the D11 upgrade would help with the decision.
You're welcome :). It would be great though if everyone that was experiencing the issue could update locally their autosave_form module (composer update drupal/autosave_form) and check that they do not experience this issue anymore.
I feel like everyone in here deserves a credit. I just released a new version 1.9 with this workaround.
I dig deeper into it and found what could be potentially causing autosave_form to cause this strange behavior. I investigated further the referenced issue 🐛 Ajax error ajax.$form.ajaxSubmit() is not a function RTBC and now I am introducing a workaround to ensure that autosave_form would not be causing this issue for anyone until Drupal core accepts my proposed solution over there.
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? :)
In the meanwhile I am moving it back to the "Drupal CMS development repository" project so that it can get more eyes on it as it seems rather related to a different bug and not really caused by autosave_form.
After digging through the issue queue this seems rather related to 🐛 Ajax error ajax.$form.ajaxSubmit() is not a function RTBC . Could you please check if you can still reproduce it after applying the patch from over there?
Whoever is experiencing this, could you please check your "recent log messages" if a more descriptive error is being logged?
Also maybe observe the network tab in the browser console and show some screenshots from there when this error occurs.
Closing in favor of 🐛 "Experimental" autosave on form change is enabled, but doesn't work. Active that has some work going on already.
I want to bring the attention also to 🐛 "Experimental" autosave on form change is enabled, but doesn't work. Active . Maybe if the experimental features gets working we do not need other features to prevent unnecessary submissions?
Accepted. Thank you!
I tested with Drupal 10.3.6 and everything seems to be working fine and CKE5 changes get autosaved and can be resumed.
I think what you refer to is about when the exprimental feature is enabled to autosave only on form change. I will close this issue and link your solution to 🐛 "Experimental" autosave on form change is enabled, but doesn't work. Active .
1. You are adding the new message, but not using it anywhere.
2. Further I think we should add everything to the regular settings file as maybe we should merge the messages file into it - otherwise the edit form looks strange editing two different configs.
Thank you, I just merged it as it looks quite better now!
Before:
After:
@attilatilman, yes this makes sense, thank you. Merged.
I've reset it to the default template since there is no reason to overwrite default variables for this project. This is now merged.
Merged. Thank you!
Merged. Thank you!
@rkoller I tested the MR and I was able to see the autosave-form-save class in the DOM and also that the autosaving still works, as well as resuming from a draft or rejecting a draft.
Regarding the deprecation notice this was resolved with https://www.drupal.org/project/autosave_form/issues/3355495 🐛 PHP 8.2 deprecation issue with AutosaveFormBuilder Needs work some time ago.
I have merged the MR now.
Uploading a static patch of the MR.
Uploading a static patch.
Uploading a static patch of the MR:
Static patch for the MR:
The updated MR results into the following script on the page:
<script type="text/plain" data-type="application/javascript" data-name="google-tag-manager" data-src="/modules/contrib/google_tag/js/gtm.js?snvjrf"></script>
The current version is not loading GTM on urls that are consisting of multiple slashes, e.g. example.com/x/y will try to load the script from https://www.example.com/x/modules/contrib/google_tag/js/gtm.js which is clearly the wrong path. The issue relies in how the data-src is created and is missing the leading slash so the links look like this in the DOM before being processed by klaro:
<script src="/?snv6li" type="text/plain" data-type="application/javascript" data-name="google-tag-manager" data-src="modules/contrib/google_tag/js/gtm.js"></script>
Next to not having the leading slash one can also see that the version query string is added to the src and not to the data-src attribute which is also wrong.
Uploading patches for current dev version and for beta2.
hchonov → created an issue. See original summary → .
And is now included in the new D11 release.
Feel free to create a new issue for this please. A new version supporting D11 was just released.
This was just merged. Thank you!
I've merged only what the Automated Project Update Bot did, not sure why the other commits were done. I will test this with Drupal 11 and if all works fine I will tag a new release.
hchonov → changed the visibility of the branch project-update-bot-only to active.
hchonov → changed the visibility of the branch project-update-bot-only to hidden.
hchonov → changed the visibility of the branch project-update-bot-only to hidden.
hchonov → changed the visibility of the branch project-update-bot-only to active.
hchonov → changed the visibility of the branch project-update-bot-only to active.
Could you please elaborate on how this can be reproduced? In this function apparently we are running into an autosave submission, but the autosave submit element is not there, which does not seem right.
Thank you. This is now merged.
Actually I've just discovered that an existing search page config in the system is even missing the uuid and this is still breaking for me when saving as a config entity. This is what the config_plus module was created initially for to prevent from configs in the system without uuids. It turns out this config has the issue. Further it is not even possible to set the update due to core checking for the uuid changing ignoring the fact that it might not be there at all. I am just including a quick fix in here and we can discuss how to proceed.
I am not really sure why config factory instead of the config entity API was used here to create new entities, but this is not the right way. The config_plus → modules catches such issues and throws errors, which is how I've found out about this. Maybe I am missing something or should I open a new issue to fix this?
Our use case is like this that we have a content type that is not translatable, but the site has multiple languages enabled without language detection enabled and it is possible to create content in that content type for different languages. However since pathauto automatically creates the aliases with the language of the entity if we would create content in a non-default site language then we cannot visit the url of the page. I think that we need an approach similar to 🐛 If you don't want to translate your URL alias, the original URL alias won't work with your translations Needs work that will set the language to undefined in case the entity is not translatable. The only issue I can think of is though what should happen if the content type is made translatable at a later point, so this needs to be defined and tested how the aliases old and new will behave.
This was just merged. Thank you!
This was already resolved in another issue.
This was just merged. Thank you!
This was already fixed.
Thank you. This was just merged.
hchonov → made their first commit to this issue’s fork.
This is now fixed.
The method in the MR needs also to be implemented properly and not to be left with a simple TODO :).
effulgentsia → credited hchonov → .
I've just merged this one into 2.x.
valthebald → credited hchonov → .
valthebald → credited hchonov → .
Thanks for the remainder, @BramDriesen :)
Thank you. This will be part of the 1.6 release.
Does the layout builder use a dedicated operation as well? I mean can we fix it in a similar way as it was done here - 🐛 Stop triggering autosave on delete forms Fixed ?
Merged. Thank you. This will be part of the 1.6 release.
Merged. Thank you. This will be part of the 1.6 release.
The patch here fixes the issue for me where when accessing the page with a bad / wrong query parameter for the contextual filter with cold caches the page gets cached without the view and then accessing the page again without any query parameter returns again the page without the view instead of showing the view with all available filters.
I can only confirm the issue as it happened to me as well.
I've noticed there were still a lot of duplicates in the queue, so adding a condition to not create a queue item if the same one already exists in the queue.
Re-roll.
LGTM