🇺🇸United States @msypes

@kim.pepper: Are you asking me why we had NULL mimetypes in the database? I don't know. Could be from a less-than-perfect migration, from when we moved from D7. They were generally pretty old records. Did the the API always assume there was a mimetype? If not, why would the db allow it to be NULL? At any rate, the fact that it does allow NULLs should mean that the system can handle them.

No, I did not. I was looking to solve a particular caching issue and tripped over this. I hadn't previously used the module.

msypes → created an issue.

msypes → created an issue.

msypes → created an issue.

msypes → created an issue.

msypes → created an issue.

I have isolated the problem. It is not a defect in this module.

The problem is that I just cannot use this module in the way I would like to, because there is no way to deploy the changes it introduces in a repeatable manner to a higher level environment, at least not with the practices we use.

When the migration takes place, new UUIDs are generated for the replacement/renamed configurations. When I perform the basic procedure on a local environment, everything seems to work just fine, but our workflow has me export the configurations and deploy those to a shared dev environment, then to stage, and finally to prod. That's when things break. I'm guessing here, but I see that the migration generates different UUIDs each time and deploying the configs overwrites them, so there are mismatches that cannot be resolved. Perhaps if the new UUIDs were reproducible/predictable, so that every environment would get the same ones, this wouldn't happen.

At any rate, this module works as described, but just isn't usable by me, and I dare say, by many others, since our workflow is a pretty common one. I'll keep my eyes on this module, in case there's some solution. I do appreciate your work on this, and your prompt attention to the issues I've raised. Thanks.

Apparently I spoke too soon. Something is still not working right as far as roles are concerned. The table isn't truncated, but members' roles aren't showing up on a group's list of members.
I will continue to investigate and report as I find more info.

Sorry. I should have realized this was a false alarm. It does look like something got misconfigured during git operations to bring my test branch up-to-snuff. The output from drush deploy did not report anything unusual in the tests when roles weren't copied. At any rate though, I've been able to rebuild the migration process locally and can try deploying to a shared development environment again.

msypes → created an issue.

Update:
Actually, there is an issue when a field can take multiple paragraph types. Instead of displaying each paragraph type in the drop button, the displays the Title text for all, so there's no way to distinguish among them. See attached images.

I've tested both patches and they both work. Nice job(s), thanks!
Personally, I'm going with #2 at this time. I'm not seeing the advantage of #3, and that version seems to do a little too much. @Meleagyr, perhaps you could explain the use case for #3? Maybe I'm just missing something.

Started over with

1. composer require"drupal/group2to3:3.0.x" Composer reports Installing drupal/group2to3 (dev-3.0.x bc7f887), which includes the change in the commit you recommended
2. drush en group2to3
3. composer require drupal/group:^3.0
4. drush deploy

After completing Step 4 of 8 (Updates the target type of Entity Reference fields): Process finished., I get a new, but similar error: Call to a member function getPluginId() on null , and the backtrace still indicating Views as a source:

• Error: Call to a member function getPluginId() on null in Drupal\group\Entity\Storage\GroupRelationshipStorage->getEntityClass() (line 93 of .../group/src/Entity/Storage/GroupRelationshipStorage.php)
• #0 .../core/lib/Drupal/Core/Entity/EntityFieldManager.php(384): Drupal\group\Entity\Storage\GroupRelationshipStorage>getEntityClass('group_content_t...')
• #1 .../core/lib/Drupal/Core/Entity/EntityFieldManager.php(353): Drupal\Core\Entity\EntityFieldManager->buildBundleFieldDefinitions('group_content', 'group_content_t...', Array)
• #2 .../core/modules/views/views.views.inc(263): Drupal\Core\Entity\EntityFieldManager->getFi
  eldDefinitions('group_content', 'group_content_t...')

I guess not. Composer reported it pulled down dev-3.x d0dd2af

msypes → created an issue.

I was able to create a branch. Supposedly I have push access, but I can't actually push the changes.
Here's a patch file to try out.

msypes → created an issue.

Not sure how much useful info this adds, but I'm experiencing the same thing:

Everything works just fine locally, but in our shared dev and stage environments, an expected status message is not displayed if the user is logged in, but is not an administrator. Administrators get the status message.
Even when the message is not displayed, I can still see the text hidden inside a script tag as a JSON object where the text has been URL-encoded.

Uninstalling the Big Pipe module rescues the display.

Both the local (Mac) and the shared dev/stage (Acquia) are running Drupal 10.2.0 on PHP 8.2. This problem does not seem to be occurring in our production environment which is using Drupal 10.1.7 & PHP 8.1

I came across this problem too, but in my case at least, the 10 results limit was not coming from either Views data export nor Views itself. Rather, it was coming from a (Acquia) Solr Search API setting that set the default return rows when the Search API query itself is not limited, as is the case when a Views display is set to return all results with no pager. This is why setting a high limit works; setting any limit will override the default.

msypes → created an issue.

Tested patch from #120 with core 10.1.5 and redirect 1.9.
With a "From" /foo/bar/* no redirect occurred from either /foo/bar/baz nor /foo/bar/baz/bing. Was hoping for something similar to #119, using a "To" of /foo/bar. Looks like that creates a redirect loop, according to the logs, which isn't surprising, but incompatible with my use case.
I also note however, that editing the "To" to /foo didn't result in any redirects either, which is surprising.
I can't say that this patch works at all.

I cannot figure out how to submit a new branch and merge request to the issue fork I created that has now disappeared from my view, so I'll just submit an old-fashioned patch file

Updating to current version for new patch and issue fork

Note to others out there in Drupal-land:
The patch in #17 is meant for the 2.x-dev@dev branch. It cannot be applied to the 8.x-2.0 release. It does, however, apply cleanly to the dev branch.

Here's a version of the patch in #10 without the changes to the .info.yml file, as mentioned in #12

Figured it out. Presenting here, because our situation is likely non-unique.
We are using Config Split → such that TFA (& GA Login) are/were only enabled in production. As a result, the config changes, particularly those handled by tfa_update_8006 and following were being countermanded by the Config Split settings, which re-enabled GA Login in production. (I wasn't getting any database updates because they had already run in the past.)

Here's how to resolve for anyone who finds themselves in the same Catch-22 situation I described above:

1. Set your dev environment to think it's whatever environment actually has TFA & GA Login enabled. (In my case that meant temporarily changing a line in my settings.php to indicate I was in "prod" and not "local.")
2. In the key_value table of the database, there's an item with the name "tfa" and a value indicating the last hook_deploy_N that's been run. Change it to 8005, so that the next database update will re-run everything with a higher number
3. Run drush updb or drush deploy
4. Login. You should still need whatever TFA code you normally do. Verify that GA Login is disabled, and that TFA settings make sense, in that you should now see the use of the core plugin(s) instead of the GA one(s).
5. Remove GA Login from the config split settings so it doesn't get re-enabled again
6. You should now be able, as @jcnventura describes, to tell composer to remove GA Login and update TFA to the 2.0 branch
7. Export your new config with drush cex
8. You should now be able to reset your dev environment to its usual settings, i.e., undo step 1
9. Before deploying code to an environment where TFA is enabled (& GA Login erroneously), you will need to re-update the database, i.e., repeat steps 2 & 3

It doesn't seem as simple as that.
I couldn't upgrade TFA to 2.0@alpha without first disabling and removing ga_login because it has a strict requirement for the earlier version:
I tried modifying composer.json to use the new 2.0 version (changed "drupal/tfa": "@alpha" to "drupal/tfa": "^2@alpha") and ran composer update drupal/tfa. The response was

 Problem 1
    - Root composer.json requires drupal/tfa ^2@alpha, found drupal/tfa[2.0.0-alpha1, 2.0.0-alpha2] but these were not loaded, likely because it conflicts with another require.
  Problem 2
    - drupal/ga_login is locked to version 1.0.0-alpha6 and an update of this package was not requested.
    - drupal/ga_login 1.0.0-alpha6 requires drupal/tfa ^1.0 -> found drupal/tfa[1.0.0-alpha1, ..., 1.0.0] but it conflicts with your root composer.json require (^2@alpha).

I actually tried that above command twice, the second time with --with-all-dependencies because the above response also included a suggestion that that would help. Apparently not.
Disabling ga_login and removing it from composer first and then upgrading TFA unsurprisingly lost my existing TFA code, so I'm prompted to set up two factor authentication again.

What is the upgrade path?

Is there recommended procedure/order of operations for removing GA Login and using what will now be in cor TFA?
It would be nice if the upgrade doesn't require users to set up up TFA all over again. Is that possible?

$view->total_rows = count($view->result);

isn't very important, but as I've noted above, it makes sense to do so. What you really need before updating the page info is to fix the pager's concept of the row count:

$view->getPager()->total_items = count($view->result);
$view->getPager()->updatePageInfo();

Snippet works like a charm:

$view->total_rows = count($new_result); // Not strictly necessary, but nice to keep this in sync
$view->getPager()->total_items = count($new_result);
$view->getPager()->updatePageInfo();

FWIW, the Diff module → adds this information the the output in the meantime.
It would be nice, however, if this table were produced using a View, so it could be more easily modified.

I don't think this does what it says, or else "enabled" means something entirely different than I expect. The value changes from "No" to "Yes" as soon a user who is required to set up TFA logs in, not because the user has actually "enabled" TFA on his/her account.

Excellent! Worked like a charm (v9.5.3)