HTML imported into Drupal fields don't set formatting property

I'm using Salesforce module 5.0.0 on Drupal core 9.3.9 and this problem still exists. I still see the html tags displayed in the web browser after the text is being pulled from the rich text field in the Salesforce to "Text (formatted, long)" field in Drupal. Only after you save the node manually the html tags are being interpreted instead of being displayed in the web browser.
Are there are any plans to fix this?

Formatted text fields have 2 important properties: the "value" property is the text itself, and the "format" property specifies which format to use.
If you want HTML within the field to be rendered, you'll need to set both properties - either in the mapping, or in your custom code layer.

@AaronBauman thank you for clarification.
I do see that Drupal Salesforce module provides 3 options for the "Text (formatted, long)" field in mapping interface:
- Text
- Text format
- Processed text
Since I'm not sure how to set the html property in custom code layer I was hoping to do this in mapping, but unfortunately the Salesforce doesn't seem to provide (at least I couldn't find) the rich text format property that can be mapped to the "Text format".

We solved the problem by adding the field to the Salesforce that has a single constant value - full_html
After that we mapped the "My Field: Text format" to this field.

@gintass - seems like a workaround type solution.

For the "Drupal Constant" is there no way to target the properties? Seems like you should be able to set a constant there.

@pingevt, I was able to resolve the issue by using Drupal Constant. Sharing the snippet from my existing salesforce_mapping.salesforce_mapping.mapping_id.yml

  -
    drupal_field_type: properties
    drupal_field_value: body.value
    direction: sf_drupal
    salesforce_field: Body__c
    id: 7
    description: ''

  -
    drupal_field_type: DrupalConstant
    drupal_field_value: body.format
    direction: sf_drupal
    id: 8
    drupal_constant: basic_html

By default, the module gave me drupal_field_value: body, which I updated to drupal_field_value: body.format and it worked as expected.

@Rishi Kulshreshtha

Sounds great! Just confirming you manually did that in the config file and not through the admin UI?

@pingevt, that's correct. Another approach someone can do is via code as mentioned by @AaronBauman earlier.

Something like this, by subscribing to the salesforce.pull_presave EventSubscriber & then the following should help:

$entity = $event->getEntity();
$sfBody = $event->getMappedObject()->getSalesforceRecord()->field('Body__c');
$sfBody = [
  'value' => $sfBody,
  'format' => 'basic_html', // or any valid ckeditor format.
];
$entity->set('body', $sfBody);

https://www.drupal.org/project/salesforce/issues/3197605#comment-14936309 doesn't seem to work for me when editing the config yml. When I try the Admin UI, I'm currently seeing an `My Field: Text format` when using a Properties field mapping, but this Text format option is not available for Drupal Constant field mapping.

@Rishi Kulshreshtha, I have created a Salesforce mapping (on Structure > Salesforce > Salesforce Mappings) and I'm able to do the synce although I'm facing the issue reported here. I searched for the file salesforce_mapping.salesforce_mapping.mapping_id.yml (or anything similar, recently created) but I'm not able to find it. Would you be able to point me on the right direction?

I'm on Drupal version 9.5.9 and the Salesforce Mapping module, version 5.0.2

Thank you in advance!

After some research, I found a solution by updating the database.

Each of the Text format mapped fields has a table on the DB, for example:

node__field_sf_implementation

and that table had a column for the format called field_sf_implementation_format that was set to NULL. By running the below sql command, I updated it so it rendered to my needs (I used full_html, but also tested with basic_html; do also note I had to clear the drupal cache for the site to render the articles with the new format).

UPDATE node__field_sf_implementation SET field_sf_implementation_format = "full_html";

First, thanks for the great module!

I have run into this specific issue with text format. I also recently ran into a situation where I always want to set the author to a specific user. As #7 points out, the ability to target properties with Drupal Constant would solve both of these cases elegantly.

So here's a patch that does that. The pullValue method is almost completely copy/paste from the PropertiesBase class. It's just the second line that is different. I'm interested in opening an issue to make the pullValue logic a bit easier to extend. (For example, I have a custom plugin that uses migrate process plugins to massage the salesforce data similarly changes that one line.)

But for now, I thought keeping all the changes contained within Drupal Constant would make this easier to review and use and commit.

The failure there resulted form my validating the constant.

https://dispatcher.drupalci.org/job/drupal8_contrib_patches/176411/artif...

Error message
Constant value is required.

I guess it wasn't required before. I'm not going to update the patch at the moment. I think I prefer requiring it honestly.

"Drupal Constant" maps a hardcoded string value to be pulled into a Drupal field.

"Constant" maps a hardcoded string value to be pushed into a Salesforce field.

Hope this helps.

Hi @AaronBauman!

"Drupal Constant" maps a hardcoded string value to be pulled into a Drupal field.

Right, and the patch in #14 allows pulling into a Drupal field property (like a formatted text field's format property). Oh, and entity reference fields like author, which are currently not supported by Drupal Constant.

Is that a feature that you would be interested in including? It's very useful for my project and I think it would be generally useful to the community. I'd be happy to make changes based on your feedback.

Thanks again for the excellent module. Cheers!

Oh, I see, thanks for explaining.
Yes, sounds like a good feature.

I'll take a closer look.

The method \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\DrupalConstant::pullValue is nearly identical to the parent \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\PropertiesBase::pullValue

Would be much better to adjust this so we can inherit, rather than re-implement. May require changing \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\PropertiesBase::pullValue

For example, in \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\PropertiesBase:

  public function pullValue(SObject $sf_object, EntityInterface $entity, SalesforceMappingInterface $mapping) {
    $field_selector = $this->config('drupal_field_value');
    $pullValue = parent::pullValue($sf_object, $entity, $mapping);
    ...

could become

  protected function getPullValue($sf_object, $entity, $mapping) {
    return parent::pullValue($sf_object, $entity, $mapping);
  }
  public function pullValue(SObject $sf_object, EntityInterface $entity, SalesforceMappingInterface $mapping) {
    $field_selector = $this->config('drupal_field_value');
    $pullValue = $this->getPullValue($sf_object, $entity, $mapping);
    ...

Then in \Drupal\salesforce_mapping\Plugin\SalesforceMappingField\DrupalConstant, instead of re-implementing pullValue, all we have to do is:

  protected function getPullValue($sf_object, $entity, $mapping) {
    return $this->config('drupal_constant');
  }

Also, not sure what test coverage looks like for this right now, but i would want to see extended test coverage for this before committing.

Thanks for the thorough review, @AaronBauman

I agree with all of your points, having had very similar thoughts myself. I've been pretty tied up lately, but I'm hoping I can pick this back up in January and get to the refactoring and test coverage.

Cheers!

The patch in #14 needs a reroll because PropertiesBase::dataParser() was removed in #3400903: Fix eslint, phpcs, and phpstan tests. It's giving me a big fat WSOD.

I tried to improve the patch based on Aaron's feedback.