search

CuBoulder / ucb_migration_shortcodes

A module that works alongside the Shortcodes module to ease the burden of migration.
0 stars 0 forks source link

Shortcodes in the Contact Info block #15

Closed jcsparks closed 6 months ago

jcsparks commented 7 months ago

Shortcodes in the Contact Info block don't seem to render properly. Not sure if this is an issue with the theme or the Site Configuration module.

It looks like this was a pretty common practice to use this to add icons into this area though... if it's possible to add support for shortcodes in that block it would help make the migration go more smoothly.

timurtripp commented 6 months ago

Shortcode issues should go in the Migration Shortcodes repo to avoid cluttering our other repos with such an antiquated technology.

As for why they're not working in this field, I'm not exactly sure. Contact info is standard in that it's WYSIWYG field using our text format, but special in that it isn't part of any block type, paragraph type, or content type. I don't see extra <p> tags inserted or any other funny business that could interfere with the Shortcode I entered. @jnicholCU do you have any ideas on this one?

timurtripp commented 6 months ago

I'm guessing it may need a partial rewrite of the contact info block to work. Whatever the Shortcode module hooks into likely isn't getting triggered by the way this field is rendered on the page. Template file: block--site-info.html.twig in the theme, line 46:

<span class="ucb-site-contact-info-footer-content ucb-site-contact-info-footer-general-content">{% if item.value.format == 'wysiwyg' or item.value.format == 'full_html' %}{{ item.value.value | raw }}{% else %}{{ item.value.value | nl2br }}{% endif %}</span>
jnicholCU commented 6 months ago

Yeah it looks like the |raw could be the issue. We shouldn't be using that anyways so that is something we should change for the rendering of that item value. Barring that I'm not sure why it wouldn't work in that field as it's using the normal ckeditor 5 wysiwyg field. Will try out some things with the way we're grabbing that value because the item.value.value might be causing the difference here.

timurtripp commented 6 months ago

I would've only used |raw as a last resort, definitely after trying everything else.

timurtripp commented 6 months ago

It's not like a field on a node or block type, it was only giving me the HTML from the WYSIWYG as a string.

jnicholCU commented 6 months ago

Yeah I was going through it some more last night and it's mostly likely because it's just being passed in as a string of html. I've got a couple ideas of how to get it working so I'm going to test those this morning. I also think I know how to switch from the |raw at the very least. I'll keep you guys posted.

jnicholCU commented 6 months ago

@timurtripp are we able to get "#formatter" => "text_default" and "#type" => "processed_text" added to our site config values for that item? Need to pass through the processed item rather than the data string if possible. According to documentation (some guy on stackexchange) that should hopefully fix our issue.

jnicholCU commented 6 months ago

From what I can tell formatter needs to be at the same level as the label and type needs to be within the value with format I don't know if this is going to actually fix the issue or not. I'm not sure what the needs to be done for the site config to transfer processed text instead of a string in the array.

timurtripp commented 6 months ago

@jnicholCU Site Configuration/src/Plugin/Block/SiteInfoBlock.php

timurtripp commented 6 months ago

I'm not seeing that working though.

timurtripp commented 6 months ago

After playing around with the render array I finally found a fix. PR up shortly.