🇪🇺🇩🇪🇧🇬
Account created on 19 May 2014, over 10 years ago
#

Merge Requests

Recent comments

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Just merged this and will be tagging a new release.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov created an issue.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

@benstallings I've opened a follow-up and pointed to your MR - 📌 Drupal 11 support Active

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov created an issue.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Maybe working a little bit through the issue queue or even providing the D11 upgrade would help with the decision.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

I feel like everyone in here deserves a credit. I just released a new version 1.9 with this workaround.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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? :)

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬
🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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?

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Closing in favor of 🐛 "Experimental" autosave on form change is enabled, but doesn't work. Active that has some work going on already.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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?

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Accepted. Thank you!

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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 .

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Thank you, I just merged it as it looks quite better now!

Before:

After:

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

@attilatilman, yes this makes sense, thank you. Merged.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

I've reset it to the default template since there is no reason to overwrite default variables for this project. This is now merged.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Merged. Thank you!

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Merged. Thank you!

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Uploading a static patch of the MR.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Uploading a static patch.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Uploading a static patch of the MR:

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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>

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Uploading patches for current dev version and for beta2.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov created an issue.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

And is now included in the new D11 release.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Feel free to create a new issue for this please. A new version supporting D11 was just released.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov changed the visibility of the branch project-update-bot-only to active.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov changed the visibility of the branch project-update-bot-only to hidden.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov changed the visibility of the branch project-update-bot-only to hidden.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov changed the visibility of the branch project-update-bot-only to active.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov changed the visibility of the branch project-update-bot-only to active.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Thank you. This is now merged.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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?

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

This was just merged. Thank you!

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

This was already resolved in another issue.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

This was just merged. Thank you!

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov made their first commit to this issue’s fork.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

This is now fixed.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

The method in the MR needs also to be implemented properly and not to be left with a simple TODO :).

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Thanks for the remainder, @BramDriesen :)

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Thank you. This will be part of the 1.6 release.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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 ?

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Merged. Thank you. This will be part of the 1.6 release.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Merged. Thank you. This will be part of the 1.6 release.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

I can only confirm the issue as it happened to me as well.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

hchonov created an issue.

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

Re-roll.

Production build 0.71.5 2024