Thanks for checking.
Then Im literally out of clues of whats causing this issue unless there is some module completely overwriting the _content_type_format req for autologout_alterable's routes. Drupal core does not modify them at least, that much I can tell. And I have not been able to reproduce this on drupal 10.4.3.
I cannot investigat this further because I cannot reproduce. I leave this ticket open for a while longer if you or anyone else having this issue have the possibility to investigate.
I'd suggest if possible to spin up xdebug and check the code in /core/lib/Drupal/Core/Routing/ContentTypeHeaderMatcher.php and before to see why the error is thrown and where the constraints are modified, if done so.
The changes made so far though are obvious improvments of the module and will most likely be part of next release of this module.
Thanks for reporting this bug, sorry that it does not seems to be a quick fix.
I can still not reproduce this issue so Im navigating in blind here a bit. But looking at the code in the ContentTypeHeaderMatcher.php it looks for a _content_type_format requirement. How ever if no requirement are set it should fallback on the match that Drupal has already set. Which happens for me.
The only way that it makes sence is if you have a module that by hook modifes the _content_type_format req for routes making this match not empty hence invalidates it.
That being said it makes sence that my module set the _content_type_format req for the patch route so I upload a patch here for you to try. This patch replaces the last uploaded patch (FYI).
On the other hand if there are hooks modifying the _content_type_format req it may very well be overwritten and making this module definition irrelevant anywayh but it is worth a shot.
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.