HTML imported into Drupal fields don't set formatting property

@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' => 'full_html',
];
$entity->set('body', $sfBody);

https://www.drupal.org/project/salesforce/issues/3197605#comment-14936316 🐛 HTML imported into Drupal fields don't set formatting property Needs work 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 but I'm not able to find the file salesforce_mapping.salesforce_mapping.mapping_id.yml (or anything similar, recently created). Would you be able to point me on the right direction?

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 last submitted patch, 14: salesforce-drupal_constant-3197605-14.patch, failed testing. View results →

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 📌 Fix eslint, phpcs, and phpstan tests Fixed . It's giving me a big fat WSOD.

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