Users were reporting that they couldn't update their Send interval on their /user/me/subscriptions->Settings page. I have been able to reproduce it on two installs (one using MariaDB one using MySQL).
Specifically:
/user/me/subscriptions
Settings:
Send interval: As soon as possible: toggle to Hourly
Save
"The changes have been saved."
Settings: is still at As soon as possible.
However if I do this for another user - everything is fine:
/user/1071/subscriptions
Settings:
Send interval: Every 15 minutes: toggle to Daily
Save
"The changes have been saved."
Settings: is indeed Daily.
It's odd that I have permissions to to update another user's Settings - but that they can't update their own. And even I can not update my own Settings. Let me test if it's just Send interval - or more Settings:
/user/me/subscriptions
Settings:
Digest mode: toggle to off
Save
"The changes have been saved."
But -> no the Digest mode check box is still on
So it's not just the Send interval. What about Delivery of notifications:
Delivery of notifications:
toggle to No -> Save
The changes have been saved.
Your subscriptions are suspended. Please go here to resume delivery of your notifications.
And, that's working well!
I have a small subscriptionsedit module that edits some of the descriptions in forms in various places. I'll disable that - just in case. Ran a drush updatedb - just in case.
Still same issue:
/user/me/subscriptions
Settings:
Send interval: As soon as possible: toggle to Hourly
Save
"The changes have been saved."
Settings: is still at As soon as possible.
I'm using: the dev +17 version (pulled from your project site yesterday). Where do you suggest I start to try and figure out what may be happening here? Thanks,
-- Karin
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | subscriptions.remove_arg_calls.1585516.5.patch | 12.35 KB | salvis |
Comments
Comment #1
salvisThank you for the detailed description.
Have you tried to (temporarily) disable the "me" module? That's the pattern that I'm seeing here...
Comment #2
karingAh... clever. Ok - instead of disabling 'me' Aliases module how about I just use my userid to test this:
/user/12/subscriptions
Toggling the Settings->Send interval to something else
Save
You're right: that works!
Does is make sense to you that Delivery of notifications->Receive notifications was editable by users themselves when the url was:
/user/me/subscriptions
but Settings-Send interval (and the other variables under Settings-> were not?
-- Karin
Comment #3
salvisYes, that's not completely unreasonable. The two settings follow somewhat different logic, because the Delivery applies only to users, while the other Settings do double duty for System Settings as well.
I'll have to look into what is happening here.
Comment #4
karingThank you very much - let me know if you can think of anything else I can do on our end to help.
Comment #5
salvisThis is a burden of the past that has come back to haunt me...
As they say: don't use arg()!
Please try and test this patch. It affects many of the paths that Subscriptions uses, especially those with "me", uids, nids, and other IDs.
Comment #6
karingThanks a bunch for this - that was quite a bit of patching on your end:
$ patch < subscriptions.patch
patching file subscriptions.admin.inc
patching file subscriptions.module
patching file subscriptions_blog_ui.module
patching file subscriptions_content.module
patching file subscriptions_taxonomy.module
patching file subscriptions_ui.module
And it worked! I can now update Settings -> Send interval (select) and also eg Settings -> Digest mode (checkbox) when I use a user/me/subscriptions URL.
Anything else you recommend I check/test before I get too excited and push this over to the production site tonight :-)
Thanks!
-- Karin
Comment #7
salvisYes, it was a bad use of Core's API and I've fixed it throughout the module, not just where it bit you. This will also go into the D7 version.
As I wrote in #5, just about all paths with 'subscriptions' in them as well as those with 'node/NID' are affected.
Comment #8
karingOk, I ran some more tests with different URLs and all is working well. So, I've added the patch to the install on the production site and - thus far - no one is reporting any issues. Thanks a bunch!
Comment #9
salvisGreat, thanks for the tests.
I've pushed this to 6.x-1.x-dev and a similar fix to the D7 version.