Great module....currently using it one a high traffic site but I found a small issue with this module.
This is maybe an oversight of the module (or not), but user registration emails are queued. I would have preferred user registration emails to be sent right away.
If I am a user, and I register on the site, I will get a confirmation message saying "your login information and further instructions have been sent to your email address". Naturally, I check my inbox and no email is there.
I know I can set cron to run more often, I have it running hourly, so the user will get the email within the hour. But as its a high traffic site (approx 40,000 page requests per hour), I don't want to overburden the server with running cron every 5 mins....unless you can suggest a better way.
Is there a way to specify what emails are queued? I am under the assumption that ALL emails are queued.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 356200.patch | 3.01 KB | aufumy |
| #8 | 356200.patch | 2.96 KB | aufumy |
| #2 | 356200_D5.patch | 3.34 KB | xamount |
Comments
Comment #1
kbahey commentedThat is the design: everything is queued.
We can change that to have priorities (e.g. "immediate", or "delayed").
Then the email key can be checked and assigned immediate.
But someone has to come up with a clean patch for this that is simple, readable and maintainable.
Comment #2
xamountI have attached a patch that does this.
I created an admin area at admin/settings/queue_mail where admin can set which $mailkeys they want to be bypassed. Admins can enter a comma separated list of $mailkeys
I tested and it seems to work but feel free to test it out and report bugs and ways to improve (especially in areas of performance and efficiency).
Comment #3
Patroclas commentedAny chance of someone posting a version with this patch applied?
Comment #4
kbahey commentedHow would the site admin know what keys to type in? They have to look at the source code?
We need a better way.
Also, if this has a D6 version, it has more of a chance of getting in, rather on being on the older version only.
Comment #5
wwwoliondorcom commentedAlso interested. Thanks.
Comment #7
HS commented+1 for a D6 fix.
User registration emails have to always be instantly delivered. This is a major drawback for any Drupal site if login information isn't delivered instantly. IMHO this can't be by design and should not be marked as a feature request.
Comment #8
aufumy commentedInitial patch cleanup for drupal 6.
Comment #9
kbahey commentedI like the patch, with a few exceptions:
1. Do we really need a separate permission for this? Can't "administer site configuration" be used?
2. The concern in #4 (how to know mailkeys) is not addressed.
Comment #10
parasolx commented+1.. thumbs for this patch..
but as all mention, what meaning of $mailkey actually? can give some example where to refer of this key.
thanks in advance
Comment #11
xamountI agree with kbahey that looking for the mailkey in the source code is not ideal....what other options are there? any ideas?
Comment #12
parasolx commentedi looking in source code, especially user module (core) and found some mailkey.
apply it but nothing happen. email of new registration, password reset still pending.
Comment #13
aufumy commented1. Changed permission to 'administer site configuration'
2. Added details as how to know the mail key.
parasolx, check "/admin/reports/job_queue", if there are queued jobs, running cron.php will send out the queued mails.
Comment #14
kbahey commentedCommitted.
Thanks.
Comment #16
timtrinidad commentedThe patch to queue_mail.inc's drupal_mail_wrapper references "$mailkey", but $mailkey doesn't seem to be defined.
I think the following line fixes it:
Comment #17
cor3huis commented@timtrinidad , thanks for reporting a newly possible bug.
Q: Could you file it as a new Bug?
... since the code in this issue is now in -dev version and therefore anything found should be filed as an issue against the -dev version TIA
Comment #18
cor3huis commented