@scambler

Seconding #56... The "blue cheese" background hurts my eyes

This patch checks if there is an expected answer, and marks it as RESULT_NOT_APPLICABLE if there isn't one.

scambler → created an issue.

Patch:

scambler → created an issue.

scambler → created an issue.

If you are still experiencing this issue, make sure you remove `show_mail_in_messages: 0` from your system.site.yml, otherwise it will be re-imported and break the form again.

Attached is the proposed patch.
Whilst creating this issue I had the idea of creating a route option '_ignore_path_alias_xt' to give developers an easy way to avoid the aliasing. This is a pretty niche situation, so I will leave it to the maintainers to decide whether it's worth adding that to the default config.

scambler → created an issue.

scambler → created an issue.

scambler → created an issue.

#3 didn't work for me either, but this did: drush ev "\Drupal::service('extension.list.profile')->reset();"

Source: https://drupal.stackexchange.com/questions/314430/moved-an-old-installat...

#41 worked for me, thanks.

I was having the same problem, but found the way to do this without a patch.

class MySalesforceSubscriber implements EventSubscriberInterface {

  public function onSalesforcePullEntityValue(SalesforcePullEntityValueEvent $event) {
    $value = $event->getEntityValue();
    if (is_null($value->getValue())) {
      $value->setValue(42);
    }
  }

  public static function getSubscribedEvents() {
    return [
      SalesforceEvents::PULL_ENTITY_VALUE => ['onSalesforcePullEntityValue'],
    ];
  }
}

You need to use setValue() and you don't need to pass by reference.

This is not clear, an example added to SalesforceExampleSubscriber would be helpful.
Also, should the pass by reference be removed from the __construct in SalesforcePullEntityValueEvent.php? As far as I can tell it does nothing.

scambler → created an issue.

Corrected the patch format (missing the first line) in the previous 2 patches.

Nice! I came across the same issue. I used a similar patch and it solved my problem. The only difference is when checking for an empty line, I copied the logic from L422. I'm not sure if there are situations where this will actually make a difference, but I'll upload it anyway.

scambler → created an issue.

The old commands are out of date for the latest versions of Open Social, based on https://git.drupalcode.org/project/social/-/blob/11.4.x/modules/custom/s...

I have added the Version < 11 etc. lines to clarify the command usage.

D10 also requires Drush 11
I was hoping to use this module on our site, but it is already on PHP8 and Drush 11, so it is not compatible.

The code basically goes like this:

function my_module_node_update($node) {
  // Do some checks...
  // Do some stuff...
  
  drupal_register_shutdown_function('my_module_send_request', $node);
}

function my_module_send_request($node) {
  // Manually build up the page into a render array.
  $builder = Drupal::entityTypeManager()->getViewBuilder('node');
  $node_render_array = $builder->view($node, 'full');
  $build = [
    '#type' => 'html',
      'page' => [
        '#type' => 'page',
        '#title' => $node->label(),
        '#head_title' => [$node->label()],
        'content' => $node_render_array,
     ]
  ];
  
  Drupal::service('renderer')->renderPlain($build);

  return $build;
}

function my_module_preprocess_node(&$variables) {
  $view_id = 'watchdog';
  $display = 'page';
  if ($view = Views::getView($view_id)) {
    $view->setDisplay($display);
    $view->executeDisplay($display);
    $preview = $view->preview();
    $variables['content']['glossary'] = $preview;
    $variables['display'] = $display;
  }
}

The problem occurs in the renderPlain() when inside the preprocess node and executing/previewing the view. I have tried to tweak this so that it can work on a vanilla site, but I haven't tested it myself yet.

Also worth noting that we have another process that is calls my_module_send_request manually and it works fine. Which further points at the shutdown function being the 'problem'.

@cilefen I will create some sample code to help reproduce when I next get some free time

*Correcting file path for patch 2

This next patch is more of a suggestion and not one I will be using on a production site (unless others approve it) as I am not confident of the consequences elsewhere on the site.

I have found the line which is causing the error and have reverted it to what it was on 9.5.3.

scambler → created an issue.

scambler → created an issue.

I was getting this error: Refused to execute script from '...' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

This was on a .js file using the private file system. After applying patch #4, this is now getting the correct mime type and working as expected.

Drupal version: 9.5.3

Thanks @kevin.dutra