Thanks for pointing this out to me.
I can cofirm this issue. It appears, no block settings can be changed while ajax_blocks is active.
My current workaround is:
1. Deactivate block_ajax module
2. Change the block properties
3. Reactivate block_ajax module
4. Reactivate "Load block via Ajax" checkbox for the desired blocks
You will find those settings under /admin/structure/types/manage/%NODE-TYPE%/display
Thank you for solving this old issue.
e5sego → created an issue.
Looks ok for me.
I called the update script from this branch and the summary texts were retained.
A summary can also contain html. It always has the same format as the longtext. But in my opinion the use of footnotes in a summary would be extremely unusual.
Voilà, now the result of convertion lokks as expected:
Body content:
I am the body text with a footnote followed by punctuation<footnotes data-value="" data-text="Text in footnote"></footnotes>. More text.
Here ist a second example<footnotes data-value="" data-text="Text in footnote"></footnotes> where the text continues.
And the browser output look as expected.
May worth to mention, a additional
within the text does not cause a newline/whitespace to be added.
Thanks for solving this!
I have double-checked this by creating a fresh installation of Drupal 10.2 with minimal configuration. No text editor and only the footnotes filter is activated (see attached screenshot)
Unfortunately, the line break always occurs after the conversion. This can be seen in the same way both in the backend on node edit and in the database cell.
I corrected my above comment in the meantime.
The conversation creates an unwanted linebreak, the browser displays a whitespace.
I checked there is no twig debugging enabled and no other filter than footnote is enabled while the drush convert run.
Do you have any ideas what else I could try?
Using the 4.x branch works fine for new content.
But now I found during the drush conversation run, there will also be a whithespace inserted after the footnote number.
Example:
1. Insert content having 3.x syntax using CKEditor 5 source code editing:
Lorem ipsum[fn]Footnote text[/fn]. Dolor met...
2. run drush footnotes:upgrade-3-to-4 node
3. This results in following (CKeditor source view):
Lorem ipsum<footnotes data-text="Footnote text" data-value=""> </footnotes> . Dolor met alpis.
The second $nbsp; before the puctuation is the problem here.
Hi @scott_euser,
I can confirm translated content got updated too using this branch.
Thanks for make this work!
Yes, just gave it a first try, but run into this new issue 🐛 Translated content not updated from 3 to 4 syntax Fixed with translated nodes.
For me the patch from #3 works well on Drupal 10.2.x Thanks!
For me, this fork and patch #11 worked under Drupal 10.2, at least at first glance.
^10.0 requires core 10.0.x, so it denies core upgrades to 10.1.x, 10.2.x and above.
Actually, the version contraint to ^10.0 ist still in the module composer.json file. I added a patch to fix that. You will need to regenerate the root composer.lock file after using this patch.
I can confirm what _michel_ described.
Patch from #3 worked like a charm and erstored my site from beeing broken by the D10 upgrade.
Got it, thanks for your advice!
I meant it technical-wise. The compressed leaflet.js has only one line of real code, so the patch contains the whole file.
But for those who want to automate the process of patching using composer, I attached a patch file.
The regarding section for composer.json would look like:
"patches": {
"drupal/leaflet": {
"Fix leaflet maxZoom factor. See https://www.drupal.org/project/leaflet/issues/3247962": "https://www.drupal.org/files/issues/2023-11-01/3247962-Leaflet-fix-maxZoom.patch"
}
}
#11 Works for me, thanks!
I got the same issue in the 10.1.0 version of this module and found a solution.
The library js/leaflet/dist/leaflet.js has a hardcoded value for maxZoom set to 18, which has to be changed to 22.
Attached you will find a fixed and zipped version of this file.
(a patch does not make sense for compressed javascript)
After some testing it seems a cache issue. Image captions which seemed to be lost (booth in view or edit node mode) re-appeared after cache clear.
Hi, I run into the exact same issue as described.