Contrib.social

Existing term settings ignored

Open on Drupal.org →
Created on 1 December 2023, about 1 year ago
Updated 4 December 2023, about 1 year ago

Problem/Motivation

Our site had an existing "Media Path" vocabulary with terms set on thousands of media items.

Given the mapping to that vocabulary, the expectation was that this value would be read in by the module.

Instead, there is a 'directory' column on the media record in the media_field_data table that is initially NULL for each item.

Proposed resolution

When the "Vocabulary" is set, copy any existing values* to the 'directory' column for that media item.

*Will need to resolve what to do if multiple terms are assigned to a media item

In the meantime, the following query sets the values:

UPDATE media_field_data
INNER JOIN media__field_media_path
ON media_field_data.mid = media__field_media_path.entity_id
SET media_field_data.directory = media__field_media_path.field_media_path_target_id;

Change media__field_media_path to the correct table for your term reference field

✨ Feature request
Status

Closed: won't fix

Version

2.1

Component

Code

Created by

🇺🇸United States kevinb623

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

Comments & Activities

  • Issue created by @kevinb623
  • Comment about 1 year ago →
    🇨🇭Switzerland ytsurk Switzerland

    Thank you for reporting this issue kevinb623.

    I don't get the exact use case. Did you change the vocabulary? Was this on installation?
    It seems that we are incompatible with the default taxonomy reference field, but using a custom field.

    Unsure if we shall offer a migration path, or change our custom field?

  • Comment about 1 year ago →
    🇪🇪Estonia rang501 Viljandi

    @ytsurk I think the issue is that existing media has an existing reference field (I guess field_media_path) and after enabling the module, these are not used.

    We can't do anything special here. Finding existing term reference fields is error-prone and I think if someone has such a case, they need to migrate the id-s manually. Unless we want to make the field configurable somehow. Fortunately, the migration is quite simple (with hook_update_N or the SQL query mentioned above, unless two or more references are allowed), so I think we don't need to make it configurable.

    As for allowing to assign media to multiple folders - it is possible, but there are UI changes needed (moving files in the browser), and migrating that field to a separate db table needs a migration path.

  • Status changed to Closed: won't fix about 1 year ago
  • Comment about 1 year ago →
    🇨🇭Switzerland ytsurk Switzerland

    I have the same opinion that we keep our dedicated column.

    So, when we decide to offer a migration path, what shall exactly happen?

    We let the user choose the existing field and take it's first value (a media shall only live in one folder), and copy it over.
    At the end of the migration that field should be deleted, as we will not keep it in sync.

    Thinking more about this, I agree that this edge case shall be handled by the user itself.
    Thus closing this issue.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024