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.

CommentFileSizeAuthor
#13 356200.patch3.01 KBaufumy
#8 356200.patch2.96 KBaufumy
#2 356200_D5.patch3.34 KBxamount

Comments

kbahey’s picture

Category: support » feature
Status: Active » Needs work

That 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.

xamount’s picture

Status: Needs work » Needs review
StatusFileSize
new3.34 KB

I 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).

Patroclas’s picture

Any chance of someone posting a version with this patch applied?

kbahey’s picture

How 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.

wwwoliondorcom’s picture

Also interested. Thanks.

HS’s picture

+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.

aufumy’s picture

Version: 5.x-1.x-dev » 6.x-1.x-dev
Status: Needs review » Needs work
StatusFileSize
new2.96 KB

Initial patch cleanup for drupal 6.

kbahey’s picture

I 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.

parasolx’s picture

+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

xamount’s picture

I agree with kbahey that looking for the mailkey in the source code is not ideal....what other options are there? any ideas?

parasolx’s picture

i 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.

aufumy’s picture

StatusFileSize
new3.01 KB

1. 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.

kbahey’s picture

Status: Needs work » Fixed

Committed.

Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

timtrinidad’s picture

Status: Closed (fixed) » Needs work

The 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:

$mailkey = $message['id'];
cor3huis’s picture

Component: User interface » Code
Status: Needs work » Postponed

@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

cor3huis’s picture

Status: Postponed » Closed (fixed)