Wait, Bootstrap was not the problem. This was a Javascript issue which is the same as https://www.drupal.org/project/views_tree/issues/3344199 🐛 Collapsible javascript event attach multiple times RTBC .
I applied that patch and it worked. Does this make it a "Related Issue"?
ANd... Thanks for the Great Module!
Hello again. Please... I see now that this bug was worked on for the Drupal 7 version, but never got included moving forward. The Drupal 8|9|10 code is very different, so I have no idea how to implement this fix now. It seems that Bootstrap's collapse function is fighting your own collapse function, because when I try to expand a row, it expands, collapses, expands again, collapses again and them stays collapsed. I really want to get this to work so I can use it for a better Book Table of Contents. Any chance someone can give me a hint of where to poke? I spent about eight hours poking around, but in the end was not successful.
Howdy! This seems like just what I need, but my site is indeed based on Bootstrap 5. So when I click on something, it expands and then immediately contracts again. Any chance of getting this back in the module? I looked at the patch file and it seems that it has no home in the current 2.0@dev release, so I suspect that the code has moved on. But perhaps the solution of just passing down the wrapper class would work and might be easy to implement.
Solved! There is a Config button further up the Text Format page that has a checkbox that needs to be enabled. See image.
I tried solution #10 and got an error message:
Attempted to create an instance of field with name bp_background on entity type paragraph when the field storage does not exist.
So the fields were not getting purged because there was an accidental deletion of the "bp_background" field's table in the database. After looking all through the Paragraph module, I finally realised that this field was created by the "Bootstrap Paragraphs" module, which I had uninstalled. I re-installed it, ran the drush php-eval 'field_purge_batch(500);' command, got no errors, and then I could uninstall this module.
Documenting this in case it helps someone else find the problem sooner.
Damien, thank you for hanging in there. I don't know if I am still making a stupid mistake or if something is still not working. I have two questions:
First, I don't know what you mean by "a new option in the display settings". It seems most likely that you meant a new option in the Field Formatting options inside of Views, but there is none that I can find. Perhaps I don't have the right field selected for formatting, but here are the formatting options for the field that represents the actual audio file attached to the content:
I can select "URL to File", or "RSS Enclosure" and a few other things, but not "File length" or "Duration".
OK, I spoke too soon. The module installed, but I do not see any new types of information I can add in the Views Fields. Searching for "audio" only gives me the field "Audio file" in the category "media" which I had before I installed this module.
There is no field like "id3" of "playtime" or "length" or "encoding".
Thank you. Yes, this patch fixed it.
I also had to remove the module and reinstall, because the patch wasn't working (the views_rss_media_getid3 was in the wrong place). Don't know how that happened, but probably my fault and not yours.
hyperlogos,
Thanks for the response. I do that, and I still have the error message when I go to enable the module:
Error message
Before you can use the FakeObjects module, you need to download the plugin from ckeditor.com and place it in /libraries/fakeobjects. Check the README.txt for more information. Get the plugin here. (Currently using FakeObjects version Plugin not detected)
So, as I said above, I have a fresh Drupal 10 install, and we no longer seem to have a /libraries folder. At the top level, I only have two folders, "vendor" and "web". Or, perhaps I just ignore the error?
So, can I use Footnotes in Drupal 10? It seems that patch 5 didn't quite work, and thus the need for patch 24, but only Footnotes 3.0.1 is compatible with Drupal 10.
I have this same problem in Drupal 10.1. Actually, my custom paths no not work, and I think it is a translation problem.
I had other problems that might be related, but I don't know where to go to look. When I looks at custom fields in entities, there were errors saying that they could not be translated because there was a language mismatch between the field and the underlying storage. Basically, when I started setting things up I had "la" as the language, but when I added some fields I was using the "en" interface, so the fields got "en", even though I had created them earlier "la" storage (I was reusing them in other content types).
The solution was to use drush to fix the field language:
drush cset field.field.node.dates.field_type langcode la
Is there a way to check for a language mismatch in the path settings and to fix it with drush?
That's it, thank you!
[vps14520]$ drush field-info node statute
+----------------+----------+----------------------------+-------------+
| Field name | Required | Field type | Cardinality |
+----------------+----------+----------------------------+-------------+
| body | | text_with_summary | 1 |
| feeds_item | | feeds_item | -1 |
| field_dates | | entity_reference | -1 |
| field_id | | string | 1 |
| field_parent | | entity_reference_hierarchy | 1 |
| field_subtitle | | string | 1 |
| field_type | ✔ | entity_reference | 1 |
+----------------+----------+----------------------------+-------------+
[vps14520]$ drush entity-hierarchy-rebuild-tree field_parent node statute
Too many arguments to "entity-hierarchy-rebuild-tree" command, expected arguments "field_name" "entity_type_id".
[vps14520]$ drush entity-hierarchy-rebuild-tree field_parent statute
In EntityTypeManager.php line 139:
The "statute" entity type does not exist.
@idaz.roncero I had tried the ordering, but I was using the patch from #24. I noticed that you used the patch from the Git repository #5. It works with that patch, but not with the one from #24 here.
The problem is, when I use your patch and try to enable it, it still requires CKEditor 4 and asks me to Download the FakeObjects module and put it in the /libraries folder. I don't think Drupal 10 has a /libraries folder anymore, or at least I don't since I let it set up the new structure with just /vendor and /web folders at the top level, and will I be able to disable CKEditor 4 later?
Did this patch ever get added? It would make my life a LOT easier, but it doesn't seem like it got into the code, and now we are up version 3.3, so I doubt the patch still works.
I have a new project in Drupal 10 that needs footnotes. The "Drupal 10 compatibility" patch ( 3343180 📌 Drupal 10 compatibility Fixed ) was for version 3.0.1 (and worked). This patch does not work on that version, I assume because it was made to patch version 3.0 (Composer just gave up). Is there a chance to get this patch rolled into the Drupal 10 compatibility?
Yes, this is the same issue, so I will close this one. DomPdf ALSO developed an issue in using font files that have a space or a dash in them, which masked some of the problem, but I will put that issue in their cue.
Thank you.
OK, but DomPdf encountered the same css property in January and had no problem. So did DomPdf just update in an unhelpful way, and could I downgrade or upgrade it to get around this issue?
I just tried with the DEV version, same results. But I noticed that I use the a patch is that matters (the compression messes things up):
https://www.drupal.org/files/issues/2020-10-27/entity_print-allow_choose... →