Ok, thats good. That actuall points to an error thrown in drupal which makes this more likely to be able to solve within the module. In what drupal version do you get this error? I have not yet been able to reproduce this error.
If you come to think of any other debug info that would be good to know investiating this to narrow down the issue it would be much helpful.
For example
What drupal version?
What browser are you using?
Do you get same issue on different browser? (All though I dont think this is a client side error but it could be a combination)
Thank you for the feedback. Can you please provide more info about the issue. Like inspect the networktab for clues of what is throwing this error. And check in Drupal logs to get clues of what is causing the error. As mentioned the module does not explicitly throw any 415 error so there must be something else interfering, either deeper level drupal or server infra.
Added patch for proposed fix of specify content-type in the JS requests. Even if this does not fix the issue this is a obvious improvment that will go out in the next release.
Hmm 415 status code; Unsupported Media Type is not an error that is thrown by this module. I have not been able to reproduce which indicatest that this is not even thrown by Drupal, but I cannot say that by 100% certainty.
What does Drupal log when this happens? Is it consistent?
How ever, the JS in this module does not specify the requested contenttype that might make some servers och firewalls or similar throw the error.
An obvious improvment would be to have the fetch in the JS script be more specific of what its asks for. I will put that in the the queue improvments. Maybe that would solve your problem...
Good catch. That description was not very clear.
The include_destination config is specifying if destination query parameter should be included in the redirect url that is used for redirect after logout of user.
That works as designed but I have in the latest beta release now specified the descriptions for that.
How ever, you can still define the destination parameter (or even the redirect url) by using the AutologoutProfileAlterEvent.
Aha, it seems like there is not yet a consensus of what the use statement order should be
https://www.drupal.org/project/coding_standards/issues/1624564
📌
Coding standards for "use" statements
RTBC
It makes sence that I implement it as gitlab-ci wants it (even if we don't really agree with it at the moment) and change once/if the standard gets in place in gitlab-ci.
I push a revert of the alphabetical sort now to the 1.0.x
Maybe its a bug in gitlab-ci phpcs? Worst case I could make a skip for that phpcs rule but thats is not ideal.
Yes, but that is the thing. If I make phpcs locally happy (with the alphabetical sort order) gitlab-ci complains and vice versa.
Phpcs locally, and for you obviously, want it sorted one way. Gitlab-ci want is sorted an other. Having different views of how uppercase/lowercase fits in the alphabetical order.
@vishal.kadam
Good inputs. I have now taken care of the suggested changes.
But, the phpcs issue is a mysterium. When running phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml autologout_alterable/ I also got the "Use statements should be sorted alphabetically." error and the order that has been updated now makes sence for a human.
But ci in gitlabs has a different opinion of what "sorted alphabetically" means.
see: https://git.drupalcode.org/project/autologout_alterable/-/jobs/3129616
It seems like in gitlab ci "autologout_alterable" should be sorted after "Core", e.g. uppercase "C" goes before lowercase "a". Could that be system dependent?
I would very much keep it in the now updated order, which also is what phpstorm ide autoformat it to. But at the same time I dont want gitlab ci to fail on phpcs. Any idea how to resolve it?
andersmosshall → created an issue.
Proposed solution via patch file.
andersmosshall → created an issue.
andersmosshall → created an issue.
A proposed solution patch to this issue. See Proposed resolution section.
andersmosshall → created an issue.
Also noted this issue. There is a change record for ajax.js in core here.
https://www.drupal.org/node/3293812 →
Effectivly the suggested solution is to store the original success callback, do your processing and then call the original callback again.
I created a patch doing just that.