Each semester, I use the mass mail mod to send out emails once a week to students who sign up to receive them. It works okay up until I get about 100 email addresses signed up, then gets sooo slow, and sometimes times out before I get to the mass mail successful screen.

I signed myself up, and I receive them, even if the script times out- does this mean everyone else does?

Is there something I can do to speed it up?

Sigrid

Hi,

Is it possible to run the mass email script as crontab weekly? This will avoid time out problem

Cheers,

Dat

Programming and creating plugins and templates
Blog

I don't know a whole lot of programming- (like what a crontab weekly is). Would this allow me to schedule the mail-outs, and what messages they contain? That would be great. I'll crack open my perl book and look into that, but if anyone could help, I'd appreciate that too.

This would also solve my memory problem (the memory in my brain, that is- I sometime forget to send them out)

Thanks for the hint,

Sigrid

On a linux system i get that problem, so use Internet explorer from windows to avoid the problem without doing any code adjustments. it shouldn't timeout if you have the browser properties set not to Timeout, ever.

It's a timeout on the browser I think, not anything in the system itself or in the dbman code itself. yes, it can be slow but it will depend on the server's mail prog more than anything. nothing you can do with your dbman code to affect that. albeit, even at that rate sendmail (qmail, whatever) is usually quicker off the server than a 3rd party mail prog, which you could use instead BTW.

It needs to be rewritten to take advantage of fork, allowing the script to quickly return a message to the admin, wihle chugging out the mails in the background. I only recently learned the beauty of fork, and am busy rewriting a lot of my scripts/hacks to take advantage of it.

most definitely I only have spoons... but it works.

I hope you will share any updates or tweaks to existing DBMan mods :)

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

I do have to sit down and conglomerate things myself all into one place.

Here's a for instance. It's a nice idea to get users to go to add form first (must add that record! really!) Ok but having to get a password will send off plenty of good users. what password, check email hoy veh, you know. so hey put the form online at default like here:

https://secure2.pinn.net/...nyapp.cgi?add_form=1

so per example lets say userid is field number 12 which will always be written as default. thats fine buts thats default and that's not fine. so now, they choose their username right on the form itself as they submit, then there's a button on the results page that sends field emailaddress and field username to another file for signup, (have to add-in a new signup mod to separate cgi) and voila registered and app in at one time, almost. add a new cfg file for them to log in, and change userid field from default to the field that contains the username they chose.

We get twice as many signups that way. Now all I have to do is figure out how to get the site to make money... heh. requires hefty code lifting from html.pl but they love that fast form for sure.

it's a pretty chop this add that affair so.... requires some digging. It's getting better, lot of work.

I can lift some code from user-friendly mod to get that verify-accounts to work better think. I found some better code for it too but need to test it.

Thanks!

I would think others would be very interested in your notes on how you incorporated the signup into the add form.

Hope you find some time to share it with others :)

P.S. It's just my opinion but I think to get traffic to your site you may want to consider allowing default users to view your database.

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

Well as for the biz, no, I tried a default search and it didn't help, plus signups dwindled. On that end the site is more succesful when people who would just search the database for fun are hindered I think. But i don't know, I have it written that way also and maybe just need to rearrange it a bit. It's a finicky biz, heavy customer support (phone!) I put it up after I had a database half written for an agency (on their own software) and they screwed me as is par for the course with those businessess many times I think. Not wanting to throw the work out it ended up here in this format. In that it does help keep the competition on their toes a bit, otherwise, far as I know before us they had no competition. I have to be a bit more ingenious with services I think, but as I am sure you know, tackling a database is a major project and things take time. It's a long term project, part public service, part income on this end. What I've found most successful is simply to branch it off, I have a dedicated Christian section at www.christiananny.com, that's popular. and I may move the main database into more refined areas also. Mostly it's a matter of dealing with unscrupulous (totally) competition. It's a very strange field. We have some new competition selling pretty much the same service for 49.00 but I was unable to get any signups at all charging a low fee, people want something more exclusive has been my impression, they don't want to be competeing with every Tom Dick and Harry in town. Plus we need the funds for development. security is number one at all times. The sites may just need updating. I have been working on security and stuff, i will get to the rest eventually. It's good however, been online almost 2 years, have not been hacked, though it's been attempted, we use parse form to pull scripting etc, and I've been tightening it up real good the past several months. we may end up just calling applicants via phone for initial interviews for validation, email can only do so much and cannot really verify anything in a real world scenario. But it's a very good start what we've got.

Essentially to do a default application and enable signups you just need a second cgi setup with it's own cfg file set to the proper userid field.

I use this button on the form results page after initial app submittal to grab the essential info and send it to signup on a separate cgi:

<TABLE WIDTH="550" CELLPADDING=2 CELLSPACING=0 BORDER=1 BGCOLOR="#FFF4FF">

<TR><TD><P><CENTER><FONT face="verdana,arial,helvetica" size="4"><b>Activate Your Account</b></font><br>

<$font>To Activate Your Account Now, Click the Button.

Your password will be mailed to you immediately. Keep this window open while checking your mailbox. Follow Log On directions in the letter.</p>

<P><form action="http://www.mysitehere.com/cgi-bin/mybin/register.cgi" method="post" name="form1">
<input type=hidden name="db" value="register">
<input type=hidden name="uid" value="">
<input type="HIDDEN" name="userid" value="$rec{'Username'}"></td></tr>
<input type="HIDDEN" name="email" value="$rec{'Email'}"></td></tr>
<center>
<input type="SUBMIT" name="signup" value="Click to Activate"></center></form></p></font></TD></TR>
</TABLE>



------

and you can set that as a mod also and just call it like

&html_register_mod;

also. either way. works well. Voila form submitted, user registered, no question about it. if the email address is invalid, they cannot access their account or any other parts of the site, so that's covered. I am using secure-password lookup mod to write the passwords. Th original file that the default app is running on needs to be secure, I have disabled signups from that, pulled view mods etc to be sure someone doesn't try to log on as default. Just an in case measure. All that cgi does is add, it cannot do anything else, period.



we also completely disable searching for name, email and phone fields from the public end of the database using this in query:

# First thing we do is find out what we are searching for. We build a list of fields

# we want to search on in @search_fields.

if ($in{'keyword'}) { # If this is a keyword search, we are searching the same

$i = 0; # thing in all fields. Make sure "match any" option is

$in{'ma'} = "on"; # on, otherwise this will almost always fail.

foreach $column (@db_cols) {

if (($db_sort{$column} eq 'date') or &date_to_unix($in{'keyword'})) { $i++; next; }

if ($i == $auth_user_field) { $i++; next; }

if ($i == $protectd1) { $i++; next; }

if ($i == $protectd2) { $i++; next; }

if ($i == $protectd3) { $i++; next; }

if ($i == $protectd4) { $i++; next; }

if ($db_form_len{$column} == -1) { $i++; next; }

push (@search_fields, $i); # Search every column

$in{$column} = $in{'keyword'}; # Fill %in with keyword we are looking for.

$i++;

}

---etc query as normal and then adding to default.cfg those fields as:

$protectd1 = 1;

$protectd2 = 2;

$protectd3 = 3;

$protectd4 = 4;

----as neccessary, any defined fields won't be returned in a search, say email address, name etc, for the public database to protect the user's privacy. if that all makes sense to you! Most of this stuff I originally got from the dbman unofficial faq site and adjusted it to suit.



I sure could use some help with that verify accounts html.... I will give it a shot later.

quote:
I sure could use some help with that verify accounts html.... I will give it a shot later.

Did you try the latest changes in your original post?

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

not yet. I tried it a diffrent way this morn and CAPUT. I will get to it! I am trying to make it do too many thing at once I think, I use archive which cannot be run via userid so i have to do some wrangling... but it will wait till later! thanks!