Contrib.social

When used with custom filter module, text replacements appear to be saved

Open on Drupal.org →
Created on 16 November 2023, about 1 year ago

Thanks for the excellent module! I think this is a great alternative to paragraphs, particularly in use cases where references to other entities are not ideal.

Problem/Motivation

The Custom filter → module allows site builders to create their own text filters using regex patterns, which can search and replace text in field values. For example, a site builder can define that all instances of 'foo' be replaced with 'bar'.

For most fields, the original text ('foo') is retained in the field value when the node is saved. For text fields that are part of a Custom Field, saving the node causes the replacement text ('bar') to be saved.

Steps to reproduce

  1. Create a custom filter (TestFilter) that searches for 'foo' and replaces with 'bar'
  2. Enable TestFilter in one of the CKEditor profiles
  3. On the Basic page content type, add a new custom field (CustomField) with a "Text (long)" field (CustomTextField).
  4. Enable WYSIWYG on CustomTextField
  5. Create a new Basic page
  6. Type 'foo' in the body field, as well as on CustomTextField
  7. Save node. Both the body and CustomField will correctly display 'bar'
  8. Edit node. The body field will still display 'foo' (expected behavior), while CustomTextField will display 'bar' (unexpected behavior)

Can you kindly give me pointers on what the issue could be?

💬 Support request
Status

Closed: works as designed

Version

2.0

Component

Code

Created by

🇨🇭Switzerland jedsaet

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

Comments & Activities

  • Issue created by @jedsaet
  • Comment about 1 year ago →
    🇺🇸United States apmsooner

    Custom field data types are limited to storing in a single column of the table since multiple data types comprise a table. Normal drupal longtext fields are stored with: value, format, processed but we can only store value so in order to support wysiwyg this was built to save the configured formatted value. It was really designed in this module around the format type being configured once and not have flexibility to dynamically change the format per instance since theres no way to store the format per field value. I'm not sure if theres a better way to handle this but open to suggestions.

  • Status changed to Closed: works as designed about 1 year ago
  • Comment about 1 year ago →
    🇨🇭Switzerland jedsaet

    Yes, that makes absolute sense. Thank you for the explanation! Can't really think of a way to handle this so marking this closed.

  • Comment about 1 year ago →
    🇺🇸United States apmsooner

    Thanks, I did consider enabling it as a formatter but I'm also trying to support decoupled and would have to add a computed property there for the formatted value. Computed properties in single column values are a little bit hacky too. I did this with the uri field type by adding a suffix __url to the field name in jsonapi output to support the aliased value. Ideally it would be served as an object composing both but not sure that drupal's property declarations even support that in this way.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024