🇺🇸United States @ExTexan

@smustgrave, other than overriding the button text, I don't know of any other steps needed to replicate it.

This may shed some light on the issue. It seems to me that the full configuration for shortcuts (stored in the database tables) is not being exported to the config yml files.

The 3 attached screenshots show the three tables prefixed with "shortcut" in the site where shortcuts are working.

And here are the three config yml files exported from that site, and imported into another site (in which no shortcuts appear).

uuid: f2e2a04f-a646-4376-a5f0-78d157102f32
langcode: en
status: true
dependencies: {  }
_core:
  default_config_hash: U5VlGjd_SfV0Qm_EfnaynOfc549cNscFAx48JfYoMRI
id: default
label: Default

uuid: 9fbf3b51-f736-4160-9dbe-900d711b9ff8
langcode: en
status: true
dependencies: {  }
id: staff-shortcuts
label: 'Staff Shortcuts'

uuid: aa9e33ce-90ce-419c-bf91-c8b77f5b122e
langcode: en
status: true
dependencies: {  }
id: content-admin-shortcuts
label: 'Content Admin Shortcuts'

I just don't see how the data in the tables could come from the limited data in the yml files.

Just to weigh in on this issue, our non-search autocompletes were broken. The MR from TomTech fixed them.

I'm not sure what a "Nodequeue relationship" is (from #4), and I'm not using the entity_reference_revisions module (from #5).

Can someone offer some insight on what I need to look for? The view with the issue in my case lists several taxonomies.

I agree with @RobLoach. The condition IS being encountered, so it's better to fix it, even if you can't imagine how it is possible.

In my case, I upgraded a site that was on D8.9, through D9.5, to D10. In doing so, I started with the D8.9 database (cloned from the live site), and ran a massive (1200+ entry) config sync on it. In the D8 site, I was using SwiftMailer, but uninstalled it during the updates of Drupal core, contrib and custom modules, during the move to D10. Somewhere in all that syncing, the configuration for symphony_mailer ended up in such a state as to trigger this error.

So, by performing normal steps to upgrade Drupal and contrib modules, this condition was created. Please tell me how I could have done it differently to avoid the error?

ExTexan → created an issue.

It would be a great time saver if, for the files in the "to review" sections under Option 2, the relative paths could be added. Otherwise, they can be rather difficult to find. You can safely leave off the "/templates" or "/css" parts, because each section is referring only to files in each of those folders.

For example (for "templates"): /field/file-link.html.twig

ExTexan → created an issue.

@FrittenKeeZ,

Thanks for the helpful posts. Seeing your messages here made me realize I had neglected to come back and post the solution we settled on.

I added this line at the top of all twig templates:

{% set params = _context.email.params.legacy_message.params %}

Then in the rest of the template, I changed all occurrences of "message.params.my_field" to "params.my_field".

No other code changes were needed elsewhere in the site.

ExTexan → created an issue.

Point taken. My apologies. My post was written after the aforementioned 20 hours of effort - I shouldn't have let my frustrations creep into my post.

ExTexan → created an issue.

A huge +1 on this. It is desperately needed.

So far, my colleague and I have spent almost 20 hours trying, without success, to get SymfonyMailer working in a Drupal 9.5 site. With limited documentation, and misleading/contradictory/outdated posts from Google searches, to guide us, we've had to resort to trial-and-error, best guesses, and looking through module code - all to no avail.

Please make sure that the documentation shows actual code examples on how to accomplish each of the three "levels" of integration (from this page → ).

Also, may I add... as I said, this is desperately needed, so the first draft doesn't need to be all that pretty; the structure/format can be cleaned up later. I'd be happy for a simple page with somewhat detailed explanations, and the all-important code examples ASAP.

ExTexan → created an issue.

I'm uploading screenshots that provide a better visualization of one of the two issues stated in the OP. The view is currently configured the 2nd way - which appears below the line "If we change the non-exposed filter to this:" in the OP.

In the view, there are two filters on the "status" field, one that's not exposed that restricts the list to statuses "Closed" and "Cancelled" (excludes "Open"). The other filter is exposed and allows the user to filter on just "Closed", or just "Cancelled" or "Any".

Here's the non-exposed filter:

Here's the exposed filter:

The two screenshots below highlight the differences between an unfiltered query diffed to one filtered on "Closed", and the same unfiltered query diffed to the one filtered on "Cancelled". And, again, with this configuration, the unfiltered query works correctly, as does the one filtered on "Closed", while the one filtered on "Cancelled" shows no results. And the reason why is obvious when you look at the screenshots.

Here's the one filtered on "Closed":

Here's the one filtered on "Cancelled". Note the red box around the comment indicating the bug.

In previous posts, I've been asked to provide a simplified setup that reproduces the error. I can't see any way to do that. The system this view is for is very complex, with many tables and fields. But as these latest screenshots illustrate, the bug is in the code that adds the additional LEFT JOIN for the status field/table (called "status2" in the queries). Its "ON" clause seems to be getting the first of the two possible values of status in both cases, when it should be getting the opposite one from what's included in the "WHERE" clause. Hopefully that narrows the search a bit.

To restate the bug, in the query that doesn't work, it's trying to select when status equals "Cancelled" AND when status doesn't equal "Cancelled", which just isn't possible.

My 2 cents... The original issue is from 2009. My coments were 10 years ago. The issue has gone from D8.0 (or whatever version it was originally posted for) through to D9.5 (as I write this). I'd say this should be closed and re-opened (or a new issue created) if someone runs into the issue again.

And, two years later, I'm also getting the same error as in #26:

Notice: Undefined property: stdClass::$content in advanced_forum_get_reply_link() (line 883 of /home/vps1/public_html/mrs/sites/all/modules/advanced_forum/advanced_forum.module).

Seems like it's back to the original issue, as if the patch never fixed anything, though several (including me) reported that it did fix the issue.

Did the $content property get renamed in core (D7.75)?

@smustgrave, your comment about "...not sure of the current fix. Seems to be fixing a symptom vs the cause." prompted me to point out one aspect of my issue summary that may be relevent here.

By adding a challenge question/answer feature to our client's login procedure, we essentially turned the Login form into a multi-step form. When it reloads (with our challenge field added), the password the user originally entered is blank. I'm not sure why, but I'm guessing it's a security measure. In any case, on the subesequent submit, the function in question runs (beyond our control) with a blank/null password.

The point of this is, I don't see that as a invalid condition (a "symptom" as you put it). It seems to be a valid situation that that function needs to check for, and handle, a blank password. The fix seems perfectly reasonable, in that light.

@cilefen, removing "project" did the trick.

Thanks for the quick replies on this. Sorry it took me a while to get back to it. An issue came up with that client that took a few days to get sorted out.

Here's the contents of sunland_access.info.yml:

name: Sunland Access
type: module
description: Handles user access to various features and data in the Sunland site.
package: Sunland
version: 8.x-1.0
core_version_requirement: ^8.8.0 || ^9.0
project: Sunland

I figured it was because of the "No available releases found" message. And I just realized I forgot to put that message in my OP - sorry about that.

Here's a screenshot:

ExTexan → created an issue.

ExTexan → created an issue.

@cirrus3d, sorry for the late reply. I was trying to find time to get back in and apply the patch again so I could answer the question from TwoD (#353). By the time I saw his question, I couldn't remember exactly where/when the error appeared.

But as for your questions:

Views 7.x-3.14
PHP 5.6.10
MySQL 5.5.52
(running in MAMP Pro)

I just applied patch #332 to a D7.51 installation and started getting this error repeatedly...

Recoverable fatal error: Method DatabaseCondition::__toString() must return a string value in SelectQuery->__toString() (line 1565 of /path/to/root/includes/database/select.inc).

.

Line 1565 of that file is...

if (!empty($table['condition'])) {
  $query .= ' ON ' . (string) $table['condition'];    <= Line 1565
}

.

When I reverted the two patched files, the errors stopped.

I know that, early in this thread, it was speculated that this issue might be related to the content access module, but I don't have that module installed. I am, however, using the Domain module (and domain_access).