@dabley

I've just upgraded from groups v1 to v2, and I hit the same problem, which puzzled me for a while. The issue is also discussed in 💬 Sitewide Administrator permissions not working Closed: works as designed , which is closed as "works as designed".

@matslats, what I think you're asking for is an option to choose "Outsider or Insider" as the group option when adding a group role. This would save developers from having to create two separate roles. So, this is a feature request rather than a bug report. I've updated the Category.

dabley → created an issue.

dabley → created an issue.

Hi @johnv, yes, the workflow field (field_state) does appear in the $form array - but this is the value originally shown on the edit form, not the value after the user has made changes.

I have now found the workflow field in the $form_state - but it is not where I'd expected. Instead of
$to_state = $form_state->getValue([<parentfield>, 'field_state', 'to_sid', 0, 'target_id']);
it is in
$to_state = $form_state->getValue(['to_sid', 0, 'target_id']);

So, I can look up the value. But I also want to be able to update the value in my validation routine. However, when I try:
$form_state->setValue(['to_sid', 0, 'target_id'], $new_value);
I find that the value in the entity doesnt actually get updated.

Not only that, but simply trying to change the workflow state using the drop-down on the edit page (rather than my custom code), the field also does not get updated.

This looks like a bug to me.

Hi @johnv, thanks for your quick response, and for confirming that my solution to my first problem is correct. But for my second problem, I dont have a solution. When I call $form_state->getValue([<parentfield>]), I get back an array which includes all the fields on
the form, but excluding field_state, which holds my workflow. In v1.7, field_state was there alongside all the other fields, but with v1.8, it is simply gone.

I looked in workflow.api.php file, but I couldn't see anything that looked relevant.

Where can I find my field_state inside $form_state?

dabley → created an issue.

Ah yes, I see now that the accessCheck has been put in at line 164, whereas patch #4 puts it in at line 158.

It looks to me as if 2.0.0-beta6 does not include patch #4 (access check in buildExistingTermsOptions).

This shows the changes I made on top of https://www.drupal.org/files/issues/2021-07-15/3194699-6.patch →

dabley → created an issue.

This is because Drupal 10.2 isn't compatible with Thunder 7.1. However, Thunder 7.2 is out now, so you can now upgrade to Drupal 10.2.

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

Thanks @sagesolutions, this now works for me (after I'd added "use Mailchimp\Mailchimp;")

#17 works for me. I'm not seeing any duplicates (this might be because I only have a small number of results submissions).

Is this issue obsolete now? Can it be closed?

@shital.mahajan is this issue really active, or are your patches now needing to be reviewed?

I have checked patch #2 and patch #4, and found they both work ok.
The problems which these patches address are also reported (and patched) separately in 🐛 TypeError: Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch(): Argument #1 ($event) must be of type object, string given RTBC and 🐛 SQL access check not implemented RTBC .

The outstanding problem with "Call to deprecated method prophesize() of class PHPUnit\Framework\TestCase" reported by @dineshkumarbollu doesnt appear to impact normal term merging activity (presumably only testing). I propose that this problem is moved to its own, separate issue, where it can be dealt with separately, and not hold up the roll out of patches #2 and #4, which are clearly causing problems for anyone wanting to use this module on D10 (and causing people to waste their time re-inventing patches).

This duplicates patch #3329485-2: Automated Drupal 10 compatibility fixes →

This duplicates patch #3329485-4: Automated Drupal 10 compatibility fixes →

This patch works for me.

Issue ✨ Use checkbox and radio instead of Select, Provide better user experience Needs review makes the selection of terms much easier by putting them in a select list with radio buttons. Can you review that fix and mark it as "Reviewed and tested by the community" if it works for you? (And close this one if your needs are met?)

Issue ✨ Use checkbox and radio instead of Select, Provide better user experience Needs review provides usability improvements, including displaying the term ID to disambiguate terms with the same label. Can you review that fix and mark it as "Reviewed and tested by the community" if it works for you? (And close this one if your needs are met?)

I wrote a patch to achieve this a while back. See #3311345-7: Use checkbox and radio instead of Select, Provide better user experience → . Please review that patch, and mark it as "Reviewed and tested by the community" if it works for you.

Apologies for the earlier confusion. The work I described in #7 was committed in #6. So it now needs to be reviewed.

My changes can be obtained either from the issue fork repo (branch 3311345-use-checkbox-and) , or by applying the patch: https://git.drupalcode.org/project/term_merge/-/merge_requests/7.diff (apply this instead of patch #4, not in addition to it).

This is a duplicate of 🐛 SQL access check not implemented RTBC

This patch works fine for me (with D10.1.5), and appears to be complete. I'm not sure why the status was left at "Active" (rather than "Needs Review"). Presumably just an oversight. I believe this is ready to be released.

I found this helpful. However, for Salesforce 5 (Drupal 10), the syntax is now a bit different - there's no longer a salesforce_get_api() function. The snippet now needs to be:

use \Drupal\salesforce\SelectQuery;

function mymodule_sf_contact_exists($email) {
  $soql = new SelectQuery('Contact');
  $soql->fields = [ 'Id' => 'Id' ];
  $soql->addCondition('Email', "'{$email}'");
  $result = \Drupal::service('salesforce.client')->query($soql);
  return ($result->size() > 0);
}

In my case I wanted to get the SFID of the contact if it existed. In this case, the last line becomes:

  return ($result->size()) ? current($result->records())->id() : NULL;

Have you considered using the salesforce.push_allowed event (previously hook_salesforce_push_entity_allowed)? This allows you to write an event listener with custom code to determine the conditions when a record should or should not be pushed. Or did you find some other solution to your problem?

You can use the Database API to perform an "Update Query" - see https://www.drupal.org/docs/drupal-apis/database-api/update-queries → . This will be fast, but there are two things to beware of:

1. It requires a knowledge of, and is sensitive to the underlying database structure, which might change in future versions of Drupal.

2. The cached data for the relevant table will become out of date, so you'll need to refresh it.

I found that the standard migration procedure does migrate the additional user fields, but they dont get displayed if the langcode is not set correctly - which makes it seem that the fields were not migrated.

I am migrating from D7 to D10.1 using drush. In the migrate_plus.migration.upgrade_d7_user.yml file, I had to change the process definition for langcode to this:

  langcode:
    -
      plugin: user_langcode
      source: language
      fallback_to_site_default: true

This works fine for me on a single-language website. On a multilingual site, you'd need something more complex.

This looks like a duplicate of 🐛 CKEditor 5 resizes images with % width instead of px width (the CKEditor 4 default): breaks image captions *and* is a regression Fixed .

dabley → created an issue.

dabley → created an issue.

I hit the same problem - seems that the documentation hasn't been updated yet.

Also, while you're updating the documentation you might like to add that Thunder 7 isn't compatible with D9, so another prerequisite is that you have to make sure that all of your other modules and themes are D10 compatible before trying to update to Thunder 7.

I've pushed a fix to the issue fork.

dabley → created an issue.

I've updated the issue title to reflect the outstanding problem more accurately.

I found that the upgrade_status module complains that image_slider is using the deprecated core/jquery.once library. This should be replaced by the core/once library (see https://www.drupal.org/node/3158256 → ).

I have made the necessary change and pushed it to the issue fork.

Note: I cant find any usages of once functions in the image_slider code, so perhaps the library isnt actually needed?

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

Hi @DamienMcKenna, the changes I committed were in a different branch (3311345-use-checkbox-and). I suggested that those changes could be merged into the branch for this issue (3280163-ui-improvements). I was waiting to hear from other people whether they thought this would be a good idea or not.
This issue seems to have already made it's way into release 2.0.0-beta4, (while #3311345 has not), so it would probably be better to close 3311345 and mark it as a duplicate of this one.
(I'm still a beginner in terms of Drupal contributions, so I'm not sure of the best way of doing things.)

I am also having problems after upgrading to 3.0.0-rc4. My code calls MailchimpLists->getSegments(), which gives rise to the error:

Call to a member function request() on string in Mailchimp\MailchimpLists->getSegments() (line 595 of /home/xxx/yyy/zzz/vendor/thinkshout/mailchimp-api-php/src/MailchimpLists.php)

MilchimpLists extends MailchimpApiUser, and line 595 is:

return $this->api_class->request('GET', '/lists/{list_id}/segments', $tokens, $parameters);

So, it looks like a problem with $this->api_class.
This might not be the same as the originally reported problem, but I suspect it is related.
Downgrading back to v2.1.3 fixes the problem.

Patch #12 doesnt apply to the latest version of Structure Sync (v2.0.5).
@louis-cuny - you have flagged this as "Needs Work" but it isn't clear what further work needs to be done. Can you clarify?

This issue is a superset of issue ✨ Sort terms and provide a better UI Needs review

I've had a look at this patch (3d38a7d). It works well for me, and it is certainly a welcome improvement.

I have a few comments. Issue ✨ Use checkbox and radio instead of Select, Provide better user experience Needs review (patch 04821ad) includes the same functionality, and a bit more, and also works well. I've compared the two approaches.

#3311345 not only sorts terms alphabetically, and provides check boxes on the page for selecting terms to be merged, it also provides check boxes on the following page for selecting the term to be merged into.

#3311345 also provides hyperlinks to the terms (on both pages), which is handy for checking that you have selected the correct term(s).

These are both worthwhile benefits which this patch doesn't have.

This patch updates the form definition (#empty_option to #description), ensuring that the help text gets displayed. #3311345 doesn't do this, and fails to display the help text.

The help text is not modified by this patch, but I think it should be, because it is misleading. It says "Select two or more terms to merge together". If I am wanting to merge one term into another existing term, then I should only select a single term on this form. The help text should instead say "Select one or more terms to merge". I think that this clarification of the help text can legitimately come within the scope of "provide a better UI".

This patch introduces the use of Drupal\Core\Render\Element\Checkboxes::getCheckedCheckboxes to determine which boxes have been checked. #3311345 appears to function perfectly well without this. I'm wondering why this extra call was introduced? What are the benefits?

In summary, I suggest combining (merging!) this issue with #3311345 to obtain the benefits of both.

@Wim-Leers, thanks for your input on this. My comment about warning about the use of an unsupported style tag was really just an aside, and not the main point of the issue I raised. (It did occur to me that perhaps I should not create confusion by mentioning this.) Your change to the title rather shifts attention away from my main concern.

Thanks for pointing out the related issues. It is sad to see that despite 7 years of effort, there are no solutions, only partially successful workarounds. Nobody seems to have given much consideration to customising the image widget so as to include a styles dropdown. I wonder if that's because it is just too difficult?

@SocialNicheGuru, yes, I could ask for developer access, but my changes would still need to be reviewed. If you try out the revised code, do let us know how you get on.

I like the improved user experience. I have a suggestion to make it a little better - make the text for the link to the taxonomy term the term ID, rather then the term label.

Instead of displaying a term like this:

[ ] Cheese and wine (Cheese and wine)

it display it like this:

[ ] Cheese and wine (7728)

Motivation: The term label is already displayed - there is no benefit to displaying it again as the link text. But it can be helpful in some situations to know the ID of the term. For example, if you have two terms which are identical, or differ only in small ways (such as a having a space at the start). In this case, it can be hard to know which term to choose. Other parts of the Drupal UI typically display a taxonomy term label followed by its ID in parenthesis. This change follows the same style.

I've added a commit to the issue fork with this minor modification.

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

@SocialNicheGuru, yes, it was a lot of work. Rather than a patch file, there's a fork for the chapterthree library and a fork for the module. See comment #4 for instructions on how to use these in your own project.

dabley → created an issue.

@drunken monkey: thanks, that makes things much clearer. So, I see there are 3 basic options when deciding what to do with characters like "-", "." and "_".

1. Ignore them - in which case we are liable to get "overlong word" errors if the text contains strings like "this-is-a-long-file_name.which.is.over-the.50-character-word-length_limit". Shorter strings like "smith-and-jones" will be indexed ok, but as "smithandjones", and so a search for "smith" wont match. A word like "re-introduce" will get indexed as "reintroduce", and will match a search for "re-introduce" or "reintroduce", but not a search for "introduce"

2. Dont ignore them, and treat them as whitespace. In this case, "smith-and-jones" is indexed as 3 separate words, and so a search for "smith" will match. But "re-introduce" will also be treated as separate words, and so a search for "reintroduce" will not match. (A search for "re-introduce" will match, as will a search for "introduce".)

3. Dont ignore them, and dont treat them as whitespace. In this case, "smith-and-jones" is indexed as-is, so, again, a search for "smith" will not match. A search for "reintroduce" wont match "re-introduce".

I see that the list of default whitespace characters is very long, and does include "-._", so by removing these characters from the Tokenizer's "Ignore Characters" option, they will instead be treated as whitespace, as in (2).

@bobpotter, thanks for your work on this. I've had a quick look at the code. Do you think you could summarise what you've done? Did you follow the approach of firfin, or a-fro, or something else?

I'm setting the status to Needs Review, to alert people to the need to check what's been done.

dabley → created an issue.

I got this problem after setting up Search API (v8.x-1.28) on my Drupal 9.5.3 site. I'm using the pre-processors: Ignore Case, Transliteration, HTML Filter, Tokenizer, Stemmer. I'm not using the Ignore Characters processor, but I see that the Tokenizer itself has an "Ignore Characters" parameter. This is set by default to ignore the three characters "._-". I changed this, setting it to empty.

This has pretty much solved the problem for me. I now get a much smaller number of "overlong word" errors, and these are almost entirely from strings of characters which are not words, so dont need to be indexed. So, the solution seems simple.

I am wondering why nobody mentioned the "Ignore characters" parameter in the Tokenizer before? Is this a feature that has been added recently?

It's a shame that the documentation on the processors → doesn't go into detail about how the Tokenizer works. It would be helpful if people could better understand how best to configure it. And what's the rationale behind ignoring the characters "._-"? Are there any downsides to not ignoring these characters?

dabley → created an issue.

Yes, 🐛 403 error if you use VBO in group related views RTBC has a simple patch (to the Groups module) to solve this problem.

#34 works ok for me.