Problem/Motivation

The user subscriptions page could be enhanced.

Steps to reproduce

Here's the current version, at /user/{uid}/simplenews.

Proposed resolution

(1) Use the url /user/{uid}/newsletters. 'Simplenews' should not be a user-facing term.

(2) Allow sitebuilders to control the order in which the newsletters are displayed. Simplest way is to add an integer weight field to newsletters.

(3) Show the newsletter descriptions.

(4) Have the button say "Update" not "Save".

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
Newsletters-ux.png67.6 KBjonathanshaw
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jonathanshaw created an issue. See original summary.

jonathanshaw’s picture

(3) Show the newsletter descriptions.

I think this may be problematic: if this text has not been exposed to subscribers before, it may have content that is intended only for editors.

AdamPS’s picture

Issue summary: View changes
AdamPS’s picture

(1) I'm not sure about changing the URL. It would break any existing links or bookmarks. Maybe it's borderline if a URL is really a user-facing thing - many people won't even notice them. If any site prefers a different URL then it's pretty easy to change with a hook.

(2) A weight field feels reasonable. Out of the 4 points here this one is probably the hardest to achieve in custom code, hence the greatest justification for including in the simplenews module.

(3) Displaying descriptions would need to be optional. However it's easy enough for any site to add that behaviour in custom code by creating a widget that extends the base widget.

(4) "Update" seems better I agree, it would be consistent with /newsletter/subscriptions. The fix will be tedious as it would require changing maybe 100 lines of code in tests:-) It should be fairly easy to change in custom code with a hook.

AdamPS’s picture

I thought some more.

(1) FYI There is also /node/{node}/simplenews. I tend to think we leave these alone. I agree there is logic to what you say but equally some sites likely prefer it to stay the way it is (e.g. if they wrote their own tests). 3.x is alpha and we are allowed to make non-BC changes but I'd rather do so only for a clear benefit. Drupal is highly customizable exactly for this kind of scenario, and if anybody doesn't like the defaults then they can easily use a hook to alter.

(3) Provided that the descriptions are optional and disabled by default then there is no impact on existing sites. So I'm in principal OK with this one. However it definitely should have tests before going into simplenews.module.

(2) The weight field seems generally useful. However I feel it's not entirely trivial - at least not to me as I'm not familiar with the way it works elsewhere in Drupal.