🇬🇧United Kingdom @Finn Lewis

amateescu → credited finn lewis → .

rajeevk → credited finn lewis → .

john cook → credited finn lewis → .

This just happened to me too, Drupal 10.3.5.

I think removing modules and permissions at the same time seemd to prevent config import on production.

Patch in #11 saved my tofu!

Not had a chance to read through the discussion, but it would be good to find a way to avoid this exception preventing deployments where permissions and related modules are all being removed at the same time. Happy to help test further!

Should I set this to RTBC or would you prefer more eyes on it?

Loving the module, thanks people! Super inspired after Drupalcon Barcelona :)

Just tested this and confirm that before this MR config inspector reports an error with the config.

After the MR, config inspector it has no errors:

[Aside: Could do with some AI help to upload images to an issue on Drupal.org and generate alt text! ]

Hi people,

Any movement on using Gitlab issues on Drupal.org yet?

Many thanks,

Finn

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

finn lewis → created an issue.

Any update on a likely stable release soon?

We're having to use the module less and less as it is not covered by security advisories.

Hey folks!

Are the first projects testing the Gitlab issues yet? Might we be able to join the testing for http://drupal.org/project/localgov

Anyone looking into migration of issues from Github yet?

Many thanks,

Finn

Ah yes, see https://www.drupal.org/project/hide_revision_field/issues/3462079#commen... 🐛 Use of $form['actions']['submit']['#validate'] ? Active

It seems perhaps like hide_revision_field overwrites the validation.

I'll close this and follow up there.

Thanks again!

Hi folks,

Thank you and sorry not to respons sooner. I think we traced this down to a conflict with another module.

I will check and report back.

I was wondering the same!

I removed the two references to the profile from the config file core.extension.yml then did a config import.

The profile is gone and no harm done!

Finn Lewis → created an issue.

Finn Lewis → created an issue.

I ran into the same error, just trying to edit my encryption profile.

The patch in #5 fixes it for me.

Might we get a release?

Many thanks!

Finn Lewis → created an issue.

We have the same issue.

Ended up with a 2.2GB purge_queuer_url table. Had to uninstall the module.

Drupal 10.2.4

PHP 8.2.15

purge_queuer_url 8.x-1.0

It would be good to find time to fix this as without it enabling Cloudfront caching is kind of unsustainable.

Any suggestions from the maintainers would be most welcome.

Adding a patch file version of the merge request #12

https://git.drupalcode.org/project/autosave_form/-/merge_requests/12#not...

Ditto @Sam152 and @pacproduct - worked a treat! I owe you a beer!

Very interesting comments.

It sounds like The first Drupal 10 release will be Opigno 3.2.x, with Group 1.x → .

Having worked on upgrades from Group 1.x to 2.x and 3.x, I would much prefer a fresh start with Group 3.x.

Rather than a fork, ideally collaborating with on a Drupal 10, Group 3.x version would be best, with help from the Drupal community. Where does development of opigno_lms happen or is it not public?

Thanks for this @Christian.wiedemann

Any chance of a new tagged release to support PHP 8.2?

Hi AardWolf!

Thanks for the reply.

The link to the commit I included above is where you swapped AcademicPuma to Seboettg

https://git.drupalcode.org/project/bibcite/-/commit/d9976bb3de1d619b1f73...

That was 03 August 2023

The current 2.0.0-beta3 is from 5th July 2023 and includes the AcademicPuma package: https://git.drupalcode.org/project/bibcite/-/blob/2.0.0-beta3/composer.j...

The current 3.0.0-beta3 is also from 5th July 2023 and includes the AcademicPuma package: https://git.drupalcode.org/project/bibcite/-/blob/3.0.0-beta3/composer.j...

It would be great if you can tag new releases with the swap from AcademicPuma to Seboettg.

Many thanks,

Finn

The patch in #9 solved this for me.

I note that in the relase notes here: https://www.drupal.org/project/google_tag/releases/2.0.3 → it states that

Starting March 6, 2024 tags that use certain features from google that require consent mode will not work properly unless the code is set as on by default.

I think this might be why our Google Tag Manager and subsequent Google Analytics stopped working over the last couple of days.

Any chance of a new tagged release with the above patch?

We were seeing exactly the same problem.

Enabling: "Exclude admin pages." and "Don't show the banner for site administrators (including UID 1)." seems to resolve it for us.

Finn Lewis → created an issue.

Any chance of a release to include this?

Hey kristiaan,

Thanks, I did see your reply which was reassuring, thank you! But not here, so must have been an email.

Not sure what's going on with my contact details / emails, so will check and update.

Still testing Ekes's work and the upgrade process for existing LocalGov Drupal Microsites, but it is all going well, so I'll close this issue and report back if we find any real issues.

Thanks for your work on this and encouragement.

All the best

Finn

Thanks for the patch @webflo.

I was also getting the following warnings:

Deprecated function: Creation of dynamic property Drupal\wingsuit_companion\StreamWrapper\WingsuitStreamWrapper::$config is deprecated in Drupal\wingsuit_companion\StreamWrapper\WingsuitStreamWrapper->__construct() (line 46 of modules/contrib/wingsuit_companion/src/StreamWrapper/WingsuitStreamWrapper.php).
Deprecated function: Creation of dynamic property Drupal\wingsuit_companion\StreamWrapper\WingsuitStreamWrapper::$request is deprecated in Drupal\wingsuit_companion\StreamWrapper\WingsuitStreamWrapper->getRequest() (line 110 of modules/contrib/wingsuit_companion/src/StreamWrapper/WingsuitStreamWrapper.php).

I've extended to patch to suppress these, but could do with your review to check I've done it the right way.

The merge request here is against the dev branch, 2.0.x, which makes sense.

We're still using the latest tagged release, which seems to be 2.0.0-beta4.

Here's a patch against oauth2_server 2.0.0-beta4.

Hey people!

The patch in #31 works for me with the suggestion in #33

It looks like the merge request https://git.drupalcode.org/project/bootstrap_styles/-/merge_requests/55/... does the same as the patch, so setting this RTBC as it sounds like a simple solution that is working for a few people.

Any chance of a merge and release?

Many thanks!

Finn

Hey itamair,

any chance of rolling this into a release?

We could use it in LocalGov Drupal.

Many thanks,

Finn

Awesome, thank you @apaderno !

I don't think this was ever committed or released.

Here's the merge request: https://git.drupalcode.org/project/easy_breadcrumb/-/merge_requests/48/d...

It doesn't look like it is on the 2.x branch: https://git.drupalcode.org/project/easy_breadcrumb/-/blob/2.x/src/EasyBr...

And not in the 2.0.5 tag: https://git.drupalcode.org/project/easy_breadcrumb/-/blob/2.0.5/src/Easy...

Finn Lewis → created an issue.

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

I can confirm the behaviour on my local dev environment.

I've created an issue fork and a commit that I can use as a patch for now to test hacking those two lines out of search_api_db.

https://git.drupalcode.org/issue/search_api-3392465/-/commit/de1cc3c5d4a...

I really don't understand what is happening here, but looking back in time, those lines come from the Drupal 7 version of search_api_db 10 years ago, possibly around removing the score?

https://git.drupalcode.org/project/search_api_db/-/blame/7.x-1.x/service...

https://git.drupalcode.org/project/search_api_db/-/blob/7.x-1.0-rc1/serv...

https://git.drupalcode.org/project/search_api_db/-/commit/5aee9c0c63a08c...

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

Thanks @progga

Tested, merged and will tag a release.

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

Yes please, just testing an upgrade on a site that uses current_page_crumb and it breaks badly.

I'll run with the dev release for now, but a 1.5 release would be very much appreciated.

Thanks for all your work on this!

+1 please could we have a release with this fix?

Finn Lewis → created an issue.

I think this can be closed, it looks like the latest release includes the bulk of the patch.

https://git.drupalcode.org/project/civicrm_entity/-/blob/8.x-3.5/civicrm...

I note that the line is not quite the same:

if (isset($civicrm_database_info['default']) && method_exists($query, "getTableQueue")) {

if (isset($civicrm_database_info['default']) && is_object($query) && method_exists($query, 'getTableQueue')) {

The original patch included && is_object($query)

Is the call to is_object($query) redundant?

I've tested this locally and it seems to do the trick.

Thanks @Gertlor !

I've tested this patch with the patch on https://www.drupal.org/project/search_api_solr/issues/3326515#comment-14... 🐛 "can not use FieldCache on multivalued field" error when using boost recent dates processor Fixed and it does resolve our problem.

Is that enough for you to commit and perhaps get a new release @drunken monkey?

The patch in #17 works for me, in combination with the patch for search_api in comment #4 of https://www.drupal.org/project/search_api/issues/3340305#comment-14940876 🐛 Aggregated fields are always declared as multivalued / list causing problems with boosting in search_api_solr Fixed

Thank you @Gertlor !!!

Assuming this approach is sound, what's the best way to get this committed and released @mkalkbrenner ?

That looks great @Gertlor!! I will test.

Thanks drunken monkey!

I've tested this in the installation that was giving us the original problem reported on https://www.drupal.org/project/search_api_solr/issues/3326515 🐛 "can not use FieldCache on multivalued field" error when using boost recent dates processor Fixed

It does not fix the original problem but I can see that Saerch API is no longer declaring the aggregated field as a list, which is nice!

But now in search_api_solr the logic continues on from https://git.drupalcode.org/project/search_api_solr/-/blob/4.2.9/src/Plug...

to https://git.drupalcode.org/project/search_api_solr/-/blob/4.2.9/src/Plug...

where this line still sets the prefix to dm_

$pref .= $this->getPropertyPathCardinality($field->getPropertyPath(), $index_properties) != 1 ? 'm' : 's';

So I need to understand why the getPropertyPathCardinality is not returning 1 for the aggregated field.

So I think the patch looks good but perhaps reveals another part of the problem back in search_api_solr.

I'll follow up with that over on https://www.drupal.org/project/search_api_solr/issues/3326515 🐛 "can not use FieldCache on multivalued field" error when using boost recent dates processor Fixed

Finn Lewis → created an issue.

Hey @jidrone and @fabiansierra5191

We're starting to want to create issues agains the 3.x version, please could we get a 3.x branch that we can put issues against and help to support?

Many thanks,

Finn

Thanks @robcarr

I can replicate this problem. We're working with LocalGov Drupal distribution.

https://www.drupal.org/project/localgov →

Steps to reproduce:

1. Install LocalGov Drupal.
2. Enable LocalGov Full page Alert Banner (this creates fields on entities with long names)
3. Install and enable security_review
4. Run the report at /admin/reports/security-review

Result:

Batch fails and we get this error:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db.localgov_alert_banner__localgov_alert_banner_body' doesn't exist: SELECT `entity_id`, `localgov_alert_banner_body_value` FROM localgov_alert_banner__localgov_alert_banner_body t; Array ( ) in Drupal\security_review\Checks\Field->run() (line 107 of /var/www/html/web/modules/contrib/security_review/src/Checks/Field.php).

Apply the patch from this merge request and the report runs just fine!

I am trying to run update.php on a site running Drupal 9.5.3 and 7.4.3-4ubuntu2.17

It seems that the PHP version warning is preventing me running update.php.

I am seeing this message on a Drupal

Warnings found
PHP
7.4.3-4ubuntu2.17
Your PHP installation is too old. Drupal requires at least PHP 8.0. It is recommended to upgrade to PHP version 8.1.6 or higher for the best ongoing support. See PHP's version support documentation and the Drupal PHP requirements page for more information.

And then below, just

Check the messages and try again.

It doesn't look like there are any other warnings or errors, so it seems this is blocking running update.php.

Thanks @apaderno

I contacted the project maintainers 15 days ago, which I mention in the comment #3 above

https://www.drupal.org/project/domain_group/issues/3325392#comment-14895114 💬 Offering to maintain Domain Group Fixed

If only one person can make the request, probably best to be Ekes.

I will let Ekes update the issue and continue the request.

I assume the title is now in the correct format.

Many thanks!

Finn

Hi drupal.org site moderators!

We're keen to help maintain https://www.drupal.org/project/domain_group →

Following guidelines on https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →

Moving to this issue to https://www.drupal.org/project/issues/projectownership →

Many thanks,

Finn

Finn Lewis → created an issue.

The perfect solution would be to fix that in Search API, for example by providing a dedicated aggregated field for union.

Thanks @mkalkbrenner - started an issue in search_api to explore that: https://www.drupal.org/project/search_api/issues/3340305 🐛 Aggregated fields are always declared as multivalued / list causing problems with boosting in search_api_solr Fixed

Meanwhile, I will take a look at adding a check before to delve into the aggregated field and see if we can check for single value aggregations.

Finn Lewis → created an issue.

It looks like aggregated fields are always declared as a list:

https://git.drupalcode.org/project/search_api/-/blob/8.x-1.28/src/Plugin...

  public function getPropertyDefinitions(DatasourceInterface $datasource = NULL) {
    $properties = [];

    if (!$datasource) {
      $definition = [
        'label' => $this->t('Aggregated field'),
        'description' => $this->t('An aggregation of multiple other fields.'),
        'type' => 'string',
        'processor_id' => $this->getPluginId(),
        // Most aggregation types are single-valued, but "Union" isn't, and we
        // can't know which will be picked, so err on the side of caution here.
        'is_list' => TRUE,
      ];
      $properties['aggregated_field'] = new AggregatedFieldProperty($definition);
    }

    return $properties;
  }

Can we check if the aggregated field is single or multivalued rather than just relying on the is_list property?

What happens if we just remove the check for $field->getDataDefinition()->isList() to fall back to the getPropertyPathCardinality method?
?

              else {
                if ($this->isHierarchicalField($field)) {
                  $pref .= 'm';
                }
                else {
                  try {
                    // Returns the correct list of field definitions including
                    // processor-added properties.
                    $index_properties = $index->getPropertyDefinitions($field->getDatasourceId());
                    $pref .= $this->getPropertyPathCardinality($field->getPropertyPath(), $index_properties) != 1 ? 'm' : 's';
                  }
                  catch (SearchApiException $e) {
                    // Thrown by $field->getDatasource(). As all conditions for
                    // multiple values are not met, it seems to be a single
                    // value field. Note: If the assumption is wrong, Solr will
                    // throw exceptions when indexing this field. In this case
                    // you should add an explicit 'isList' => TRUE to your
                    // property or data definition! Or activate
                    // fallback_multiple in the advanced server settings.
                    $pref .= empty($this->configuration['fallback_multiple']) ? 's' : 'm';
                  }
                }
              }
            }

Thanks for your feedback @mkalkbrenner.

As to the data model, I will let @cbrody comment on that as he is more familiar with the data model and how and why it is how it is.

Even so, the data model did not change but changes in the module between 4.2.8 and 4.2.9 did break things, so I do think it would be good to get the patch committed if possible to maintain the behaviour that we were relying on, even if less than ideal.

I will look at adding a log message with something appropriate.

I've just read through the suggested procedure on https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →

I've just send messages to https://www.drupal.org/u/jidrone → and https://www.drupal.org/u/fabiansierra5191 → with links to these issues and a request to comment.

Hopefully we'll get some movement soon.