[Dev] Global Remove

[BGSWebDesign]

Note: This is a split thread...continued from this post

DW,

If you can get the email address based on the UID you could perform a simple query to remove users from all lists:

Yes, I do this as per your previous instructions on how to do a global delete, BUT, the problem occurs when someone does a delete from ONE list using the Delete From This List command (which is basically the same as your previous delete code, what I did was copied that and added a REMOVE ALL functionality in the admin.php like this:

Code: [Select]

// ADDED ADDITIONAL TEXT HERE TO DISPLAY REMOVE ALL LINK... WHICH CALLS remall.php (a COPY I made of the remove module with added code)
     $rtext = "To be removed from ALL mailing lists, click:\n" . $lmpath . "remall.php?u=$usid\n\n";
     if($data1) { $rtext .= $data1 . "\n"; }
     $rtext .= $lmpath . "rem.php?u=$usid";
    }


And I added the globals like this:

Code: [Select]


 // BAS-MOD ADDED REMOVA ALL GLOBALS
 global $remallconform; global $remallsucform; global $remallerrform;

 $loadfile = "editlists.php"; // default

 if($cpage=='listsup') $xtra = '&getcode=1'; else $xtra = '';
 if($cpage=='confcode') { $xtra = '&codes=1'; $loadfile = 'editconf.php'; }
 if($cpage=='custom') {
  $loadfile = "custom.php";
  if($confirmform) $xtra = '&confirmform=1';
  if($subform) $xtra = '&subform=1';
  if($suberrform) $xtra = '&suberrform=1';
  if($remconform) $xtra = '&remconform=1';
  if($remsucform) $xtra = '&remsucform=1';
  if($remerrform) $xtra = '&remerrform=1';
 // BAS-MOD ADDED REMOVE ALL GLOBALS
  if($remallconform) $xtra = '&remallconform=1';
  if($remallsucform) $xtra = '&remallsucform=1';
  if($remallerrform) $xtra = '&remallerrform=1';
 }


I still add the standard !remove code (which displays remove from this list), then I added my own remall.php module - so the users see two links - Remove from This list, and Remove from ALL lists - I wanted to make sure I had that option so I don't lose people who still want to be on other lists.  

But, the problem with this is that if someone removes from this list first, it removes that UID from the list, so if they later click on the REMOVE ALL link the uid is no longer there - even though they may still be listed in other lists - my solution was to add NEW custom html code in the custom table that displays a different message if they click REMOVE ALL then if they click REMOVE, that html code displays a message that You are no longer listed in the database - you may have removed yourself earlier from a single list - to guarantee you are removed from all lists you can Email the list administrator to ask to be removed.... something like that...

Then I added code to custom.php to allow for this (and the other error codes):

Code: [Select]

if($remallconform) { $formdata = "
...

if($remallsucform){ $formdata = "
...


if($remallerrform){ $formdata = "
...


And added code to around line 150 like this:

Code: [Select]


if(!$subform && !$suberrform && !$remconform && !$remerrform && !$remsucform && !$remallconform && !$remallerrform && !$remallsucform && !$confirmform) { $confirmform = 1; }

if($subform){ $refval = 'subscribe'; }
if($suberrform){ $refval = 'suberror'; }
if($remconform){ $refval = 'remove'; }
if($remerrform){ $refval = 'remerror'; }
if($remsucform) { $refval = 'remsuccess'; }
// BAS-MOD ADDED ALL BUTTONS HERE TO CALL UP ALL FORMS FOR ENTERING CUSTOM TEXT
if($remallconform){ $refval = 'removeall'; }
if($remallerrform){ $refval = 'remallerro'; }
if($remallsucform) { $refval = 'remallsucc'; }
// BAS-MOD END


Which gives me extra buttons in my Custom HTML menu at the top of:
UnsubALL Confirm, UnsubALL Success, UnsubALL Error.

This adds rows to the custom table to allow for displaying different custom HTML screens for UnsubALL Confirming their decision to remove from all lists, Success at removing, and Error removing (this error message is the one where I tell them to make sure they are removed from all lists - email the admin).

if I don't put auto-resume into the release I could work on it shortly after. I'm working at getting everything possible into the program ASAP.

GREAT, I can't wait for the new release!  I hope that you can work in the auto-resume as I feel it will still be needed, but let me test out your new admin.php module changes - did you make ANY changes to domail.php in this newest release?

Well, that's about it...

Thanks for the input and I'm very happy you've decided to make LMP your priority now - and to grandfather those of us in who have purchased previously.

Thanks Dean,
-Brett

[DW]

Brett,

Sounds like you're pretty deep into the modifications.   You've practically rewritten rem.php already.  Why not modify the Remove Link code to send the email address instead of the UID?

The way I do it in the upcoming release is with 2 extra data fields in lm_codes.  These 2 fields are used for 2 more options for the Remove Link.  The first one is "one-click remove", which skips the Remove Confirm page, and the second one is multi-list removal.  When a Remove Link is set to multi-list (or all lists) unsubscribe it adds a variable to the Remove Link code that tells the script what ID (in lm_codes) to look for the lists to unsubscribe from and the UID is used for lookup.

You know, now that you bring it up, my script will suffer the same problem that yours does!  This could (does..) mean changing ListMail's remove link code to use the email instead of, or with, UID when doing multi-list unsubscribe..  :x

I do not believe I have made any changes to domail.php in the latest minor update.  Most of them were made to the domail() function, called BY domail.php.  There are significant changes in the major update coming, though, as message editing pages have been revamped.

Regards!

[DW]

Hey, Brett.  What if you were to keep removed users in the database?  Instead of using DELETE, use the command:

update $utable set cnf = '2' where uid = '$u';

This way, the old UID will still exist in the database to retrieve the email address from.

[BGSWebDesign]

Hi Dean,

Hey, Brett. What if you were to keep removed users in the database? Instead of using DELETE, use the command:

Basically that code is what I have - I think, here's what is at line 44 and 139 in rem.php:

Code: [Select]

update $utable set cnf = '2' where uid = '$u';

I just tested it, basically you're saying that IF I set the option to Keep Users in Database instead of removing it should act the same way right?  I tried that but if I delete from THIS list , I still get the message if I later try Delete from ALL list that the User is not found:

Code: [Select]

User not found in database. Did you already click remove?
This ID no longer exists and you will not be sent any more email.

Where do you suggest I make this change in the code?  Can you tell me what should be here to guarantee that I can find the uid - oops... found it, look below...

DW - ok, I changed the code in line 64 of my remall.php to read like this:

Code: [Select]

$cmd = "select id,list,fname,lname,email from $utable where uid = '$u' and (cnf = '1' or cnf = '2')";

Note I added "or cnf = '2' to the SQL select to make sure it pulls the record - even if they have been previously deleted (set to '2'). That pulls the UID up, even if they have already been set to '2' by the Delete from THIS list call - BUT, now when the user clicks the Delete from ALL button on the Delete from ALL Confirmation page, they get the message from the Delete from THIS list Success page instead of from my Delete from ALL list success page???  

Can you tell me where this call is ending up (should I change 'rconf' to 'rconfall'?  Where is the <Form> being submitted to in this call in my remall (line 86):

Code: [Select]


   $buttoncode = "<form name=rconf method=post>


Is that correct?  

oops - ok Dean I solved that one too, basically I had the wrong select in my remall.php, here's what I put in to make it select the correct Remove from ALL Success page:

Code: [Select]


  $cmd = "select data from $vtable where list = '$list' and ref = 'remallsucc' limit 1";


That's it, everything works fine - it's great, if they click Remove from THIS list and try Remove from THIS list again they get the message User does not exist in Database, already removed, but if they try clicking Remove from ALL lists after they have clicked remove from THIS list they get the correct screen to let them Remove from ALL lists, clicking that gives them the success page and removes them from all lists - FANTASTIC....  does your modification work the same way?  Does it also allow for custom HTML code for Remove ALL and Remove from THIS?  I think that's important as I needed the extra HTML code to display different pages....

Oops - one little thing I didn't think of, there's a slight inconsistency since if they click Remove from ALL lists and then the button to remove, and then click Remove from ALL lists again (in their email) they still get the page that says 'retrieved your email from the database' - this is because of adding the extra search for the or CNF='2' option - so basically would need another flag here that they removed from ALL already - maybe set CNF='3' when they Remove from ALL would do it?

Thanks, I think we almost got it....  can't wait for that new version  

[DW]

This is tricky.  I need to figure this out and finish up the feature.  Basically, this is what I have in mind.

"Remove Link" code:

- 1-click Remove Option
- Current List Only, choice of Custom HTML (Default for current list or custom)
- Multi List, choice of Custom HTML

Of course, Custom HTML must be "modularized" before the choices can be presented.  I may implement this without the choice of Custom HTML at first.

Now, the remove link format is what we need to fix.

Currently, it looks something like this:

http://site.com/rem.php?u=1a2b3c4

To be able to read options from the Remove Link code, we need to pass it's ID in the link, something like this:

http://site.com/mail/rem.php?u=1a2b3c4&c=12

Now, thanks to you pointing out the weakness in this method, I'm considering something completely different.

Not all people are going to "Keep removed users in database" so if they remove from the current list, then try to remove from ALL lists, their uid will not exist.  To get around this, the best way is to include the email address directly in the link.  This will, unfortunately, create much longer remove links.  We also have to use either the UID or set a new variable containing the "current-list" so that we can determine default Custom HTML if a custom choice is not chosen, etc.  So the link might look like this:

http://site.com/mail/rem.php?c=12&l=5&e=test@listmailpro.com

We could also concatenate all data into a single variable, ie:

http://site.com/mail/rem.php?x=12,5,test@listmailpro.com

While I don't like the link being longer, it seems to be the only way to implement multi-list remove effectively.

Thoughts? Comments?

Regards

[BGSWebDesign]

DW,

http://site.com/mail/rem.php?c=12&l=5&e=test@listmailpro.com

This sounds fine to me, however, what do you think of setting cnf='3' as I mentioned to track if they have removed themself from ALL lists already?  I believe you're still going to need that, right, since if they are 'keep all removed users' and they click to 'remove from all', and then do the same thing again - Oops, they've already been removed, see the problem here?

I think you need to set cnf='3', what do you think?

[DW]

A cnf setting of 3 is used for "Bounced" users still in the database.

If the rem link includes the code id, current list, and email address, we should be ok.  Of course, it will be backwards compatible if $u is found, defaulting to the current options (user list Custom HTML and non 1 click or multi-list remove).

I'm thinking this format is most suitable/attractive:

http://site.com/mail/rem.php?x=1,23,test@listmailpro.com

Doing this will allow us to find Custom HTML to use when the user is not found in the database on any of the lists being unsubscribed from.  You will need to create 2 message codes, one for removing from the current list and one for removing from all lists.  If the user is not found, with either link, in any of the lists, the chosen (or default, set up in the msg code) Custom HTML error page / error message will be shown.

Since we're moving away from UID and are including the email address in the link, one will not be required to keep users in the database for this to work.  Customizing cnf will not do anything that the new code and link can't provide.

For your current working customization you could retrieve the email address using the (old, removed) UID, detect whether or not this user was already removed, then perform the check again on all other lists, searching only Active users.  You shouldn't need to change the value of cnf.

I'm working on modularizing the Custom HTML now so that Signup Forms, Remove Links, and Confirm Links can be much more diverse.

Regards!

[BGSWebDesign]

Hi DW,

Code: [Select]

http://site.com/mail/rem.php?x=1,23,test@listmailpro.com


The reason I do NOT like this is that it's not visibly clear what the parameters are by looking at the call, while with this, it is clear:

Code: [Select]

http://site.com/mail/rem.php?c=12&l=5&e=test@listmailpro.com

link, in any of the lists, the chosen (or default, set up in the msg code) Custom HTML error page / error message will be shown.

One request, provide a way to let us save a GLOBAL html error page/message for each of the options, Remove THIS list, Remove Success THIS list, Remove Fail THIS list,  Remove ALL lists, Remove Success ALL lists, Remove Fail ALL lists.

For your current working customization you could retrieve the email address using the (old, removed) UID, detect whether or not this user was already removed, then perform the check again on all other lists, searching only Active users. You shouldn't need to change the value of cnf.

I don't follow this, here's an example, look up UID because user clicked Remove ALL lists, how do I detect if already removed, need to look for cnf='1' or cnf='2', perform check in ALL other lists and set cnf to WHAT ('2')?  User clicks the same link again - the check still looks for cnf='1', or cnf='2' otherwise it wouldn't find the user who removed themself from THIS list and then clicked Remove ALL lists, therefore cnf needs another setting - if 3 doesn't work, choose another number, 4, 5, 6, it seems cnf needs another number, I don't see a way of doing this, unless you can be more specific - it's your code, but I don't see it...   let me know?

Regarding using email address as you propose. As you already mentioned, it stretches the link out to HUGE - I have some email addresses that are 50-60 chars long!  I suggest you follow the setting of cnf to another number as indicated above, I believe it's best that way, you don't want to stretch out the Remove Link like that, it will discourage users from clicking, and webmasters from buying your software - just my two cents....

What do you think?

[DW]

Okay, so what if I made the program only output the email-style link IF you have not chosen to keep removed users in the database (or provide an option)? If users ARE kept in the database we can continue to use the UID-style link (plus the msg code ID to get the options), performing a check to avoid problems like the one you are trying to implement.

http://site.com/mail/rem.php?x=1,23,test@listmailpro.com

The reason I do NOT like this is that it's not visibly clear what the parameters are by looking at the call, while with this, it is clear:

http://site.com/mail/rem.php?c=12&l=5&e=test@listmailpro.com

I agree that it is simpler to understand what is happening in the 2nd link, but on the other hand noone can really make sense of either one anyways.  The first link is shorter, why wouldn't you want that?

A uid-based link with the code id might look like

http://site.com/mail/rem.php?u=1a2b3c4&c=12
-or-
http://site.com/mail/rem.php?x=1a2b3c4,12

Again, do you prefer seeing more variables (link 1)?  I am not sure if I agree..

One request, provide a way to let us save a GLOBAL html error page/message for each of the options, Remove THIS list, Remove Success THIS list, Remove Fail THIS list, Remove ALL lists, Remove Success ALL lists, Remove Fail ALL lists.

Each code will have it's choice of Custom HTML.  You will have two remove links if you like, one for global and one for single/current list.  Therefore this will be completely possible with modularized Custom HTML.

I don't follow this, here's an example, look up UID because user clicked Remove ALL lists, how do I detect if already removed, need to look for cnf='1' or cnf='2', perform check in ALL other lists and set cnf to WHAT ('2')? User clicks the same link again - the check still looks for cnf='1', or cnf='2' otherwise it wouldn't find the user who removed themself from THIS list and then clicked Remove ALL lists, therefore cnf needs another setting - if 3 doesn't work, choose another number, 4, 5, 6, it seems cnf needs another number, I don't see a way of doing this, unless you can be more specific - it's your code, but I don't see it... let me know?

I was hinting at checking the database to make sure that every user with that email address is not set to cnf = 2.

What about adding an extra SQL query AFTER the "where cnf=1 or cnf=2" one (that retrieves the email) to again check cnf = 1 (with the email)?

[BGSWebDesign]

Okay, so what if I made the program only output the email-style link IF you have not chosen to keep removed users in the database (or provide an option)?

Why make it harder on yourself?  Do it all the same way, and we know that putting the email in the link is too long, and will cause wrapping problems in many readers.

Again, do you prefer seeing more variables (link 1)? I am not sure if I agree..  

There are commas in the second (shorter link), I'm not sure how well this is treated by ALL email readers, whereas the first link (with the '&') is more common and probably easier recognized by email readers - the only reason I say this is because I'm currently using link tracking software, that software appends a numbered parameter at the end of the link (to guarantee that there are 50 unique links) like this:

Code: [Select]

http://mydomain.com/a/t.cgi?095676543hb

For some reason, recently that link is getting knocked out by Email readers and the person reading their email says they never see the link because the numbered part is chopped off!   So, it seems that some readers do not like certain formats (unless you would know why the readers would do that?), I don't have a clue, that's why I suggest the first link.

What about adding an extra SQL query AFTER the "where cnf=1 or cnf=2" one (that retrieves the email) to again check cnf = 1 (with the email)?

That adds overhead to every REMOVE request, when there are hundreds coming in at once it's too time consuming, ONE SQL query is enough, all that needs to be done is assign another number to cnf such as 4, 5, or anything else, that way the number of SQL queries are reduced, you get the unique ID you wanted and you know it wasn't previously deleted, it solves everything ; )    Just tell me where to set that in my rem.php and remall.php and I'll do it too.

[/quote]

[DW]

Okay, so what if I made the program only output the email-style link IF you have not chosen to keep removed users in the database (or provide an option)?

Why make it harder on yourself? Do it all the same way, and we know that putting the email in the link is too long, and will cause wrapping problems in many readers.

If the email address is never used a problem will still exist for those who do not keep users in the database and want to use current + global remove.  Sure, we can warn everyone, but it would be better if there was an option of different styles.  It wouldn't be very time consuming to implement and will cover everything we both like.

http://mydomain.com/a/t.cgi?095676543hb - For some reason, recently that link is getting knocked out by Email readers and the person reading their email says they never see the link because the numbered part is chopped off! So, it seems that some readers do not like certain formats (unless you would know why the readers would do that?), I don't have a clue, that's why I suggest the first link.

I think I know what the problem is with that link.  It's the fact that it doesn't define a variable name.  The target script likely reads the "Requested URL" and parses it to get the data.

A proper link would include, for example, x=
http://mydomain.com/a/t.cgi?x=095676543hb

I didn't think about the ability to parse the Request URL for the remove link.  It looks snazzy but as you mention, can cause problems due to programs not recognizing the link as valid.

My shorter suggestion does contain the "x=" part, but simply uses (non-special) commas in the string of that variable to differentiate between data fields, so it should be perfectly safe.

That adds overhead to every REMOVE request, when there are hundreds coming in at once it's too time consuming, ONE SQL query is enough, all that needs to be done is assign another number to cnf such as 4, 5, or anything else, that way the number of SQL queries are reduced, you get the unique ID you wanted and you know it wasn't previously deleted, it solves everything ; ) Just tell me where to set that in my rem.php and remall.php and I'll do it too.

I didn't mean for my suggestion to be a permanent workaround - just until the update.  The server should have no problems handling the extra query.  After all, dozens of queries are executed processing message codes for each and every message.

I don't follow you on the changed cnf setting but am willing to try to help you.  When/where do you propose the user be given a cnf such as 4?  What should happen when they try to remove, etc.  I'm reading your previous posts so you don't have to repeat yourself.

I don't follow this, here's an example, look up UID because user clicked Remove ALL lists, how do I detect if already removed, need to look for cnf='1' or cnf='2', perform check in ALL other lists and set cnf to WHAT ('2')? User clicks the same link again - the check still looks for cnf='1', or cnf='2' otherwise it wouldn't find the user who removed themself from THIS list and then clicked Remove ALL lists, therefore cnf needs another setting - if 3 doesn't work, choose another number, 4, 5, 6, it seems cnf needs another number, I don't see a way of doing this, unless you can be more specific - it's your code, but I don't see it... let me know?

Yes, "2" is the cnf setting for Removed.   This is all getting a bit confusing  Okay, we must remember that the UID must always be able to be found in the database for each list that has any remove link sent to it.  Therefore, changing any user on any list's cnf to an unrecognized number will simply cause the email to be "not found" when a global remove is attempted from a message sent to the same list.  You always need to be able to retrieve the email from every UID, but you have to detect when they are removed from all lists.

I still think it is best and easiest to perform a 2nd query.  Check the email instead of the UID in the standard cnf=1 statement. (Add some custom code above it to check cnf='1' and cnf ='2' to get the email address from the UID.)  Remember, this is only temporary.  I'm working on an official version for the update.

Regards

[BGSWebDesign]

Hi DW,

Sure, we can warn everyone, but it would be better if there was an option of different styles. It wouldn't be very time consuming to implement and will cover everything we both like.

Ok, go ahead, if it's not too time consuming  :lol:  as long as we can see an update in the next few weeks... what's the current ETA?

http://mydomain.com/a/t.cgi?095676543hb - For some reason, recently that link is getting knocked out by Email readers

I think I know what the problem is with that link. It's the fact that it doesn't define a variable name. The target script likely reads the "Requested URL" and parses it to get the data.

A proper link would include, for example, x=
http://mydomain.com/a/t.cgi?x=095676543hb

Ok, I just verified it's on AOL that it's stripping off the end of that link, so I updated my script to let it pass through as:

Code: [Select]

http://mydomain.com/a/t.cgi?ca=095676543hb

Do you believe that it will pass through AOL's mail readers ok  now?  Have you heard of this happening to others?

I didn't mean for my suggestion to be a permanent workaround - just until the update. The server should have no problems handling the extra query. After all, dozens of queries are executed processing message codes for each and every message.

Ok, then no problem, just forget about the 'cnf=4' thing, I'm fine with how it works temporarily for now, didn't mean to confuse you and only brought it up as I assumed you were updating the code and that you are still using 'cnf='?  Are you?  If so I could see using the cnf= to check a global remove - and save yourself a step of having to pull multiple SQL queries, I disagree on the pulling multiple SQL queries, it eats up CPU, remember if I put in the THROTTLE CODE all is well, if I take it out, I get very few removals!  

Anyway, I"ll leave it up to you, I've had my 2 cents, just keep us posted on when this is going to be released as I believe THIS THING IS GOING TO BE INCREDIBLE if you get the rule based part of working too!!!  Regarding the cost, and grandfathering, you should consider charging more to make ends meet if you're not going to have subscribers, the updated package is easily worth 2-3 times what you charge now...

Good luck...

Thanks,

[DW]

Ok, I just verified it's on AOL that it's stripping off the end of that link, so I updated my script to let it pass through as:

Code: [Select]

http://mydomain.com/a/t.cgi?ca=095676543hb
Do you believe that it will pass through AOL's mail readers ok now? Have you heard of this happening to others?

I have not heard of this happening but I suspect that your new link will have a much higher chance of getting through.

I'm making good progress.  The selective sending is finished.   I finished up most the Custom HTML modularization/upgrade process last night.  Once I work it into the interface I'll be finishing the new Remove Link.  After that, I'm thinking to make a number of easier modifications and then release!

Thanks a lot for your input! I hope to discuss more features with you soon.

[DW]

This feature has been implemented in version v1.8!