🇺🇸United States @DamienMcKenna

I recreated the example hook implementation for CKEditor Media Resize, which was my intended use case: ✨ Convert data migrated using Media Migration to new structure Active

This code has been working for me in local testing.

damienmckenna → created an issue.

FYI I've tested it now using code from the example hook implementation in the API docs, and it's working rather well for me, especially when used with 💬 Recommendation for converting alignments added via "style" attribute Active .

A WIP and untested ;-) change to add hook_media_wysiwyg_filter_alter().

damienmckenna → created an issue.

I worked out how to do this in the module, so here's a merge request that checks for float:left, float:center or float:right in the "style" attribute on the source object. And it works great in my local testing :-)

damienmckenna → created an issue.

@steva1982: No problem. This has been a weird situation for sure - there was no grand announcement that they were getting rid of half of their meta tags, the change had existed for a few years before I came across it, so I do sympathize with your confusion. Thank you for raising the question, I'm sorry it took me a bit to remember the root issue, but I'm glad I could help. Take care.

Thanks for mentioning that issue.

Disclaimer: I'm using the address field via a Webform element, so I'm not discounting the possibility that there's a problem with Webform.

Related issue: https://github.com/commerceguys/addressing/issues/227

damienmckenna → created an issue.

Ah. It was removed: 📌 Remove deprecated Twitter Card plugins (D9) Fixed

This is the list of available Twitter/X Card tags: https://developer.x.com/en/docs/x-for-websites/cards/overview/markup

Giving folks here credit for working on this.

Committed. Thank you.

damienmckenna → changed the visibility of the branch 3484792-page-manager to active.

damienmckenna → changed the visibility of the branch 3484792-page-manager to hidden.

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

This would happen because some of the logic uses empty() to check if the value is set, rather than checking to see if it's blank. So, if you look around for uses of empty() you'll probably find the source of the problem.

This would be a feature request.

Committed. Thank you.

Doing a little debugging on this, the problem is that the after maintenance mode is set and the render cache is invalidated, loading the user/1 page again results in the "Access denied" message instead of the "Site under maintenance" message.

So for some reason the output cache was not invalidated as expected.

The same code needs to be turned into a test.

Yes, let's do that.

The change needs to accommodate "empty" values that are not blank, i.e. the number zero.

Committed.

damienmckenna → created an issue.

Committed.

Committed. Thank you all.

Won't this remove valid strings which fail empty(), like the number zero?

I think this should be changed to loop over each element of the array and run the old check.

damienmckenna → changed the visibility of the branch 3396529-no-main-property to hidden.

Did you enable the Metatag Twitter Cards submodule?

Moving this to the 2.1.x branch.

Maybe there's a way of inheriting this from the parent class?

Committed. Thank you.

Committed. Thank you.

Some of the tests are failing against the 11.2.x branch, so I opened a separate issue to fix them: 🐛 Entity field tests are failing with 11.2 Active

damienmckenna → created an issue.

Committed. Thank you.

Never mind, it already does.

Doing a little tidying on the code to match the coding standards.

I suspect there's a tag group plugin in your codebase somewhere that can't be loaded, maybe because it comes from a Metatag or Schema Metatag submodule that has been disabled despite being defined in configuration.

I think we need a log message to track the fact that $group_name wasn't loadable.

Thank you Claudiu!

IMHO a major part of this is the CSS that goes with the image, so in the examples in #23 there might be CSS that also affect how the image is being displayed.

BTW it's not technically possible to set the image's width and height attributes to the specific image variation the browser will use as the HTML tag is generated at the server, and the server doesn't know what the browser is going to do with it.

I wanted to know what the recommended solution was for the "width" and "height" attributes when using responsive images.

I couldn't find any recommendations on Mozilla's dev article on the topic or their <img> docs page.

I did find this article:

• https://chipcullen.com/what-width-and-height-attributes-to-use-with-resp...

The article says "Set width and height to the resolution that corresponds to your default src." That suggests that Drupal core's handling of these attributes is correct and that we should close this as "won't fix".

This is a duplicate of 📌 Fix phpcs issues reported in gitlab Active .

It might make sense to extend dom_str_replace..

damienmckenna → created an issue.

Could you please clarify what the HTML looks like before and after this change? I think that would help everyone understand what is happening. Thank you.

Oh bother! Thank you for spotting that and for providing a fix.

I guess we don't have much test coverage for that submodule, which is why the tests didn't flag it.

This will be included in the next 2.1.x release.

@bbrala: I think you linked to the wrong issue there :)

damienmckenna → created an issue.

damienmckenna → created an issue.

damienmckenna → created an issue.

damienmckenna → created an issue.

Is this the correct approach or are there other considerations or appraoches to fixing this that I didn't take into account?

This is the code I'm prototyping:

if ($this->moduleHandler->moduleExists('tvi')) {
  if (str_starts_with($display->getBaseId(), 'views_')) {
    $term = \Drupal::routeMatch()->getParameter('taxonomy_term');
    if ($term instanceof TermInterface) {
      $tvi = \Drupal::service('tvi.tvi_manager');
      $term_view = $tvi->getTaxonomyTermViewAndDisplayId($term);
      if (!empty($term_view) && isset($term_view['view_id'], $term_view['display_id'])) {
        $display_plugin_definition = $display->getPluginDefinition();
        if (isset($display_plugin_definition['view_id'], $display_plugin_definition['view_display'])) {
          if ($term_view['view_id'] == $display_plugin_definition['view_id'] && $term_view['display_id'] == $display_plugin_definition['view_display']) {
            return TRUE;
          }
        }
      }
    }
  }
}

It feels a bit unclean, besides the \Drupal::service() usage. Is there a better way?

A prototype that checks if the current path is managed using TVI, then compares the current facet's Search API display against TVI's display.

damienmckenna → created an issue.

I think SearchApiDisplay::isRenderedInCurrentRequest() needs to be extended to check if the configured view is displayed on the current page.

I'm running into a similar issue where I'm using the "page" display via TVI and the facets aren't being displayed though the block plugin is supposed to show.

damienmckenna → created an issue.

The problem appears to be this:

class ViewfieldFormatterDefault extends FormatterBase {
..
  public function viewElements(FieldItemListInterface $items, $langcode) {
..
        if (!empty($view->result) || $always_build_output) {

This doesn't have any logic to check if the exposed form is supposed to be displayed.

It works if I select the "Always build output" option..

damienmckenna → created an issue.

For consideration:

diff --git a/core/lib/Drupal/Core/Url.php b/core/lib/Drupal/Core/Url.php
index d16ef550651..b3a8e0e0d41 100644
--- a/core/lib/Drupal/Core/Url.php
+++ b/core/lib/Drupal/Core/Url.php
@@ -276,6 +276,11 @@ public static function fromUserInput($user_input, $options = []) {
    * @see \Drupal\Core\Url::fromUserInput()
    */
   public static function fromUri($uri, $options = []) {
+    // Special handling for <nolink>.
+    if ($uri == '<nolink>') {
+      return Url::fromRoute('<nolink>');
+    }
+
     // parse_url() incorrectly parses base:number/... as hostname:port/...
     // and not the scheme. Prevent that by prefixing the path with a slash.
     if (preg_match('/^base:\d/', $uri)) {

damienmckenna → created an issue.

Thank you for reporting the bug and providing a merge request, hopefully some folk will be able to test this and work towards committing a fix.

As a reminder, please set the "Assigned" field to "Unassigned" after you're finished with your work - attribution/credit for issues is tracked separately. Thank you.

This breaks the taxonomy hierarchy display.

A structure like this:

- Term 1 (weight 0)
  - Term 1.1 (weight 0)
    - Term 1.1.1 (weight 0)
  - Term 1.2 (weight 1)
- Term 2 (weight 1)
- Term 3 (weight 2)
  - Term 3.1 (weight 0)

This turns into the following:

- Term 1 (weight 0)
- Term 1.1 (weight 0)
- Term 1.1.1 (weight 0)
- Term 3.1 (weight 0)
- Term 2 (weight 1)
- Term 1.2 (weight 1)
- Term 3 (weight 2)

(or worse)

damienmckenna → created an issue.

In patch format.

FWIW wrapping the code in a try-catch block works around the issue, e.g:

    try {
      $installed_version = InstalledVersions::getPrettyVersion('drupal/search_api_solr');
    }
    catch (\Exception $e) {
      return self::SEARCH_API_SOLR_MIN_SCHEMA_VERSION;
    }

damienmckenna → created an issue.

There's an existing issue to fix this problem: 🐛 "Drupal\migrate_tools\Commands\MigrateToolsCommands" not found PathRedirectImportCommands Postponed: needs info