Closed (fixed)
Project:
Simplenews
Version:
8.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
2 Mar 2019 at 16:23 UTC
Updated:
23 Jul 2019 at 09:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
adamps commentedThis patch applies after #3013721: SubscriberForm overwrites existing subscription data has been committed so it won't apply now. However I'll upload it anyway to make sure it doesn't get lost.
Comment #3
adamps commentedComment #4
berdirOne problem is that I think we now have 3 local actions on that page I think. We've already been discussing a bit about the existing two because the recommendation is to only have two of those. Maybe import/export should be somewhere else instead, not sure.
Comment #5
adamps commentedGood point. For me there are 3 already: Mass subscribe, Mass unsubscribe, Export. I have raised #3037266: Reduce number of local actions on subsribers page
Comment #6
adamps commentedComment #8
adamps commentedComment #9
berdirI feel like doing this needs more of a justification than just "because we can", especially due to the problem with the now 4 local actions.
What's the use case for this? Maybe mass-subscribe could better support this, for example by offering an edit link when subscribing a single e-mail?
Comment #10
berdirBasing this on having or not having an e-mail seems a bit strange, why not use !isNew()?
This is also a bit strange IMHO, you could for example instead check the form id, which should contains the operation, a subclass or $form_state->get/set
Also, the add form IMHO looks quite weird, e.g. e-mail not being the first element.
Comment #11
adamps commentedMass subscribe does not allow setting fields whereas this way does. From a usability perspective, it's not intuitive that the way to add a single subscriber is to click mass subscribe. This patch makes the subscriber behave the same way as Drupal core entities.
If you had raised your comment 3 months ago then I would have no problem dropping it. Seeing as I have now just finished writing tests then I'm not keen to throw the work away. I think we need to keep moving forwards not backwards. We already have 3 local actions and it's too many. If you feel strongly about that then you could post a patch for #3037266: Reduce number of local actions on subsribers page.
Comment #12
adamps commented@Berdir Thanks for the review
1. The code as I wrote is necessary to solve #3031919: Bugs if user has blank email address.
2. Good point. Do you mean like this?
3. This fix has not changed the form order of the email field. The code that pushes it after other fields already exists in
Subscriber::baseFieldDefinitions(). However I agree it would be better to have the email earlier and I'm happy to put it to the top.Comment #13
berdir> If you had raised your comment 3 months ago then I would have no problem dropping it
Yeah, if only I'd made the same comment already 4 month ago ;) I didn't say to drop it, but maybe solve the other issue first. Just not sure how, maybe local tasks would work better, but might also be weird, especially when editing a subscriber.
2. Or just $this->getFormId(), this is the form class.
3. I know it's the same as edit, but the situation is different, for edit, the e-mail is not so important, for add, it is.
Comment #14
adamps commentedSorry I don't have time to solve any extra issues. My priority at the moment is to clear all my part-finished issues so they don't need huge rerolls with upcoming big tidy up: #3055728: Convert from Simpletests to PHPUnit tests #3037140: Fix coding standards.
I guess I can commit this one with the action link code commented out and a todo linking to the other issue?
2. Good idea.
3. OK but isn't that just the way Drupal works - the add and edit forms would generally have the same order. What would you like to see?
Comment #15
adamps commented#3037266: Reduce number of local actions on subsribers page wasn't so hard and I have a patch ready that I will post.
2. Fixed
3. I think it is a good idea to put the email first always. When editing a user, the email is hidden, so it makes no difference. When editing a non-user it is quite common to want to edit the email - subscribers cannot edit it themselves so they often ask the admin to change it for them. In any case what we put is just a default value and anyone who doesn't like it can alter it.
I deleted core.entity_form_display.simplenews_subscriber.simplenews_subscriber.account.yml because it's no longer necessary. The access handler will automatically hide the email field.
===
I think this is a long way from being the most important issue, so hopefully we can just commit it and spend our time discussing more strategic ones.
Comment #16
adamps commentedComment #18
adamps commentedI need to commit to unblock other issues. If you have any more concerns then please comment and I can do another commit to fix them.