🇺🇸United States @maddentim

I think we can close this one out. Thanks for your attention.

> The default is is-ultimobile since I hardly have desktop versions.
I think they are still pretty common to have a desktop version, especially for existing sites. I am not as familiar with the code as you, but it is not clear to me why the JS needs to add the .is-ultimobile to html element before it has figured out if we are touch or not. I will look to work around it as I am sure you have your reasons.

OK, progress has been made. I added the is-ultimenu to the classes in the template for my html element and added the is-ultimenu__canvas-on / is-ultimenu__canvas-off as needed to my page tempages. All that is looking nice. I also went through my styles and switched the styling for the mobile/desktop to rely on the is-ultidesktop or is-ultimobile class in the html element to align with the way that the module works now.

My last issue is with the desktop. On my staging site, I am seeing a flash of bad styling. Watching the page load, I am seeing the is-ultimobile class appear for an instant and then get replaced by the proper is-ultidesktop class. In that instant, things don't look so nice. I checked my html element in the template, but it is not coming from there. This seems like a possible bug. I could probably change my styles not to rely on the is-ultimobile which seems like not the way it should work. I have not overridden the module js.

This is a little off the path of this issues original topic. If you need me to start a new ticket, I can.

Hey Gaus,
You convinced us and we are biting the bullet and attempting to get our site using the 3.x branch. I have it all looking identical when loaded, however, I have an instant of jumpiness on both mobile and desktop where the menu is styled wrong for a few hundred milliseconds before it straightens itself out. I tried inlining a couple key styles to no avail. The jumpiness is not present in the 8.x version. I am wondering if I has to change to "no longer relying on media queries". I am going to dive into that next. If you have any suggestions, I am all ears.
Thanks

Hey, how can I help to get a D11 compatible release? The issues look minimal.

Thanks

This issue is blocking my ability to upgrade a site to D11. It was a bit of a head scratcher as the module said it was D11 compatible, but composer thought otherwise. I would appreciate a new release with the fix.

Hey, sorry, but I cannot really justify to the client why they need to spend my time on reworking this when the current code works and is compatible with Drupal 11. We have a lot on our plate and reworking the menu system is not on the list. It might be an hour or it might be more. The changes to go to 3.x are definitely breaking. I am certain there were good reasons to make them. I am not questioning that in the slightest. If we were starting fresh, I would be using 3.x, but that is not where we are.

I think they will opt to just go off the reservation so to speak.

maddentim → created an issue.

@hiramanpatil I believe this is fixed in 10.3.6.

Yep! Thanks for your support!

This is all good to hear. I reviewed the twig_tweak and the src for the footnotes block, the {{ drupal_block('footnotes_group', { group_via_js: true }) }} looks easy enough.

What I am not sure about is the cache part. Looking at the source for footnotes, I see on line 17 of the FootnotesGroupBlock.php file that we have the entity @ContextDefinition there. I am not sure how I would set that with the tweak. When I set that for the provided footnotes_block, is that saying that if I set it to "Node from URL" that if the node cache has been invalidated that the block should as well. So that it stays updated when the node changes?

I agree on the popups for the footnotes. I showed that to the main site editor and he was interested. We are talking this afternoon to go over this stuff so I will bring that up again. Thanks!

maddentim → created an issue.

Do we still need the type_data dependency in social_share.info.yml after this change?

type: module
name: Social Share
description: 'Contextually configurable social share buttons.'
package: Social media
core_version_requirement: ^8 || ^9 || ^10
dependencies:
 - typed_data:typed_data

Fixed truncated title

I tried updating typed_data to 2.1.0 and switching out the use statement in src/SocialShareLinkManager.php to be the Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery. This fixed the fatal error, but the social share buttons are not rendering. I am not sure if it is a database issue and when I have more time I will try refreshing the database from production and seeing if it works again. It might be a few days though.

maddentim → created an issue.

I think the issue is on line 82 here: https://git.drupalcode.org/project/footnotes/-/blob/4.0.x/footnotes.inst...

That directory recently got renamed to "optional" instead of "install". I am assuming changing that would resolve the update issue.

maddentim → created an issue.

Just circling back here. We could not wait for a real fix from upstream so we opted to develop an alter hook that uses DOMDocument() to restructure the HTML prior to sending it into CK5. While our hook is very specific to our quirky button structure, maybe someone can use parts to fix their own issues!

/**
 * Alters the existing ckeditor content before loading to tranform the buttons
 * into a compatible structure for ckeditor5.
 *
 * @param array $element
 * @param \Drupal\Core\Form\FormStateInterface $form_state
 * @param array $context
 */
function MYMODULE_field_widget_single_element_form_alter(&$element, FormStateInterface $form_state, $context) {
  $formats = ['full_html', 'full_html_w_o_correction', 'basic_html'];
  if (key_exists('#format', $element) && in_array($element['#format'],$formats)) {
    $element['#default_value'] = _transformHtml($element['#default_value']);
  }
}

function _transformHtml($htmlFragment) {
  $doc = new DOMDocument();
  libxml_use_internal_errors(true);
  $doc->loadHTML('<div>' . mb_convert_encoding($htmlFragment, 'HTML-ENTITIES', 'UTF-8') . '</div>', LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD);
  libxml_clear_errors();

  $dummyRoot = $doc->getElementsByTagName('div')->item(0);

  $xpath = new DOMXPath($doc);

  /** Transform two cols buttons */
  $buttonWrapperTwoCols = $xpath->query(".//span[contains(concat(' ', normalize-space(@class), ' '), ' button-wrapper-two-col ')]", $dummyRoot);
  foreach ($buttonWrapperTwoCols as $span) {
      $div = $doc->createElement('div');
      $div->setAttribute('class', $span->getAttribute('class'));

      foreach ($span->getElementsByTagName('span') as $innerSpan) {
          foreach ($innerSpan->getElementsByTagName('a') as $a) {
              $newA = $a->cloneNode(true);
              $newA->setAttribute('class', 'btn');
              $div->appendChild($newA);
          }
      }

      $span->parentNode->replaceChild($div, $span);
  }

  /** Transform standalone buttons */
  // De-nest any spans
  $nestedButtonWrappers = $xpath->query(".//span[contains(concat(' ', normalize-space(@class), ' '), ' button-wrapper ')]//span[contains(concat(' ', normalize-space(@class), ' '), ' button-wrapper-two-col ')]");
  foreach ($nestedButtonWrappers as $nestedSpan) {
    $parentSpan = $nestedSpan->parentNode;
    if ($parentSpan && $nestedSpan !== $parentSpan) {
      while ($nestedSpan->firstChild) {
        $child = $nestedSpan->firstChild;
        if ($child->nodeName === 'a') {
            $parentSpan->insertBefore($child, $nestedSpan);
        } else {
            $nestedSpan->removeChild($child);
        }
      }
      $parentSpan->removeChild($nestedSpan);
    }
  }

  // Process all 'button-wrapper' spans for transformation
  $buttonWrappers = $xpath->query(".//span[contains(concat(' ', normalize-space(@class), ' '), ' button-wrapper ')]", $dummyRoot);
  foreach ($buttonWrappers as $span) {
    if ($span->parentNode) {
      $aElements = iterator_to_array($span->getElementsByTagName('a'));
      foreach ($aElements as $a) {
        $newA = $a->cloneNode(true);
        $newA->setAttribute('class', 'btn');

        if (!empty($span->parentNode)) {
          $span->parentNode->replaceChild($newA, $span);
        }
        else {
          $dummyRoot->appendChild($newA);
        }
      }
    }
  }

  $transformedHtml = '';
  foreach ($dummyRoot->childNodes as $child) {
    $transformedHtml .= $doc->saveHTML($child);
  }

  return $transformedHtml;
}

I have a similar situation with a site now running Drupal 10.2.1 with ckeditor4 still. The blocker to going to ckeditor5 is that they have existing buttons like this:

<p>
	<span class="button-wrapper-two-col">
		<span class="button-wrapper">
			<a href="https://new-philanthropists.org" target="_blank">Learn About NGAAP</a>
		</span>
		<span class="button-wrapper">
			<a href="/donate/new_generation_african_american_philanthropists">Join NGAAP</a>
		</span>
	</span>
</p>

the outer wrapper is just to make two buttons go side by side on desktop.
When this code is opened in ckeditor 5, it is transformed into:

<p>
  <a href="https://new-philanthropists.org" target="_blank">
		<span class="button-wrapper-two-col button-wrapper">Learn About NGAAP</span>
	</a>
	<span class="button-wrapper-two-col"> </span>
	<a href="/donate/new_generation_african_american_philanthropists">
		<span class="button-wrapper-two-col button-wrapper">Join NGAAP</span>
	</a>
</p>

This rearranging of the code breaks our button styling. I am open to changing our button CSS, but I don't see how I can make buttons with the current output. I tried turning off the "Correct faulty and chopped off HTML" to no avail.

Recently, I have been looking for a way to alter the input sent to the editor such that we could do some regex magic to find the buttons and rewrite the code so it works. My only solution that I see so far would be to set up a hook_form_alter function, look for the form_ids we need, then look for the fields and rewrite them. We have about 25 ckeditor fields so that could become a pretty hairy function. Open to suggestions.

maddentim → made their first commit to this issue’s fork.

Here is a patch that includes the rector patch and the change to the info file. This allow us to upgrade to drupal 10.

Well, upon further review, my issues were introduced by a patch I was using from another field_group issue. I would say to close the issue if not for the issue @klelostec has made a patch to fix his issue.

maddentim → created an issue.

Well, a scan with upgrade_status module comes out with no real issues besides the info file not being marked as ^10 compatible. I have a project that uses this site in Drupal 7 and we will be upgrading to Drupal 10. For now, I have copied this module in the project to modules/custom with the ^10 marked. We would be interested in a release that would be compatible with Drupal 10.

Thanks Aaron for the response. Looking at the database table structures, I see they are pretty similar. That sounds like a decent path to go.

Another idea I have thought of would be to just migrate the content type structure and not the data on the Drupal side. From there, we could set up the mapping of the fields that we needed back in Drupal and then pull the data out of Salesforce. So basically, instead of migrating Drupal to Drupal, we migrate from Salesforce to Drupal for this data. .

Well, it looks like we are going to get serious about this migration soon. I don't think migrating the mapping is critical, but the salesforce_mapping_object and salesforce_mapping_object_revision might be. I am going to start by studying what other modules have done for similar structures.

Just so all understand the history, this return statement got introduced from this issue: https://www.drupal.org/project/conditional_fields/issues/3207751 🐛 URL validation of link field doesn't work Fixed

I am going to add this patch from #15 in my project for now so we can use the alpha3 relese, but long term I think the project probably needs to find a solution that does not just break the link validation issue again from 3207751.

I can also confirm the patch resolves the issue and applies cleanly to the 4.0.0-alpha3 release.

This patch is out of date now. Not sure if other changes in the code have effected this issue's "Problem/motivation"...