Support Metatag 2.0 json storage

Created on 23 August 2023, over 1 year ago
Updated 8 November 2023, about 1 year ago

Problem/Motivation

Some of my content throws an error on unserialize() when I try to export.

It looks like Metatag 2.0 switches data storage to JSON: https://www.drupal.org/node/3325825 β†’

Steps to reproduce

Click on export tab or run drush command on migrated content into metatag 2.0.

Errors:
TypeError: Drupal\single_content_sync\Plugin\SingleContentSyncFieldProcessor\Metatag::exportFieldValue(): Return value must be of type array, bool returned in Drupal\single_content_sync\Plugin\SingleContentSyncFieldProcessor\Metatag->exportFieldValue() (line 28 of /app/web/modules/contrib/single_content_sync/src/Plugin/SingleContentSyncFieldProcessor/Metatag.php)

Notice: unserialize(): Error at offset 0 of 261 bytes in Drupal\single_content_sync\Plugin\SingleContentSyncFieldProcessor\Metatag->exportFieldValue() (line 27 of /app/web/modules/contrib/single_content_sync/src/Plugin/SingleContentSyncFieldProcessor/Metatag.php) #0 /app/web/core/includes/bootstrap.inc(164): _drupal_error_handler_real(8, 'unserialize(): ...', '/app/web/module...', 27)

Proposed resolution

Switch to \Drupal\Component\Serialization\Json::decode()

πŸ’¬ Support request
Status

Fixed

Version

1.4

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States mortona2k Seattle

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @mortona2k
  • πŸ‡ΊπŸ‡ΈUnited States mortona2k Seattle

    I can see a Metatag field handler in 1.4, but not 2.x. Is that still in progress?

  • @mortona2k opened merge request.
  • πŸ‡ΊπŸ‡¦Ukraine nginex

    2.x is outdated and does not contain all the changes from 1.4.x.

    2.x will be updated and released when all the todos are finished for 1.4.x

    Makes sense to fix it in 1.4.x, and then backport patch to 1.3.x

  • Status changed to Needs review over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States mortona2k Seattle

    Got this working, thanks for your support!

  • First commit to issue fork.
  • Status changed to Needs work about 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine abramm Lutsk

    There are a few comments in the MR, moving to Needs work.

  • Assigned to abramm
  • Status changed to Active about 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine abramm Lutsk
  • Assigned to nginex
  • Status changed to Needs review about 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine abramm Lutsk

    The comments are actually handled already, it's just GitLab not showing them as not resolved since there was no maintainer's response.
    Moving it back to review for @nginex.

  • Issue was unassigned.
  • Status changed to Fixed about 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States bdanin

    When will a new release be created that incorporates this fix? I have run the dev-1.4.x version of the module and it works, so it would be really nice to have an official release and not run the dev version in production.

  • πŸ‡ΊπŸ‡¦Ukraine abramm Lutsk

    There's nothing special in dev vs tagged release, 1.4.x is not unstable version or something; there's no tagged release with this feature yet as we don't feel there are enough remarkable changes to create a new one and urge people to make fairly unnecessary upgrade.

    I'd suggest just keeping a dev version or, if your company or project policy forbids it, applying a patch from MR on top of latest tagged release.

  • πŸ‡ΊπŸ‡ΈUnited States bdanin

    The 1.4.3 version simply does not work for me in my Drupal 10 site. The dev version does. I don't understand how a module not working vs. actually working isn't a big enough change to warrant a new release.

    To me, this represents a very remarkable change and it would be great if there was a new version. It will likely help others not have to track down this issue and then apply patches or change to a dev version of the module as well.

  • Status changed to Fixed about 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine nginex

    This is now available in the latest release 1.4.4

Production build 0.71.5 2024