This is by design. Authentication tokens are not stored in configuration. Except for a raw db dump (with no security striping, not recommended), users will need to re-authenticate when deploying a new site. On a side note, deploying configuration to a pre-existing, authenticated site, should NOT invalidate credentials.
Fixed! Will roll out an RC3 shortly.
The fact that this doesn't include a test, nor does it make existing tests fail, while being a fundamental change of the modules functionality (defaulting redirect from false to true) -- is probably a big enough gap to mark needs work, until a test is added that confirms the new functionality. (or at least confirms the current functionality is broken)
Committed the RC2 code cleanup fixes. Marking this issue fixed, if there are other issues found, a new issue can be made.
the new MR passes tests, committed!
Unfortunately I do not believe such a large change will occur in this module, due to its EOL status. Working to update the documentation so that users will goto the Google Tag module instead. Fortunately the Google Tag module incorporates the goals of this patch, so please try it out!
The previous MR incorrectly sets the GAAccounts wrapper with an empty value. new MR incoming.
japerry → changed the visibility of the branch 3353389-typeerror-argument-1 to hidden.
japerry → made their first commit to this issue’s fork.
Updated the main page to redirect users to the google_tag module.
LGTM -- Committed!
Looks like some pieces are missing from the migration
Oh it also fixed the config issue I was seeing in Drupal 11.2. Committed!
While I'm not sure removing required values is the best idea, this module is EOL and it might help set these to null to facilitate moving to Google Tag. Committed!
rewrote the patch to type set correctly.
Comment #14 hides the actual issue, which is that account info is null but should be an empty string. By properly type setting the variables, these issues won't occur in the first place.
Fixed with the D11 updates.
As this module is EOL, it should not be in the project browser.
japerry → made their first commit to this issue’s fork.
Made sure we still supported older versions of Drupal, especially since this module is EOL. Committed
This module is EOL and should not appear in the entity browser.
Since this module is EOL, it doesn't make sense to have it in the module browser.
The Google Analytics module is sponsored by Google via Acquia, with the 2.x version of Google Tag meant to take over Google Analytics entirely. Any features for Google Tag should be requested in the gtag module, not this one.
If there are blockers to moving to gtag, please add them to that queue! That said, since there are quite a few users still on Google Analytics, this module should be updated to support Drupal 11, if for any reason to help facilitate an easier migration to google tag.
Because of the EOL of this module, there is no need for other maintainers here. If you wish to help out, I'd suggest working on google tag instead.
looks like a missed defect from the previous issue. committed!
japerry → made their first commit to this issue’s fork.
With tests fixed, committed!
The feature has been removed from 1.1. I added back the feature as an MR in this issue and marked NW to be worked on in the future.
japerry → changed the visibility of the branch 3491727-refactor-oauth-support to hidden.
Pushing this to the top to verify before we make the 1.1 release.
Looks good! Committed
I think its a good incremental step forward. Committed
Thanks for testing the RC! Got the patch merged.
No, the issues mentioned in #4 will not be addressed until Drupal 12 readiness. At that time, they will be fixed, as it will require us to drop Support for versions of Drupal 10 under 10.3
Marking this issue 'wont fix' because the other issues get automatically taken care of during our release process.
Committed the changes! We will clean up the rest of the issues, but RC1 will go out next.
japerry → made their first commit to this issue’s fork.
rerolled with some other refactored snippets of this code and committed
Pretty sure this is a duplicate of 🐛 Warning: Undefined array key 1 in Drupal\autologout\EventSubscriber\AutologoutSubscriber->onRequest() Active
Simplified the code and committed.
I think there is some validity to this request, but with subsequent modifications to that code, its not a simple revert anymore. Perhaps this issue can be morphed into make that feature optional?
Moving to 2.x -- while 8.x-1.x releases will still get made (since the branches are exactly the same), there won't be any development on the 8.x-1.x branch anymore.
japerry → made their first commit to this issue’s fork.
This was rewritten in 🐛 Warning: Undefined array key 1 in Drupal\autologout\EventSubscriber\AutologoutSubscriber->onRequest() Active
Simplified the code. I can see why this issue could occur, especially with drush after install now that its optional.
Thanks tame4tex! Tests are passing, committed to both 8.x-1.x and 2.x
Note, there were many comments on this long standing issue (as well as the closed dup), some valid for credit, others not so much. I'm sure some credits were missed -- However, I prioritized the original patch creators for this issue.
japerry → made their first commit to this issue’s fork.
I'll merge this in to fix the immediate problem. the Contrib JS cookie was added because of its removal from core... however I'd need to look back and figure out where that code is being derived from in this module. Agree that its a separate ticket.
japerry → changed the visibility of the branch 3346519-destination-does-not to hidden.
Agree with comment #2, Marking NW.
japerry → made their first commit to this issue’s fork.
japerry → changed the visibility of the branch 3426421-missing-required-form to hidden.
Closing as this work has been made part of 📌 Handling media items when their asset gets unavailable in Widen Postponed which takes larger approach to solving the deleted items issue in Drupal.
So this is a wrapper on entity load, which I think is wrong -- but removing the hook could cause other issues. Interestingly, I think this hook should be called "captcha_point_captcha_point_load" since its loading a captcha_point entity.