These errors cropped up for me on a 10.4.4 multisite install, and none of the solutions provided here is working for me—I'm currently migrating all of the sites to a different server running PHP 8.2.
Based on everything I've tried, and everything I've read here, I agree with posters above who suggested that it's a problem with attribute parsing in certain versions of PHP—the problem is occurring for me using the latest PHP 8.3.17 packages from packages.sury.org (on Debian 12). However, @tolstoydotcom, adding a space or a new line before the “text_default” attribute declaration to separate it from the preceding comment didn't resolve the issue for that plugin, it still shows up in the watchdog table as “does not exist”.
I don't want to overstep, but this problem is:
- breaking production sites
- affecting multiple people
- undiagnosed and unresolved
…I think that qualifies as critical, but I trust that someone with a better understanding will downgrade it if that's not correct.
I was getting this error after upgrading Drupal from 10.4.2 to 11.1.2. The patch at 4 works great to resolve the issue, but I had to make a few minor tweaks to get it to apply:
- The patch has an extra level of prefix in the file paths (they start with “/site_audit/”, so the patch has to be applied with -p2 rather than -p1 and can't be applied via Composer): I removed the extra level.
- The patch line endings are CRLF instead of LF (so I suspect it applies in Windows, but it doesn't elsewhere): I switched to LF.
- The patch file encoding shows up as UTF-16 Little Endian rather than UTF-8: I switched to UTF-8.
So the code in the patch attached here is identical, only some meta stuff in the patch file is different.
I have some charts where I'm setting colors via hook_chart_definition_alter(), and the dataset changing from an object to an array here broke that (resulting in a WSOD with “Error: Attempt to assign property "backgroundColor" on array…”). Fixing it is just a matter of changing, e.g.:
$definition['data']['datasets'][$delta]->backgroundColor = $color;
to:
$definition['data']['datasets'][$delta]['backgroundColor'] = $color;
…but I figured that was worth documenting here in case anyone else runs into this.
This patch was working well for us with Scheduler 2.0.*, but since updating to 2.1.0 we're every cron run failing to complete, and this error appearing in the log:
Error: Class "Drupal\scheduler\Event\SchedulerStorageEvents" not found in constant() (line 177 of /path/to/drupal/web/modules/contrib/scheduler/src/SchedulerManager.php)
I had a look at the changelog for the Scheduler 2.1.0 realease, and I don't see anything obvious:
https://www.drupal.org/project/scheduler/releases/2.1.0 →
For now I've made the problem go away by just removing scheduling from the storage type (I didn't have to uninstall Scheduler). I'll make some time to see what I can do to address this, but if anyone else wants to take a look it looks like the patch being developed for scheduling Paragraphs might point in the right direction:
https://www.drupal.org/project/scheduler/issues/3312200 ✨ Paragraph scheduler plugin Needs work
I've updated the MR to check if $mail['return'] is empty, rather than expecting a specific type, which should make it more flexible and compatible with, e.g. the Mailgun module. Updated patch attached.
We're using Mailgun to send email, and we're seeing the problem both with and without the patch because the Mailgun module returns Mailgun\Model\Message\SendResponse rather than an array or a boolean. I looked for documentation to see if there's a “right” type for $return['result'], but couldn't find anything. I did find that the email_contact module dealt with the same issue just by checking if $return['result'] is empty rather than expecting a specific type:
https://www.drupal.org/project/email_contact/issues/3468210 🐛 Form displays sending error when using Mailgun module even though it sends correctly. Fixed
Would that be a reasonable option here?
I had a need for the functionality requested here, so I took a run at making it work via hook_views_query_alter()—I went this route rather than trying to create a patch because I think there are some UX and other decisions that would need to be made here that are better left to the maintainers (if they decide to pursue this). In the meantime, the following query adjustment is working for me for a range filter called "price", so I'm putting it here in case it's useful to anyone else:
/**
* Implements hook_views_query_alter().
*
* Revise the price range filter to compare range to range, rather than value
* to range.
*/
function MODULE_views_query_alter(ViewExecutable $view, QueryPluginBase $query) {
if (($exposed_input = $view?->getExposedInput())
&& (isset($exposed_input['price']))
&& (!empty($exposed_input['price']))
&& ($filters = $view?->getDisplay()?->getOption('filters'))
&& (isset($filters['field_price_range']['group_info']['group_items']))
&& ($option_data = $filters['field_price_range']['group_info']['group_items'])) {
// The Views filter only provides the floor for each filter range; establish
// ceilings by loading all the floors, sorting by floor (in case they aren't
// in order), then using each floor to establish the ceiling of the previous
// range (if one exists). This won't provide a ceiling for the final range,
// but fortunately in this case the final range doesn't need a ceiling.
uasort($option_data, fn($a, $b) => $a['value'] <=> $b['value']);
$options = [];
foreach ($option_data as $key => $option) {
if (isset($option['value'])) {
$options[$key] = ['floor' => $option['value']];
if (isset($previous_key) && ($previous_key)) {
$options[$previous_key]['ceiling'] = $option['value'];
}
$previous_key = $key;
}
}
if (!empty($options)) {
// Use the existing range condition to determine the group delta and the
// fields, then unset the condition so that it can be replaced with a
// range to range comparison.
foreach ($query?->where as $group_delta => $condition_group) {
$fields = [];
foreach ($condition_group['conditions'] as $delta => $condition) {
if (isset($condition['field']) && ($condition['field'] instanceof Condition)) {
// The condition is an instance of
// “Drupal\Core\Database\Query\Condition”, and I can't figure out
// the “right” way to access it, but casting to array makes the
// elements accessible so that the “to” and “from” field names can
// be extracted.
$condition_field = (array) $condition['field'];
foreach ($condition_field as $field_name => $field_data) {
if (strpos($field_name, 'conditions') !== FALSE) {
if (!isset($fields['from']) && (isset($field_data[0]['field']))) {
$fields['from'] = $field_data[0]['field'];
}
if (!isset($fields['to']) && (isset($field_data[1]['field']))) {
$fields['to'] = $field_data[1]['field'];
}
}
}
unset($query->where[$group_delta]['conditions'][$delta]);
}
}
// If the fields are available, add new conditions to the current group.
if (count($fields) == 2) {
foreach ($exposed_input['price'] as $price_range_index) {
if (isset($options[$price_range_index])) {
$query_snippets = [];
if (isset($options[$price_range_index]['floor'])) {
$query_snippets[] = "{$fields['to']} >= {$options[$price_range_index]['floor']}";
}
if (isset($options[$price_range_index]['ceiling'])) {
$query_snippets[] = "{$fields['from']} < {$options[$price_range_index]['ceiling']}";
}
if (!empty($query_snippets)) {
$query->addWhereExpression($group_delta, implode(' AND ', $query_snippets));
}
}
}
}
}
}
}
}
It looks like changes made to the reCAPTCHA module here have broken this patch:
https://www.drupal.org/node/3408409 →
Now that \GuzzleHttp\ClientInterface is injected, \Drupal\recaptcha\ReCaptcha\RequestMethod\Drupal8Post() expects it to be there. Because the previous patch doesn't provide it, we were seeing a white screen due to “Too few arguments to function Drupal\recaptcha\ReCaptcha\RequestMethod\Drupal8Post::__construct()…”.
Attached is an updated patch that should resolve this issue. I've also updated the version, though it appears that, at least for now, the patch will apply to either 1.x or 2.x.
We're seeing this issue as well—when viewing a node revision, nested paragraphs always show the most recent revision rather than the one associated with the selected node revision. However, if a node is reverted to a previous revision the nested paragraph appears to also be reverted to the correct revision (i.e., not to the latest revision that incorrectly appeared when the revision was viewed).
I've been trying to find a workaround for this, but so far without any luck—I can't figure out how to determine what revision of a nested paragraph is associated with a given node revision. There must be a way to do it, because reverting to a node revision finds and uses the right nested paragraph revision, but I've been unable to determine how that data is stored.
I was still seeing the error with 1.0.11, because although drupal/webfinger was being downloaded (thanks to the dependency added in this issue), the module was not enabled so none of the referenced methods were available. I was able to get the site working again by following @SirClickalot's instructions re: commenting out the service in attribution.services.yml, manually enabling the Webfinger module, and then re-enabling the service.
Unless I've missed something about how this should work, I think the Webfinger module should be listed as a dependency in attribution.info.yml, no? And I think there should be an attribution.install file with a hook to ensure that the Webfinger module is enabled. I'd be up for making these updates, however I'm not even sure that will do it since the error here is preventing database updates from running (so the "enable Webfinger" hook won't run because of the error caused by Webfinger not being enabled)—I'm not sure how to work around that.
In case anyone comes across this and runs into the same issues I had: I think I was getting a class not found error when using S3 from the vendor directory because "Use S3 for private:// files" was checked—that would explain why other people haven't run into the issue, and it seems plausible that Drupal 7 would bootstrap the file paths before /vendor/autoload.php runs. I worked around the issue by adding this just above the "use" statements at the top of S3fsStreamWrapper.inc:
if (!class_exists('Aws\Sdk')) {
require_once DRUPAL_ROOT . '/../vendor/autoload.php';
} I'm not sure this is a smart solution, and this code specifically expects the web root in /web (which isn't common for D7), but I put a patch in a Gist in case it's useful to anyone. Remove the opening "/.." if the web root is the install root.
One additional little thing: I couldn't get the s3fs_sdk_autoloaded variable to stick on a fresh install because the settings aren't saved if the SDK isn't found (and the SDK can't be found until the settings are saved). The variable can be set using Drush, then everything else works:
drush vset s3fs_sdk_autoloaded 1
When I check the "No Composer Manager" checkbox, the site immediately becomes unavailable with the following watchdog error:
Error: Class "Aws\S3\StreamWrapper" not found in include_once() (line 26 of /path/to/module/s3fs/S3fsStreamWrapper.inc).
It seems like, for reasons that I can't figure out, that class is being invoked before /vendor/autoload.php has run. I can eliminate the error by adding this at the top of the file:
if (!class_exists('Aws\Sdk')) include DRUPAL_ROOT . '/../vendor/autoload.php';
I haven't added that to the current patch because it seems like there must be a better way to handle this—what might be causing that to be invoked before everything has been autoloaded?
Just a heads-up for anyone else who's having issues with media references—it appears that the bulk update doesn't work if the widget on the "Manage form display" is "Media library". I switched to "Check boxes/radio buttons", re-ran the bulk update successfully, then switched back to "Media library".
(This module has saved me a ton of time over the past few months—thanks very much for your work on it @b_sharpe.)
Patch attached.
#73 is working for me with Drupal 9.5.9, however I saw something else that I couldn't find addressed anywhere else that I thought was worth adding here in case anyone else encounters the error I did. I moved a site to a new environment with this in the composer.json:
"extra": {
"drupal-scaffold": {
"locations": {
"web-root": "web/"
},
"file-mapping": {
"[web-root]/sites/development.services.yml": "false"
}
}
...and when I did the initial composer update, scaffolding failed with the error:
In ScaffoldFilePath.php line 135:
Scaffold file false not found in package drupal/recommended-project.
I removed the file-mapping and and did composer update, and it completed successfully (including scaffolding). I put file-mapping back and subsequent updates worked as well with no errors. So I think it's just a matter of having to exclude this for an initial install.
What @SirClickALot has suggested is definitely the right path in most cases, but I'm not sure that it is here. I may be misunderstanding Prism.js, but I think there are a couple of issues:
- If you just do
require npm-asset/prismjs, Prism.js is installed in "/vendor" rather than "/web/libraries"—if you're using the composer "Project template for Drupal projects with a relocated document root" the CSS and JS can't be referenced directly, because they're not in "web". - It's probably possible to work around 1 with Composer, but even then what gets downloaded doesn't actually work—there's no CSS file in the root directory, and unless you want only the most basic syntax highlighting (e.g., no PHP) the prism.js file in the web root is incomplete: As far as I can tell, Prism.js expects the CSS and JS to be assembled on a per-use case basis using the form at https://prismjs.com/download.html.
I'm not 100% confident that I'm right, but that appears to be the situation from what I can tell.
FWIW, my solution for automating this was to create and require a custom Prism.js repo called "prism" at GitHub that just contains the generated CSS and JS files and a composer.json that includes "type": "drupal-library".
This issue was resolved for us by the latest patch here:
https://www.drupal.org/project/calendar/issues/3255924 🐛 Multiple multiday events the second event is not showing on the next row. It is showing in the column after first event colspan ends. Needs review
@trolin: I had the same issue, and discovered when I tried to uninstall via Drush that one of my installed themes has Stable as its base_theme—maybe that's why you don't see the uninstall option after unhiding?