There are many reasons why an email is not delivered to the recipient.
And the list goes on!
That should give you an idea why email delivery is so tricky and complicated, which is what created a niche for the email delivery industry, and which is why companies like Aweber, MailChimp and GetResponse even came into existence and have thrived while charging a hefty fee for what you would think is the simple act of delivering email over the interwebs.
When you use DAP for sending out emails (whether autoresponder or broadcast emails), the “From Name” and “From Email” you set up in the DAP Config are used to send out the emails.
If you use your own web host as the “carrier”, then your web host’s email server is the one that carries the email and tries to deliver to the inbox of the recipient. And web hosts are generally not very good at the intricate science of email delivery, which is why if you’re going to use DAP, we recommend that you bypass your web host and have a third-party email system like Amazon SES deliver your emails.
Regardless of the carrier (web host, Amazon SES, AuthSMTP.com, etc), all bounced and undeliverable emails come back to the “From Email” that you have used under DAP Config.
DAP by itself does not do anything with those emails, as those emails don’t come back to DAP, but they go straight to the inbox of whatever “From Email” you have specified.
We will surely address this in the future. But for now, you will have to manually review those email bounces, see which one of them sound more serious (like, say, recipient email id not found, or domain no longer in use, etc), and then de-activate those email id’s from your DAP database.
When you use Amazon SES, Amazon by itself also monitors email id’s that have a consistent history of bouncing back, and will automatically suppress those email id’s and won’t even deliver email to those email id’s even if DAP did send the actual email to those id’s.
One way of setting up Pay-Per-Post in DAP, is to create one product per post, and then sell access to each one separately.
However, if you have a lot of posts, this can be a lot of work.
An easier and more efficient way is to use our credits plugin, “Credit Store“.
Using the Credit Store plugin, you can setup individual pieces of content – like a post, page, category, or even a file – to be Redeemed via Credits, instead of cash. You sell credits, your members buy those credits, then use their credits towards redeeming individual content.
Just like when you buy an iTunes gift card and purchase individual songs or movies with it. Or like buying credits on a stock photo site and then redeeming it for individual images.
Whether that content is a bunch of content all bundled together, or individual posts/pages/files, is up to how you configure and set up your own Store.
The Credit Store plugin is a true game-changer, and allows you to be a lot more creative, and for your content to be delivered in a much more flexible yet powerful manner to your buyers and members.
We already have a few DAP users using the Credit Store (beta) this way, and they’re all loving the power and flexibility of this plugin.
See this for more details on the Credit Store:
As the Credit Store is currently in Beta, if you wish to purchase it now, we will make it available for download in a few weeks and give you access to the plugin for a big discount compared to the price it will be launching at. So feel free to email us or open at ticket if you want more details.
DAP works great with the WP Super Cache plugin. Probably works with others too – but we have officially tested it with just Super Cache at this time.
And this page below walks you through the full set up of the WP Super Cache plugin.
Go to Settings > WP Super Cache
You are now on the “Easy” tab. Don’t do anything here just yet.
Go to Advanced tab.
Be sure to put a “Check” (or “Select” the radio button) next to each of the following items
Cache hits to this website for quick access. (Recommended)
Use mod_rewrite to serve cache files. (Recommended)
Compress pages so they’re served more quickly to visitors. (Recommended)
Don’t cache pages for known users. (Recommended)
Don’t cache pages with GET parameters. (?x=y at the end of a url)
Cache rebuild. Serve a supercache file to anonymous users while a new file is being generated. (Recommended)
Clear all cache files when a post or page is published or updated.
Extra homepage checks. (Very occasionally stops homepage caching) (Recommended)
Only refresh current page when comments made.
List the newest cached pages on this page.
Click on Update Status button.
Keep scrolling down until you see the Accepted Filenames & Rejected URIs section.
You’ll see a big text area under the text “Add here strings (not a filename) that forces a page not to be cached”. +
There, add the following, one per line.
Obviously, your member content page URL’s may be slightly different. So make sure you customize it to suit your own URL’s.
Next to back to Easy tab at the top.
Now you select the “Caching On” option and save.
That’s it for the setup.
Now, on to testing.
If you organize all of your member content under a main parent page, say “members”, then all you need to exclude from caching, is /members/
For example, if your URLs include year and you don’t wish to cache last year posts, it’s enough to specify the year, i.e. /2004/. WP-Cache will search if that string is part of the URI and if so, it will not cache that page.
So basically, excluding just one single URL – /members/ – from caching, will make sure all of the following as well remain UN-CACHED.
You get the idea. When you exclude “/members/”, any URL that starts with that same text, will be excluded.
So here’s how you set up the “hierarchy” of the pages.
First, create the page “members“.
Then, when you create the “login” page, make sure you select the “parent” of the page, to be the “members” page.
So, instead of the login page URL looking like… http://YourSite.com/login/
… because the parent page is “members”, that also gets added to the URL, and the login page URL becomes like this:
If you created a page called “example” and made the “login” page as its parent, then the URL for this new page becomes:
So you see how that hierarchy works. Use that to arrange all of your member content under the main “ancestor”, which is “members”, here in our example.
But if you have already completed creation of all of your content, then you’re just going to have to do a little extra work to identify all of your pages and posts and exclude the member content from the list. DAP makes this a little bit easier as well.
If you log in via FTP and go to the “dap” folder, inside, you will see a file called “dap_permalink_dump.php”. If you download that file to your desktop, and open it with any text editor (Notepad, Dreamweaver, etc), inside you will see a full list of URL’s of all posts and pages from your WordPress site. You can just take that list, remove separator text like “Posts” and “Pages”, and trim the list of URL’s down to just your member content, you can take that and paste it right into the WP Super Cache > Advanced tab > Accepted Filenames & Rejected URIs section.
Now open multiple browsers – like Firefox, Chrome and Internet Explorer (or Safari). Use at least 3 separate browsers.
Next, go to your login page in one of them, and then log in. Then go to same login page in another browser – make sure it doesn’t say “You are already logged in”. It should show you the DAP login form. Same on third browser.
Next go to the profile page while logged in as member. Do the same in other two browsers, while logging in as three different people. Each profile page should you show you different information.
If you crated 3 separate products, with 3 different users, then logging in as those 3 different users on the 3 different browsers, should show you 3 different sets of pages.
All this is just to make sure there’s no caching going on of your membership content, that’s all.
If all of this works, then you’re all set with caching for your non-membership content, and no caching for your dynamic member content.
Or also called as network builder. And we introduced this feature in DAP v4.4.
We call it DAP “Upline” – basically a shortcode called [DAPUpline] that allows you (site admin) to display the person’s upline’s affiliate code to the person. So in effect, it is a downline builder.
1) John joins your site
2) John fills out profile with (say) his ClickBank nickname
3) John refers Adam
4) When Adam logs in, he sees affiliate link to some xyz third party product, but CB nick in the affiliate link is replaced with John’s CB nickname.
5) Adam fills out his profile with his own CB nickname
6) Adam refers Jill
7) When Jill logs in, she sees affiliate link to same third party product, but cbnickname is replaced with Adam’s CB nickname.
This can be done with any number of third-party programs, as long as the nickname can be easily replaced with the info provided by the upline affiliate.
DAP even takes this one step further.
When Jill joins through Adam’s DAP affiliate link, if Adam has not filled out his CB nickname in his profile, then the third-party CB link shows CB Nickname of Site Admin in its place.
So if an affiliate fails to claim his affiliate link, then site admin gets credit for it (and all such links).
Here’s the documentation for [DAPUpline]
In DAP, you can not only send automated pre-scheduled emails to your members (Autoresponders), but you can also set up similar pre-scheduled “Reminder” emails to be sent to you (the admin) every time a member reaches a day milestone.
Eg: Let’s say you (the admin) want DAP to send you or someone on your team a reminder email to follow up with each member by email once they reach day #7 – meaning, it’s been 7 days since they signed up for a specific product.
This is how you do it in DAP:
Now for each member that signs up for that product, regardless of when they join, every time they reach day #7, the reminder email will be sent to the 3rd party email id specified for that message (instead of being sent to member).
If you want to be sent this same email say 3 days before member’s access expires to that Product, then set the email to be dripped on day “-3”. (See Expiration Notifications / Renewal Reminders)
“Will DAP allow me to manually approve members before their new accounts are activated? The process should be…
a) new user signs up, DAP prompts that the account is pending approval
b) Admin approves the account manually and email is sent to new member with their password and login details”
Yes, this can be achieved by enabling the “Double Optin” for a product.
So, normally, when a DAP Product is made “Double Optin” by entering the double-optin subject and email text on the “Email Notifications” tab of the product, and a user signs up for this product (whether as a free sign up or as a paid purchase or Admin-add), DAP will send them the content of this double-optin email first.
And usually, the body of this email would contain the %%ACTIVATION_LINK%% merge tag, which would become the confirmation link that the user has to click on first, before their product access status becomes “Active” (from “Inactive”). And as soon as the user clicks on the confirmation link, their product status becomes active, and then the “Welcome Email” is sent out right away, and now the user can log in and start accessing the content that is protected as part of that product.
Using Double-Optin To Force Approval
If you make the DAP product as double-optin, and remove the merge-tag %%ACTIVATION_LINK%% from the email body, what happens is that the user/member will get the email, but there’s really no activation link (confirmation link) in the email for them to self-activate their account. So the email would just say something like…
“Thank you for your purchase/signup. Your account needs to be activated by us. So appreciate your patience while we do so”.
Now, their account remains at “Inactive” status. And only you, the DAP Admin, can activate it.
By now, you would’ve gotten the admin notification email for this person’s signup. So you know their email id. If not, you can just go to DAP > Users > Manage and you’ll see all inactive users.
You would then click on “Modify” to activate product access. And if the user status is also “Inactive”, then you would edit the user info, and change their status to “Active” (from “Unconfirmed”).
And then make sure you’ve added an autoresponder email (that contains the user’s email and password – insert mergecodes %%EMAIL_ID%% and %%PASSWORD%% into the email) to go out on Day #2 for that product.
And assuming you will be approving this new user at some point within the first 2 days, the autoresponder email for day #2 will get triggered within the hour as soon as you activate their account, and the user will get their welcome email.
Or you can send them the password in the double-optin email itself, but tell them that they won’t be able to log in just yet until their account is activated. It’s all up to you – DAP is as flexible as you need it to be.
So that’s how you would use the Double-Optin feature to indirectly force an “Approval” process.
There are two ways members can buy gift subscriptions for others.
1) Use the recipient’s email id (but their own name and billing info) during checkout. So when DAP creates the member account, it will send the welcome email to the recipient’s email id.
NOTE: Using the recipient’s email id may not be an option if the gift giver is paying for it using their own Paypal standard account, in which case their Paypal email id will be used by DAP to create the membership account. So, the best option is the one explained below.
2) BEST OPTION: Have the buyer make the purchase in their own name, and then forward the welcome email (which has the password to the member’s area) to the recipient. And the recipient can then log in using that information, and can change any and all profile information on the User Profile page.
NOTE: If this is a subscription product, then the recipient should not change the “Paypal Email” field in the profile, which will be having the buyer’s Paypal email id, because recurring subscriptions will continue to come in using the buyer’s Paypal email id. And since the recipient is not the one being charged, and it’s still going to be charged to the gift giver’s account, they need to leave that field in there. So you can use the [DAPUserProfile] shortcode and maybe not even show the “Paypal Email” field.
We do NOT recommend testing what your regular member’s user-experience, while you are logged in as DAP/WP Admin.
Being logged in as DAP Admin and WP admin gives you certain privileges that your regular user/member won’t have. So you may see things that your members won’t be seeing. Or you may not see things that a regular user would normally see.
Either way, you may not be seeing what you’re supposed to see when you mix user testing with admin privileges.
So we recommend that you use two completely different browsers for testing: say, Chrome (or your primary browser) for WP & DAP Admin, and Firefox (or other) for logging in as regular user.
That way, you won’t have to keep logging in and out of DAP and or WP to test as both admin and user.
Keep them both separate.
If you are wondering how can the DAP Admin actually login as a member to see what they’re seeing – a critical feature during initial testing as well as troubleshooting a live site when a member says they’re having trouble accessing certain content, then continue reading.
You can use our “Login As Member” feature, where the DAP Admin would go to http://YourSite.com/dap/loginAs.php.
This page will present 3 form fields:
1) Email id of member you wish to log in as.
2) DAP Admin Email
3) DAP Admin Password
If you do not know what your DAP admin email / password is, you can click on your admin name in DAP Admin -> Users-> Manage page and update your admin password. The DAP Admin password is NOT the same as your WP admin password.
Once DAP verifies that it is indeed the DAP Admin trying to log in as someone else, DAP will log you into the site as that member whose email id you entered in (1) above.
NOTE: The Login As Member (LAM) feature does NOT mean that you can use just one browser to log in as both DAP Admin and regular member. You still need to use two separate browsers – one for DAP admin (like Chrome) another for regular member (Firefox). All LAM does is give you a workaround for logging in as someone else, because starting 4.4.x, the DAP Admin can no longer see what the member’s password is in order to log in as them.
DAP is one of the very few membership platforms that will let affiliates earn commissions on offline payments too.
And in fact, DAP will credit affiliates for not just offline payments, but for any payments that you accepted outside of the payment options listed on your web site.
So, for example, you’re using Paypal and Authorize.net buttons on your site. And someone wants to send you a check (cheque) in the mail, or they want to send you money via Western Union, or wire transfer, or they call you and you accept their credit card information by phone, or any other such offline methods.
In this case, DAP can still give credit to the right affiliate for the sale. Here’s how…
1) Add Manual Transaction
By this time, the user would’ve received their “Welcome Email” from DAP, which will have their login info to log in to your site.
And when they log in, if they have an affiliate cookie set in their browser (which they would, if they had clicked on an affiliate link at some point before they contacted you and asked you about a non-standard, offline payment method), then when they first log in to your member’s area, DAP will pick up the referring affiliate’s id from the affiliate cookie, and give credit to them for the sale.
And when the DAP hourly cron runs at the top of the next hour, that affiliate will be credited with any commissions that you’ve set up for that product.
So you want to use DAP to sell group memberships or sub-accounts.
Eg. 1) A group membership – or multi-user account – that a School/College/Teacher can buy on behalf of their students. It’s either a one-time product, or could be a subscription product. In that case, buyer keeps paying monthly, and when they stop paying, all sub-users (child accounts) get disabled.
Eg. 2) Company A pays $X for up to 20 of its employees to have individual memberships. To begin with, the money is collected in one lump sum and DAP grants 20 memberships. Then each month Company A pays the Corporate/Umbrella/Bulk Membership and DAP gives credit to the individual memberships. If Company A fails to pay, all the “sub” members underneath lose access.
DAP doesn’t directly support sub-memberships or sub-accounts yet. We already have this on our humongous to-do list :-). And we definitely plan on implementing it soon. But for now, here’s a work-around for making this happen. It’s fairly simple, yet it is manual, and cannot be automated yet.
Until we include this feature in DAP and make it automated, there are two ways to look at this.
One: You could say, it’s too much work to remove 20/50 emails when the main buyer cancels. OR…
Two: Since this is a group membership, you are hopefully charging them a good fee for this (if not, then you certainly should!). So you can always hire someone for $5 or $10 per hour on Odesk and have them do the removal of those email id’s. Removing 50 email id’s would take about 20 minutes at most. And you would need to do this only when they cancel, which can happen only once per group membership.
So hope that helps give you some ideas.
Hope this makes sense.