@gaddman

Thanks @smustgrave, appreciate the help. Agree it's some sort of caching issue but it wasn't clear what exactly, since it wasn't resolved by a drush cr. Or any of the following which I've been trying in a mix of different orders:

• truncating the cache_discovery table
• reinstalling modules
• composer reinstalling everything
• re-running the tour update hook
• restore from backup

In the end going back to an old backup and making sure to do a server restart at key steps got it working. Similar symptoms to the issues described at https://www.drupal.org/project/drupal/issues/3440918 🐛 The "" plugin does not exist Active , which suggest updating some other module or vendor dependency could have triggered it. And that's something I'd done in my local environment prior to attempting the Tour install. Anyway, it's not a conflict with the Search API Block module and doesn't seem to be specific to this Tour module, so closing this.

Thanks for this! I've tested in a local/development instance with content that contains an embedded view (via the Advanced Insert View module → ) and it works as described - fails to index immediately but is indexed on the next cron run.
I'm not sure if you were intending to change the error logging, but personally I'd like to see it lowered to a notice or warning - as it is I'd likely keep the Index items immediately option disabled since it's more important for me that it's easy to scan for errors in the logs than it is to have content indexed quickly.

This has been superseded by https://www.drupal.org/project/node_export/issues/3330589 📌 Change readme.txt to readme.md and update content RTBC .

gaddman → created an issue.

Since the core issue has since been fixed is this effectively tracked under #2981091 → or could it be re-opened? I'd love to be able to index a view page directly, rather than the current workaround of creating a view block and inserting that into a page via the Advanced Insert View → module.

Thanks @raveen_thakur51, that works — warning gone from logs and the VBO export still succeeds with all the expected data. However I see now the ViewsBulkOperationsActionInterface class's executeMultiple function should return an array but the VBO export plugin doesn't, so perhaps I need to raise an issue against that project. Although I can't see any recent change in that code.
Perhaps one of the maintainers can comment on whether it's worth supporting those plugins which don't return anything.

gaddman → created an issue.

I think this issue in part stems from the default matches being misleading. Looking at the examples you'd assume the match is anchored to the start through to the end of the string. But it's using preg_match so, for example /.*\.aspx/ is the same as /\.aspx/.
I'd suggest one of the following approaches for clarity:

1. Adding starting ^ and ending $ markers to each of the default matches, where appropriate. For example:
   /\.aspx$/
/^\/wp-admin/
2. Wrapping each entry with ^ and $ in the code.

I don't think that's the behaviour I'm seeing? I put a breakpoint on the throw line here:

        if (filter_var(\ini_get('session.use_cookies'), \FILTER_VALIDATE_BOOL) && headers_sent($file, $line)) {
            throw new \RuntimeException(sprintf('Failed to start the session because headers have already been sent by "%s" at line %d.', $file, $line));
        }

When set to index immediately execution pauses on that line after saving the node. When indexing on cron I don't hit that line after saving or running cron. Don't think it's relevant, but I'm using the Ultimate Cron → module.

I use the Advanced Insert View module → and for any nodes which have a view inserted they fail with this issue when indexed immediately. If indexed on cron no error and they're indexed successfully.

Hi @ekes, I found the code failed if a UID didn't have a valid user (eg if the user was deleted). Also tried to make it more efficient by only processing users who have a Moodle ID. See https://git.drupalcode.org/issue/moodle_rest-3322144/-/commit/737fe3b497....

gaddman → made their first commit to this issue’s fork.

I think this is referring to the tooltip inheriting the formatting of the text in which the taxonomy term is present. For example if the node text is bold (ie formatted as <strong>) and contains the term my term:
A sentence with my term in it.

then the tooltip text for 'my term' will be bold as well. Likewise for h2 and other heading levels.

For the <strong> example I added some CSS resets (also resets some other styles):

.tx-tooltip .tx-tooltip-text {
  font-style: normal;
  font-weight: normal;
  letter-spacing: normal;
  line-break: auto;
  text-decoration: none;
  text-shadow: none;
  text-transform: none;
  white-space: normal;
  word-break: normal;
  word-spacing: normal;
  word-wrap: normal;
}

Add info on the user course list and required webservice permissions.

I'd love to see this actively maintained. @jsutta, it looks like if the project owner (@netw3rker) approves it you could take over (from How to become project owner, maintainer, or co-maintainer → ):

When the project is covered by Drupal's security advisory policy, you need to have permission to opt into security advisory coverage, or the offer must be approved by the project's owner.

He doesn't seem to be recently active here, but I could try contacting him through another channel if you like?

A workaround is to uninstall the Devel Generate module (so long as that's not going to impact other functions of your site).

Tested MR#429 and resolves the issue OK for me. I haven't deployed this into a production site, this is just a few basic tests using the email handler (since I didn't experience any problem without this).

I had much the same question - if the parameters were stored in config then they could be overridden and, using the key module, secrets stored in a vault. What's the rationale to stick with state?
thanks.

@larowlan - steps to reproduce using Bootstrap theme are described in 🐛 PHP error when form has entity reference in Drupal 10.2.0 RTBC , reproduced here:

1. Drupal 10.2.0 standard install profile with bootstrap 3.29.
2. Ensure bootstrap theme active for creating content - either login as a non-admin user or disable Use the administration theme when editing or creating content at /admin/appearance.
3. Edit the article structure to add a new field:
1. Label = Users
2. Field type = Reference
3. Reference type = User
4. Rest as default
4. Add article content (/node/add/article) - page loads OK.
5. Go back to the Users field settings and set the Allowed number of values to a value > 1 or Unlimited.
6. Add article content (/node/add/article) - page fails to load and PHP error is observed in log.

To @aduthois' point - is this considered a core issue or should the fix be in Bootstrap?

See also core issues:

• Confirmed related: 🐛 header array empty in theme.inc TypeError: strlen(): Argument must be of type string, array given in Unicode.php Needs review
• Possibly related: 🐛 Link Active

Are you using the Bootstrap theme? May be a duplicate of 🐛 PHP error when form has entity reference in Drupal 10.2.0 RTBC .

Are you using Bootsrap theme? May be a duplicate of 🐛 PHP error when form has entity reference in Drupal 10.2.0 RTBC .

Looks like a duplicate of 🐛 PHP error when form has entity reference in Drupal 10.2.0 RTBC , closing.

I misread @easp's comment #10 so just realising now that @sakthi_dev's MR32 in comment #7 hasn't been tested. It's a simpler fix than my proposal (@easp's patch #12) so would be good to see if there's any downside of that approach. Fixes the issue for me and hasn't broken anything obvious I can see.

@easp what if you edit as per my comment #5 (retaining the original else condition)?

Just confirming that on Drupal 10.1.7 this issue isn't present.

Yeah, that works, I just wasn't sure if that's the right solution since the Claro theme doesn't do that. As an example, editing web/themes/contrib/bootstrap/src/Plugin/Preprocess/FieldMultipleValueForm.php also avoids the problem:

          if (is_array($header_row) && isset($header_row['data'])) {
            $header_row['data'] = is_array($header_row['data']) ? ($prefixes + $header_row['data']) : ($prefixes + ['#markup' => $header_row['data']]);
+         } elseif (empty($header_row)) {
+           $header_row = ['data' => $prefixes];
          } else {
            $header_row = ['data' => $prefixes + ['#markup' => $header_row]];
          }

gaddman → created an issue.

I tried to hide the message by setting it to [none] but the CKEditor reformats that to

<p>
    [none]
</p>

so instead of hiding the message it just displays the text [none]. Even entering the text in source mode doesn't help (it still gets reformatted on save). Exporting the webform, removing the paragraph tags, and importing it again works, but lost as soon as you edit the submissions setting page.

A vote in favour of adding a preferred or nickname option is the ability to use it with tokens. AFAICT it's not possible to add a Drupal token like [current-user:field_my_name:preferred], while it is possible to use [current-user:field_my_name:given]. Although I do see in https://www.drupal.org/project/name/issues/2775215 → a workaround of hijacking an unused field, eg credentials.

Patch in #17 worked fine for me. Since @patryk-padus also confirmed it worked marking as RTBC.

Awesomely quick patch! Tested and works fine, thanks a heap.

This is a bit of a nitpick+tangent, but your comment here got me thinking:

In case... ...the bigram wouldn't fit into the maximum token length, there is no bigram to add.

The code is checking the length of the prev_word, not the bigram itself. No big deal, but that got me looking into what happens if the bigram itself is too long, and I see it gets truncated further down, eg the text abcdefjhijklmnopqrstuvwxyzabcdefjhijklmnopqrs tuvwxyz is stored as the phrase abcdefjhijklmnopqrstuvwxyzabcdefjhijklmnopqrs tuvw. It's a different scenario and may not cause any problems, but is there any value in storing a truncated bigram or should they just be discarded? I did some brief testing and don't get any results when searching for abcdefjhijklmnopqrstuvwxyzabcdefjhijklmnopqrs tuvw but I do get results for abcdefjhijklmnopqrstuvwxyzabcdefjhijklmnopqrs tuvwxyz, with and without quotes, so I guess it still works somehow?

Issue #3199355 → introduced a fix to strip trailing spaces to avoid these errors but it excludes type=='text'. See /modules/search_api_db/src/DatabaseCompatibility/MySql.php. Not sure why it excludes text?

From what I can tell the indexed entries are almost unique, but the trailing space is causing problems. So there are two entries:
1. 'abcdefjklmnopqrstuvwxyzabcdefjklmnopqrstuvw': the 49-char word
2. 'abcdefjklmnopqrstuvwxyzabcdefjklmnopqrstuvw ': the 49-char word plus a space (it would have been a phrase consisting of the 49-char word plus a space plus the following word but is trimmed to 50 chars).
These are being treated as identical in the MariaDB database:

MariaDB [pantheon]> show full columns from search_api_db_default_text;
+------------+------------------+-----------------+------+-----+---------+-------+---------------------------------+--------------------------------------------------------------------------------------------------+
| Field      | Type             | Collation       | Null | Key | Default | Extra | Privileges                      | Comment                                                                                          |
+------------+------------------+-----------------+------+-----+---------+-------+---------------------------------+--------------------------------------------------------------------------------------------------+
| item_id    | varchar(150)     | utf8_general_ci | NO   | PRI | NULL    |       | select,insert,update,references |                                                                                                  |
| field_name | varchar(191)     | utf8mb4_bin     | NO   | PRI | NULL    |       | select,insert,update,references | The name of the field in which the token appears, or a base-64 encoded sha-256 hash of the field |
| word       | varchar(50)      | utf8mb4_bin     | NO   | PRI | NULL    |       | select,insert,update,references | The text of the indexed token                                                                    |
| score      | int(10) unsigned | NULL            | NO   |     | 0       |       | select,insert,update,references | The score associated with this token                                                             |
+------------+------------------+-----------------+------+-----+---------+-------+---------------------------------+--------------------------------------------------------------------------------------------------+
4 rows in set (0.002 sec)

MariaDB [pantheon]> insert into search_api_db_default_text VALUES('entity:node/213748:en','rendered_item','abcdefjklmnopqrstuvwxyzabcdefjklmnopqrstuvw',1000);                                          Query OK, 1 row affected (0.001 sec)

MariaDB [pantheon]> insert into search_api_db_default_text VALUES('entity:node/213748:en','rendered_item','abcdefjklmnopqrstuvwxyzabcdefjklmnopqrstuvw ',1000);
ERROR 1062 (23000): Duplicate entry 'entity:node/213748:en-rendered_item-abcdefjklmnopqrstuvwxyzab...' for key 'PRIMARY'

MariaDB version: 10.4.17-MariaDB

From my read of the docs on varchar and collation this is expected behaviour with the configured utf8mb4_bin collation.

gaddman → created an issue.

Mmm, good question. If I generalise what tripped me up it'd be the following:

1. Using a custom module with a node presave hook; and
2. That custom module's hook must be run before or after Scheduler's presave hook.

I'm guessing that's not particularly common, so I don't think it'd make sense to change any code for this scenario.

Aside from that, some ideas from a documentation viewpoint that may have helped (I say these with no appreciation for what might be involved and also conscious that many people won't read it):

• A highlight list of the major, and especially breaking, changes upgrading from 1.5 to 2.0.
• Some guidance on choosing 1.5 vs 2.0 (besides core compatibility).
• Renaming this issue to something more related to the cause than the symptom.

Found the problem. Version 1.5 uses a node presave hook and v2.0 uses an entity presave hook. My own node hook was originally getting called after the scheduler hook, and with the change to an entity hook it ended up being called before. That messed up my check for the published state, so changed how I do that and it's all fine now.

Thanks @jonathan1055 for the help!

I've got some other funky stuff going on with form_alter hooks and trying to ensure my node_presave hook runs after the scheduler_presave hook, so I'll dig about with that. Most likely something I've done wrong here.

Thanks Jonathon,
Still doing some debugging but perhaps this will help point in the right direction. To answer your question though, I'm creating the property in that presave hook, literally just copying a field value (defined in the schema) to a node property (not in schema):

$node->my_property = $node->field_myfield->value;

I mentioned a postsave hook earlier but the value has already been lost in the presave hook so I think it's safe to ignore that. Although I've included it just in case it may be relevant. And I may well be getting confused, but it seems as though the value of my node's field has been lost.

In v1.5:
On initial save:

1. scheduler_node_presave: myfield=x
2. mymodule_node_presave: published=false so do nothing (don't copy myfield to node->my_property)
3. mymodule_node_postsave: published=false so do nothing

On scheduled publish:

1. scheduler_cron
2. scheduler_node_presave: myfield=x
3. mymodule_node_presave: published=true so copy myfield to node->my_property
4. mymodule_node_postsave: published=true and node->my_property=x so do some stuff

In v2.0.1:
On initial save:

1. mymodule_node_presave: published=false so do nothing (don't copy myfield to node->my_property)
2. scheduler_entity_presave: myfield has no value!
3. mymodule_node_postsave: published=false so do nothing

On scheduled publish:

1. scheduler_cron: myfield has no value
2. mymodule_node_presave: published=true, myfield empty so nothing to copy to node->my_property
3. scheduler_entity_presave: myfield has no value
4. mymodule_node_postsave: published=true, node->my_property not present so do nothing

Maybe some difference between the entity presave hook and the previous version's node presave hook? Or the order (scheduler module vs my module)?
thanks a heap!
chris

gaddman → created an issue.

A similar problem exists with the MailToFormatter where an invalid email address is present, eg '000' - fromUri throws an InvalidArgumentException resulting in WSOD. Although the UI prevents this, our system ingests data from other systems which hasn't been validated. Is it worth raising a separate issue for that? Or is it worth addressing at all, since really the data should be valid in the first place?

I'm doing something wrong here, putting back to Active.

Created a MR. @dinu-rodnitchi, are you able to test this?

The Form API appears to support validation, see FormBuilder::validateForm. If it's as simple as using that I'm happy to write a MR, but maybe I'm missing something here?

Done some basic testing and all OK:

• log in - using code, try to skip entering code
• set up new code
• trusted browser - with & without, add & remove
• validation attempts - skip, use up

Thanks @Matroskeen! I'm requiring drupal/core-recommended so reinstalled with guzzle6 manually required, ie composer require 'drupal/mailgun:2.0.x-dev@dev' php-http/guzzle6-adapter.
Tested the basic capability I use and all working fine: sending email with inline images and attachments + custom headers (from the reroute_email module).

Patch fixed the issue described in #7 for me, although as described there it still required saving an empty configuration first.

Perhaps this is due to how I installed it, but the 2.0x-dev release fails completely for me. Installing over the top of 1.x appears OK, and removes the guzzle6 adapter:

$ composer require 'drupal/mailgun:2.0.x-dev@dev'
./composer.json has been updated
Running composer update drupal/mailgun
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 1 removal
  - Removing php-http/guzzle6-adapter (v2.0.2)
  - Upgrading drupal/mailgun (dev-1.x 087590a => dev-2.0.x 6732b06)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 1 update, 1 removal
  - Syncing drupal/mailgun (dev-2.0.x 6732b06) into cache
  - Removing php-http/guzzle6-adapter (v2.0.2)
  - Upgrading drupal/mailgun (dev-1.x 087590a => dev-2.0.x 6732b06): Checking out 6732b06857 from cache
<snip>

But then trying to configure via /admin/config/services/mailgun/settings it appears guzzle is still required:

The website encountered an unexpected error. Please try again later.

Http\Discovery\Exception\NotFoundException: No PSR-18 clients found. Make sure to install a package providing "psr/http-client-implementation". Example: "php-http/guzzle6-adapter". in Http\Discovery\Psr18ClientDiscovery::find() (line 27 of /app/vendor/php-http/discovery/src/Psr18ClientDiscovery.php).

Http\Discovery\ClassDiscovery::findOneByType('Psr\Http\Client\ClientInterface') (Line: 25)
Http\Discovery\Psr18ClientDiscovery::find() (Line: 130)
Mailgun\HttpClient\HttpClientConfigurator->getHttpClient() (Line: 82)
Mailgun\HttpClient\HttpClientConfigurator->createConfiguredClient() (Line: 83)
Mailgun\Mailgun->__construct(Object) (Line: 99)
Mailgun\Mailgun::create('myapikey', 'https://api.mailgun.net') (Line: 40)
Drupal\mailgun\MailgunFactory->create()
call_user_func_array(Array, Array) (Line: 255)
Drupal\Component\DependencyInjection\Container->createService(Array, 'mailgun.mailgun_client') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('mailgun.mailgun_client', 1) (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 237)
Drupal\Component\DependencyInjection\Container->createService(Array, 'mailgun.mail_handler') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('mailgun.mail_handler') (Line: 39)
Drupal\mailgun\Form\MailgunAdminSettingsForm::create(Object) (Line: 28)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition('\Drupal\mailgun\Form\MailgunAdminSettingsForm') (Line: 48)
Drupal\Core\Controller\HtmlFormController->getFormObject(Object, '\Drupal\mailgun\Form\MailgunAdminSettingsForm') (Line: 58)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Looking at composer.json I see the comment that guzzle6-adapater is "Required for working with Guzzle 6 e.g. Drupal 9.3.x or earlier", so presumably this should work fine on my 9.5.9 install?

@nicoleannevella - If the Merge Request is confirmed to work (by @bushra-shaikh) isn't that good enough, ie no need for the patch?

On my system the patch failed because the file has additional packaging info lines as described in this blog post and core issue 3036459 🐛 Packaging info from .info.yml often creates conflicts when patching Active , ie these lines:

# Information added by Drupal.org packaging script on 2022-09-29
version: '2.0.1'
project: 'insert_view'
datestamp: 1664469525

So the patch could be fixed to account for that, but the MR does the same thing so accepting that should do the job.

Are you planning a new release to incorporate this fix?

The downside of the first option is that any temporary properties assigned to the entity are lost, eg if someone has done this:

$entity->myproperty = 'my data';

gaddman → created an issue.

I've come across this as well, caused and resolved as per @loze's description. Setting back to NR assuming that's answered @larowlan's questions.

@Graber, The original patch was against the 3.x branch. I've created MR!11 against 4.x, so it takes into account the strip_tags config setting and addresses your concerns.

Yeah, this seems worth renaming as it confused me at first sight. I've renamed it myself through the edit function but the patch does exactly what I'd want.

Hey campbellt_,
No solution unfortunately. I didn't hear of any of our users complaining about it, although the chances of them bothering to tell someone and that feedback reaching me was pretty slim. One thing I noticed just re-testing now - the issue shows on Chrome & Edge but not Firefox.

Closing as duplicate of #3269083 🐛 TypeError: Unsupported operand types: string - int in Drupal\views_ef_fieldset\Plugin\views\display_extender\ViewsEFFieldset->buildOptionsForm() Fixed which has a better merge request.