🇺🇸United States @bwoods

@holo96 thank you for confirming. I figured out the issue - seems as if it was a combination of an overarching class in a custom template being set to transparent plus a loading issue locally in Docker that wasn't fully rendering changes/testing. I've added a style override to ensure .block-cheeseburgermenu-container has a background color, and everything is working as expected. Thanks for your assistance!

@holo96 I tested both 5.1.x or 5.0.x and had the same results. But it sounds as if maybe the issue is that the module requires bootstrap or a bootstrap theme?

Thanks for following up, @thejimbirch. I suspect that the problem was a conflict in my custom theme with bootstrap js. I ended up moving on to something else, but if I come back to it and find out anything further, I will post details.

bwoods → created an issue.

I just ran into this issue after using Entity Share for a couple of months without any issues. It turns out the problem was that I removed a field that's part of an unrelated contrib module from the content type on the Server. Even though that field was not being used, it was creating a record in the field table (previously, since the field was left blank, it wasn't creating any records). JSON:API was picking up this record as part of the node, and because it's a special field, it could not process. To fix this, I had to re-enable the field on the form display screen, edit the node to leave the field blank, and that deleted the record in the field table. By doing this, Entity Share began working again. This seemed rather bizarre, but hopefully this troubleshooting will help someone else!

#12 worked for me as well. I assume the site I patched had a similar history with the upgrades since I recently took them over. Thank you!

@alfthecat I ran into this same issue. I believe my problem was the URL I was using was not a valid URL because it conflicted with a pathauto pattern. I also uploaded a blank PDF since I didn't have a template. Once I did those things, I was able to generate the PDF.

bwoods → created an issue.

#42 works for me. For my use case, I turned off the pathauto pattern on the client side, so I'm dependent on whatever alias comes through from the server. The problem with this (likely what @grimreaper is referring to in #44), is that there's not a check on path aliases already on the site. So if the pulled node has the exact same path alias as one on the existing site, it just overwrites it. So this change is not ideal if there is existing content that may have the same path as new content.

I was able to get this to work by using the processed_text formatter. Here is a code sample that I used in timeline-block.html.twig:

    {% for key,timeline in timeline_data %}
    
      {% set tl_description = {
    	'#type':   'processed_text',
    	'#text':    timeline.description,
    	'#format':  timeline.description_format,
      } %}        
    
      <div class="timeline-2-item">
      <div class="timeline-2-card timeline-2-bg-base text-white border-0">
      {% if timeline.time %}
        <div class="timeline-2-card-header py-2 timeline-2-bg-main rounded-0 border-0">
        {{ timeline.time|raw }}
        </div>
      {% endif %}
      <div class="timeline-2-card-body">
      {% if timeline.title %}
        <h3 class="timeline-2-card-title">{{ timeline.title|raw }}</h3>
      {% endif %}
      <div class="timeline-2-card-text">{{ tl_description }}</div>
      </div>
      </div>
      </div>
    {% endfor %}

This appears to work successfully. From what I understand, the raw filter should be avoided if possible.

I have made a copy of this file and included it directly in my theme, but I could make a patch (and include an update for all layout options, if that would be helpful.

bwoods → created an issue.

I ended up just pulling all files and not filtering because there weren't a ton of inline images altogether.

I see that can just set up a Files channel to pull files. I assume I can use the filtering options to pull precisely the images I need, so I will report back my findings.

bwoods → created an issue.

Like @hockey2112 mentioned, ultimately you just need to delete the data from the tables after removing the Field Collection fields from your nodes, and then you will be able to uninstall this module. Typically what I do in a situation like this is make a copy of the tables (structure and data) then delete the data from the actual tables. In this case, it works without the other steps listed in previous comments.

Thanks, #34 worked for me as well.

I think this patch may have unintended consequences. Today I upgraded from D9 to D10. When I attempted to run database updates, I was stuck on this patch. I do not have a table file_managed_data, only files_managed. I was able to move past this by duplicating files_managed as files_managed_data. After the migration, I tested my content, and no files/data are being inserted into file_managed_data, so I just removed the unnecessary file_managed_data table.

Thanks for the update on this. I was just coming back to look into this with other contrib module updates and saw the fix. I added as a packaged repository in composer, and it seems to work as expected.

I ran into this same problem, and it seemed at first if the patch in #31 worked. However, when I looked a little more closely, I realized the actual issue was that my custom theme was calling two libraries that were not actually enabled (one via a module, one via a theme). These calls were outdated, so once I removed, the notice disappeared, even without this patch.

Thanks for this - #11 also worked for me using a custom conf file with Lando.

Just a followup for #15 – you will want to include ^2.0 || ^3.0 directly in your composer file. Running the listed command will just require 2.0, since composer sees the pipes as a new command.

Patch #30 works for me, thank you!

bwoods → created an issue.

Just in case anyone is still seeing this, I noticed the same error message in my logs recently. Apparently in my case, the issue is that I have a single Webform submission that creates multiple SF records. On return, only one SF record can be mapped to the Webform submission. The error doesn't seem to have any effect on the actual SF records creation.

The reason why it works for @ahmadhalah is because of the values used for "module" and "key." Those reference the test email send through the SMTP configuration. So the errors that the OP is seeing are due to that, and due to the SMTP module not being referenced properly in the mail service.