Archive

Category Archives for "Troubleshooting"
5

Troubleshooting the Affiliate Program

The reason why your affiliate program may not be working as intended, is almost always because of incorrect setup and/or testing parameters.

Quick Troubleshooting Tips

  • A good clean test was not carried out, allowing the proper cookies to be set
  • You were already logged in as DAP admin, and did not log in correctly as your new buyer
  • You were using the same browser to log in as DAP admin, DAP user, new buyer, etc, thus causing a problem for DAP to set and track the affiliate cookies.
  • Affiliate commissions had not been set up in advance of the purchase
  • You used an existing user in the system (who may or may not have been previously attached to an affiliate) to test, which is incorrect – you must create brand new user.
  • Login Xpress was not setup for the payment integration – which means the buyer has to actually log in to the member’s area in order for the tracking to be completed
  • The hourly Cron job hasn’t run twice yet (which is when the commissions are credited to the affiliate)
  • Resulting affiliate commission is too low to be calculated (eg. when using a test purchase of a 1 penny product)

A Clean Test

  1. Make sure you have set up affiliate commissions for the Product on the “Affiliates > Commissions” page
  2. Delete the email id of the test user – with which you are going to make a purchase – from Users > Manage page.
  3. Log out of DAP admin, WordPress admin, clear your browser cookies, and restart your browser (unless you are going to use a completely different browser where you are not logged in as DAP admin or WordPress admin – double check that anyway).
  4. Click on an affiliate link (that you have previously sent yourself via email). Don’t manually type it in the browser window, lest you make an error in the affiliate id. Make sure you use a valid link.
  5. When you land at your web site, now make a real purchase as a new user. Don’t use email of existing user. If the email you wish to use is already used up by a test user in the system, then be sure to delete that user from your system before making the purchase. This is very critical, because an existing user who is currently not attached to an affiliate, cannot be made to get attached to another affiliate just because you clicked on that affiliate’s link before making a purchase (using existing user).
  6. If you haven’t already set up Login Xpress (where buyers are automatically logged in to member’s area), then you MUST log into the members’ area using the user id that you used to make the purchase (you DO NOT need to log in separately if Login Xpress is setup, because then you would get auto-logged in upon purchase).
  7. Now in a separate browser (like Chrome or Firefox), log in as DAP Admin, go to “Users > Manage” page to make user the new user account has been created, and that there is actually a transaction id listed under the Trans ID column of the user’s row.
  8. There should be one. Click on that transaction id, it will bring you to the transaction details page
  9. Look at the status of the transaction – it should say SUCCESS at this point.
  10. Now wait for the top of the hour, for the DAP hourly cron job to run. When the cron finishes running, refresh the transaction details page. The status of the transaction should have changed to Processed Affiliations Successfully. (If you don’t wish to wait for the top of the hour, you can always run the cron manually by going to http://YourSite.com/dap/dap-cron.php – remember that if you run it manually for this one time, then there will be no way to know if the cron has actually been set up correctly and running on it’s own. But that’s a whole another topic).
  11. Now when you log in as the affiliate in yet another browser, you will find the commissions credited for this buyer’s purchase.

Here are some more troubleshooting steps:

1A) Affiliate was not credited with a sale

There could be many reasons for why the affiliate was not credited to the sale.

a) Buyer didn’t click on any affiliate links before purchasing the product
b) Buyer did click on an affiliate link, but somehow (intentionally – or not) cleared her cookies before buying the product
c) If you haven’t set up Login Xpress, then buyer needs to log in to your membership site – which they probably haven’t done yet (if this is the case, see if DAP supports Login Xpress for your payment processor)
d) The hourly cron job on your DAP site hasn’t run yet (hourly cron has to have run *after* the buyer has logged in to their account)
e) You have not set up any affiliate commissions for the Product on the “Affiliates > Set Commissions” page

 

1B) Affiliate was credited with the “Lead”, but not the “Sale” (no commissions awarded)

Short answer: You’re not using “Login Xpress”. And you probably forgot to initially set up the affiliate commission for the Product in question, under “Affiliates > Commissions“, and only set up the commission record 7 days (or more) after the actual sale happened (the sale for which your affiliate got the “Lead”, but not the “Sale” (and in effect, no commissions). We call this the “7 Day Commission Cutoff Period”. So affiliate will not be awarded the commission. You just have to pay them offline.

Long answer: DAP has two ways of awarding commissions:

a) Using Login-Xpress, where affiliates are attached to buyers instantly after purchase, and when the cron job runs at the top of the next hour, the affiliate commissions are credited to the affiliate’s account.

b) In situations where Login-Xpress is not possible (due to restrictions with the specific payment processor), the affiliate is attached to the buyer only when the buyer actually logs in to your membership site. Believe it or not, not everyone logs in the same day (sometimes not even for a few days after) they’ve purchased your product. So it’s possible that the affiliate/buyer connection is not made by DAP until a couple of days later.

Now consider these scenarios…

Case X: Buyer clicked on affiliate link at work. They purchased the product at work. You don’t have Login-Xpress setup. So only way for affiliate/buyer connection to be made, is when your member logs in to your site for the first time. So they went home that evening, logged in for the first time from home, but there’s no affiliate cookie at home. Normally your affiliate is screwed. But DAP goes the extra mile to be fair to affiliates. If your buyer logs in to your membership site even a couple of days later from work, since the cookie is still on their work computer, the affiliate and buyer are now connected, and affiliate gets credit for the sale.

Case Y: Buyer never clicked on any affiliate link. They bought your product. You did not have Login-Xpress setup. So only way for affiliate/buyer connection to be made, is when your member logs in to your site for the first time. So since they never clicked on any affiliate link, there’s no affiliate cookie. They buy your product, log in to your site, and their account has no affiliate attached to it. Then a couple of days later, they’re surfing the web, and happen to read an article from one of your affiliates, and intentionally or not, click on that affiliate’s link. Now that affiliate’s cookie is stored on their computer. The next time they login, DAP thinks “Ah, this is the same as Case X (above): No affiliate attached already, but now finding affiliate cookie – same as the buy at work/login at home example. So DAP will go ahead and give that affiliate credit for the sale, even though the referral was not made prior to purchase. So to avoid awarding affiliates incorrectly (after the sale), DAP is deliberately programmed to look for transactions only for the last 7 days, every time the DAP hourly cron job runs.

2) Affiliate Program Life Cycle

  1. You have already set up a “Per Sale” commission for the Product being purchased.
  2. Visitor clicks on affiliate link and affiliate cookie is set on her computer
  3. Visitor goes on to buy the product
  4. a) If you HAVE setup Login Xpress, then member is logged right into the members’ area.
    b) If your payment processor does not support (or you HAVE NOT setup) Login Xpress, then buyer gets welcome email and logs in to your member’s area: This is when the affiliate is actually credited with the referral. So it is critical that if you’re testing the affiliate program, make sure you log in to the new member’s account.
  5. So regardless of whether they’re auto-logged in right after purchase, or whether they log in a few minutes after the purchase after they’ve received their log in information via email, the login action takes place at this point.
  6. At the time of this login, the only thing that happens is:
    a) DAP records in the database that this buyer was referred by the affiliate set in the affiliate cookie.
    b) If you have set up any “Per Lead” commission, then this lead commission amount is instantly credited to the affiliate’s account. So if the affiliate were to log in to his account exactly at this second, they would just see that they have gotten the “Per Lead” commission credited to their account. If there is no “Per Lead” commission, then nothing is credited to Affiliate account at this point. So the affiliate would see no “Sale” commissions yet.
  7. At the top of the hour after the buyer has logged in to their member’s area, the DAP Hourly Cron (dap-cron.php) runs. It sees that Buyer X has been referred by Affiliate Y. It also sees that no “Sale” commissions have yet been credited to the affiliate for the purchase. It then looks up the Affiliate Commissions that you have previously set up at “Affiliates > Set Commissions”, calculates the commission to be credited (“Per Sale Fixed” or “Per Sale Percentage”), and then credits affiliate’s account with that amount.
  8. If the affiliate were to log in to his account at this point, they would just see that they have gotten the “Per Sale” commission credited to their account.

3) Affiliate is unable to access the Affiliate-Info page.

So you created an “Affiliate” product, created a free sign-up form, and an affiliate signed up to this product, and is trying to log in and access the page, but is unable to, and is getting the “Sorry, you don’t have access to this product” error.

There could be many reasons for that (main one is #1 below):

a) Anyone who signs up through the “Direct Signup HTML Form” is added as a “Free” user. Which means, they can only access content that has been marked as free. So if you have created an “Affiliate” Product, and have added the affiliate-info page to that product, make sure that page is accessible by free users too, by clicking on the “edit” link next to the page, and on the resulting popup, set “Accessible to
Free users too?” to “Y”.

b) You have not even made the affiliate-info page protected under the “Affiliate” product

 

4) Double Credit of Affiliate Commissions for the same purchase

This is not really a double-credit for the same purchase, even though it appears to be so.

Sometimes you may enter a manual transaction for a purchase around the same time that DAP is processing an automated transaction for that purchase.

That means, there are now two transactions in DAP for the same purchase – one manual, and one automated – which can cause problems in accounting.

That’s usually how you end up crediting double commissions to the affiliate who referred the user, because all affiliate commissions are calculated from sales, and if you have two separate transactions for the same purchase, then the affiliate will get credited twice for the same referral.

So if you see two credits for the affiliate, you must first note that it is not for the same transaction, but for different transactions (note the different Trans Id‘s) on the Affiliates > Reports page.

So be careful when you’re entering Manual transactions. Those are meant only for when there is no way to automate the recording of a purchase (because they paid offline) and you’re unable to bring the transaction into DAP automatically.

If you see two affiliate commission credits (one for the automated transaction that DAP picked up, and one for the Manual transaction that you entered), then just refund the manual transaction in DAP. There will probably be a change to the user’s access because of the refund. So make a note of the current access of the user BEFORE you do the refund, and then AFTER you’ve processed the refund, go back to the User’s details on the Users > Manage page, and manually adjust their access to make sure it’s accurate.

10

Troubleshooting Email Delivery

Sending Email Through Your Web Site: The Basics

DAP is not an email service (like, say, Aweber).

DAP is just a script – a tool – like Microsoft Outlook or Thunderbird – that simply sends out email using your web host’s email server.

It is your web host’s mail server that actually sends out the email to the recipient. So once DAP notifies your mail server about a email that is to be sent, it has absolutely no control over what happens next.

It’s like when you put an envelope with a letter (regular mail) into the mailbox (post box). It is up to the Postal Service to actually pick up your letter, and deliver to the destination address. Your web host is like the Postal Service. If it doesn’t pick up and deliver the (e)mail, then DAP doesn’t have any say in it.

So if the emails that DAP sends out are not getting delivered to your recipients (or landing in the spam/junk folder of the recipient), there could be more than one reason for that.

Improving Email Delivery

DAP uses your web host’s email servers to send out emails.

Here are some ways to improve email deliverability and also avoid your email landing in the recipient’s junk/spam folder.

  • Check with your web host to make sure they have “Reverse DNS” setup and configured correctly for your domain. If not, then this is most likely the cause of emails not getting delivered.
  • Do not use a Gmail or Yahoo or some other web based email as the “From” email id (under DAP Admin > Setup > Config).
  • Instead, use a domain-based email id – like You@Yoursite.com or Support@Yoursite.com – as the “From” email id

If you are on a shared host, you may even consider totally by-passing sending emails through your web host, and instead use DAP’s “SMTP” feature to send emails out through an external email system – like Amazon’s SES (Simple Email Service) , Gmail or AuthSMTP.com.

Welcome Emails Not Going Out

If Admin notifications are going out ok, but the welcome email to the buyer/member is not being delivered, then see Troubleshooting Welcome-Email Delivery

Autoresponder Emails Not Going Out

If yours is a new site setup, then this is usually because the hourly cron-job has not been setup.

However, if the emails were going out fine previously, and suddenly stopped going out, then it usually is because…

  • Something changed on your host that caused the cron to stop working.
  • There is an error in the job queue, because of which DAP is unable to proceed with the remaining non-error emails. This could have happened if you tried to send out a broadcast to a CSV list, and there was an error in one of the emails from the CSV list.
  • You’re trying to use a third party “SMTP” server to send out the emails, and your server is unable to connect to that server because the authentication settings you’ve configured on “Email > SMTP” are incorrect.

Steps to troubleshoot

  1. Make sure that the hourly cron (dap-cron.php) is still running – you need to look at your web hosting control panel for that.
  2. Go to “System > Job Queue” and scroll through any items there, and see if there are any scheduled messages there with the status “Error”. If yes, then click on the “Delete Jobs In Error” link. That will delete any jobs that can’t be processed because of an error in the email id or in the import process. Also be sure to click on “Delete Successful Jobs (till yesterday)” just to clear up old, sent emails.
  3. Also go to “System > Logs” and empty the logs.
  4. Go to “System > Config” and set “DAP Log Level” to “5”. That will start logging all the details you/we may need for troubleshooting.
  5. Wait for the top of the next hour and then re-visit the queue and see if emails are going out.
  6. If they still aren’t going out, go back to “System > Logs”, copy paste all text there, and open a new ticket with that info, of course, also giving us more details about the problem, what you have tried, etc, along with your login info for: FTP, WP Admin, DAP Admin, and Web Host Control Panel.

Server Blacklisting

If your inexpensive (read as cheap 🙂 shared web host is hosting a large number of sites on one server, and one of them knowingly sends out spam (or mistakenly gets flagged for spam), that will put the email deliverability of every web site on that server in jeopardy, because your site now shares the same IP address as that of an “alleged” spammer.

So your emails get sent to junk/spam folder by Gmail and Yahoo. Or worse, they just totally disappear into the ether.

Hourly Email-Sending Limits

Almost all shared hosts have hourly email sending limits. For example, DreamHost has an outgoing limit of 300 emails per hour. Which means, a total of only 300 emails can be sent out per hour through any web site hosted on DreamHost. All of the following count towards the 300 limit:

  • Emails sent by any scripts on your site – like DAP
  • Your WordPress blog notification emails
  • Your WordPress admin emails,
  • WP forgot password emails,
  • WP comment notification emails,
  • Forum notification emails,
  • Forum emails sent to each other by your users,
  • Forum-software Admin notification emails,
  • Support software user and admin notification emails
  • Tell-a-friend emails
  • Viral-inviter type emails
  • Emails sent through Outlook or Thunderbird where you have set the outgoing SMTP server to be your web site’s SMTP server
  • Emails sent by others using the same SMTP server to send out emails-  like your business partners, employees, etc
  • DAP User welcome emails, Payment notification emails, Forgot password emails, Autoresponder emails, Broadcast emails, etc

So do you see how quickly you can go over that hourly limit of 300 emails per hour?

But here comes the worst part…

Once you go over that limit, any emails that are actually sent by you or the scripts running on your site, will not actually result in any kind of error. The mail server will respond by saying that the email(s) has been sent successfully, but in reality, on the backend, it quietly “snuffs out” the email. Which means, it doesn’t go anywhere – just gets sent to a “blackhole”. So you keep thinking that you sent out the email. DAP keeps thinking it has sent out the email. But in reality, the emails never actually get sent.

This is the same as you actually putting your letter into the mailbox at the Post Office. But then, imagine this: The postal worker who comes to pick up your mail, quietly goes to the back of the post office and dumps it all into one giant trash can, and destroys all of the mail. So you’re thinking you actually mailed out that important check to pay your utility bill. But the utility company never gets your check, and they slam you with a late fee.

Possible Solutions

1) BEST OPTION: DAP + 3rd party SMTP service provider like Amazon SES, AuthSMTP.com or SMTP.com. (much less expensive than Aweber, and very reliable too)

2) DAP + Aweber (more expensive, very reliable)

3) DAP + Good web host (cheapest option, but can lead to mixed results – depends on your host).

You could always use DAP and external SMTP service provider like Amazon SES, AuthSMTP.com or SMTP.com to send out bulk mail through DAP while totally bypassing your web host’s email system. This is probably the first best option where DAP controls the composition and sending of the email, the 3rd party service controls the deliverability.

Next best option is using a service like Aweber or GetResponse.

And if you can’t afford even that, then simply use DAP on a good web host. We ourselves use just DAP and LiquidWeb’s email servers to send out emails to all of our users.

And DAP also has built-in job queues to schedule outgoing emails while also making sure that you don’t exceed your web host’s hourly email sending limits (dreamhost’s limit is 300 emails/hour, I think). We use multiple SMTP servers from our own other web sites, all combined to be able to send a few thousand emails per hour.

But even with a lot of planning, it is easy to go over the hourly limit.

So the next time you see in your Job Queue that emails were sent out successfully, but the recipient never received it, here are some things to check:

1) It landed in your recipient’s junk/spam folder. Ask them to whitelist or add your email address to their contacts list.

2) You have overshot the limit, so you would have to actually send out the email again.

3) Try to send out broadcasts during a low-traffic time – say like later in the night – when you’re not actively sending out emails, and using up precious email counts from that hourly quota.

http://DigitalAccessPass.com/documentation/?page=/doc/troubleshooting-email-delivery/

1

Troubleshooting 1ShoppingCart Integration

There are a few different reasons why this may not be working.

1. Check if Cron is running

The DAP email-processing cron that processes the 1SC emails may not be running. Check your webhost control panel -> Cron job settings. Make sure dap-emailorder.php is setup to run once every 10 minutes.

2. Incorrect Setup of Billing Email Id

The billing email id you have entered in DAP at Setup > Config > Payment Processing , should be entered into the “Order Notice Email – Primary Destination” field in your 1SiteAutomation/1Shoppingcart account, on the Setup > Orders > Notifications section. If by chance you enter it into the “Order Notice Email – Primary Destination” field, it WILL NOT WORK.

3. No Notification Emails from 1SC

The DAP cron is running but 1SC payment notification emails are not reaching your mail server. Check the email account where you expect to receive your 1SC payment notification emails and see if the order notification email from 1SC is in that mail box.

4. Incorrect Mail Server Settings

The cron is running and the 1SC order notification email is reaching your mail server – but you did not configure the mail server settings correctly in DAP Dashboard -> Setup -> Config -> Payment Processing.

Email Server Where Order Emails Come In
Email Server User Name
Email Server Password

5.”Read” Or Deleted Emails

DAP only processes order notification emails that are in the “Unread” status, to prevent previously processed emails and other non-DAP emails from being repeatedly processed.

Also, if you “pop” off the emails from that mail box (means, your email client like Outlook or Thunderbird or Gmail is “removing” your emails from the server when it retrieves them), it means that when DAP logs in to that billing email address, there are no emails there to be processed – the mailbox is empty, or the 1SC payment notification emails have somehow gotten deleted from that mailbox.

So it is possible that DAP is able to connect to your email server, but DAP is not finding any “unread” emails. Please login to your email server and mark all the payment emails that you want DAP to process… as “unread”. And also make sure that your email client does not remove the emails from that mail box.

6.Product Name Mismatch

There might be a “Product Name” mismatch. The product name has to be EXACTLY the same (including case, spaces, etc) in both DAP as well as in 1ShoppingCart. So if you have created a product by name “Widget A”, make sure your 1shoppingcart product also has the exact same name “Widget A”.

If everything is setup correctly, DAP cron will run every 10 minutes and try to process all 1SC emails.

The next time the DAP cron will run (every 10 minutes), it will pick up all the unread payment emails from 1SC.

7. Empty “Thankyou-Email Body/Subject”

Welcome email is not getting sent.

Select the product, and make sure there is some text in the “Thankyou-Email Subject” and “Thankyou-Email Body”. Whatever is in these fields is what gets sent immediately after someone purchases that product (or right after you give them access from the backend).

Now go to DAP Dashboard -> Users -> Add .

Select the product and manually add user. Now see if the thankyou email gets sent to that email id. If it got sent, then your product setup is correct.

Also check the DAP Dashboard -> Orders . Search for all orders, look up the order for the particular user in question by email.

Check the payment status and make sure there is no error there.

If you did all this and things are still not working, please do this:

1. Set DAP Dashboard > setup -> Config -> Log Level -> Log All activity
2. Re-run the 1SC test purchase
3. Check the DAP Logs (DAP Dashboard > System > Logs) and send us the log text in there for troubleshooting by pasting it into a new support ticket.

8. Sending Email & Password To Buyer

Make sure you have set the thank-you message with the right merge tags for Email and Password.

9. Manually Running Cron

First set DAP Dashboard > setup -> Config -> Log Level -> Log All activity

If you feel that the orders were not processed in dap, then just login to the 1SC email account where the sales/payment notification emails are sitting, and mark those orders/emails as UNREAD that you want dap to process.

Then manually run the cron script dap-emailorder.php cron by visiting the following link in the browser.

http://www.yoursite.com/dap/dap-emailorder.php

Replace yoursite.com with the name of your site.

It will just display an empty screen when complete.

Then check “Users > Manage” to see if user has been created.

Veena Prashanth

4

Troubleshooting Content Access

User Can’t Access Content

By far, this is the most frequently asked support question. So let’s start by addressing that real quick…

If a User can’t access a piece of content (blog Post, Page, File, etc), then there are only a very few reasons for that…

  1. User doesn’t have any access to the DAP Product (where the content in question is protected as part of).
  2. User is a FREE user having FREE access to this specific Product, but the content within the Product itself has been marked as being available to PAID users ONLY.
  3. User does have access, but access has expired
  4. User account status is Inactive because they’ve not yet double-opted in
  5. User account status is Locked (because they reached the IP login limit, and got locked out of their account)

In all cases, the main place to start troubleshooting is with the Users > Manage page. Search for the user’s email id (who is reporting or experiencing the content-access issue). See what Products they have access to, check their Access Start & End dates, check their account status, etc.

So let’s go over some of the basics, and some more detailed solutions for such issues.

Important Basics

Use two different browsers for testing. Not two different browser tabs, but 2 completely different browsers – like Chrome and FireFox, or FireFox and Internet Explorer. Log in as DAP admin using one browser, and then as a regular user in another browser. That way, you keep the access separate, and your testing will be clean and easy.

If you are using, say, Firefox, you are logged in to DAP admin, and are browsing your blog or trying to access content on your blog, then you will only have access to the content that the admin user has access to. You, as the DAP Admin, DO NOT have automatic access to every product by default. You will have to manually give yourself access to every product you create. And if you want yourself to have “PAID” access, then you have to mark yourself as “PAID”.

That is because, if DAP gave you automatic access to all products, then you will go ahead and protect a blog post, try to access that blog post, and DAP will give you access to that content because you as admin have automatic access to the product. And then you will wonder “Hey, I protected a blog post, but I’m still seeing it.

It’s Probably Not DAP

We realize that your first gut reaction is to blame DAP :-). That’s what we would’ve done too, if we hadn’t developed DAP.

But please note that whatever issue it is, you can be 99% sure that it’s not a bug. Because access-related bugs are extremely rare. We also do a lot of pre-release testing, then we release a beta version, then we get hundreds, if not thousands of people to try the beta, iron out the issues, and then release the final version to everyone else. So if there were a bug, it would’ve been caught a long time before it gets to you.

So we request you to approach things with an open mind, and try to think through calmly (and logically 🙂 why a certain user does not have access to a certain piece of content.

Now, on to more specific issues and specific answers…

1) I have protected a blog post as part of a Product. But I can still access it.

Short Answer: If you have protected a post/page/file, try to access it, and are able to do it, then it means you DO have access to it. Now let’s troubleshoot so that you understand the “how” and the “why”.

  • Have you protected the page/post by adding it to a Product? If you don’t add it to a DAP Product, the post/page/file won’t be protected.
  • Who are you logged in as? As DAP Admin? Or as a regular member?
  • Now by logging in as DAP Admin, if you search for this logged-in user by email id or last name on the “Users > Manage” page, you will see that the user probably does have access to the product to which the post belongs
  • Are you already logged in a a user who has access to that link?
  • Maybe logged in as DAP Admin, who maybe already has access to the Product, which is why you are able to access the link? If so, either log out of DAP, or visit your blog in a completely new browser (if you’re logged in as DAP Admin in FireFox, then visit your blog using Internet Explorer).

2) I have protected a blog post as part of a Product. The User’s account shows as having access to it when I look him up in the DAP Dashboard, but the actual user cannot access it in their browser.

Short Answer: If you have protected a post/page/file, try to access it, and are able to do it, then it means you DO NOT have access to it. Now let’s troubleshoot so that you understand the “how” and the “why”.

  • Who are you logged in as? As DAP Admin? Or as a regular member?
  • Whoever you are logged in as, make sure that user (admin user or regular user) has access to the product to which the post belongs
  • Have you added the post as a “PAID” or as “FREE”?
  • If you have marked the post as “PAID”, make sure the user also is a “PAID” user (either there must have been a real transaction, or you must have manually marked him as “PAID”). Because free users cannot access content that has been marked as “PAID”.
  • Maybe the user’s access to the product has expired. Check the user’s “Access Start Date” and “Access End Date” for that product. The start date should be current (not be in the future) and the end date should be current (shouldn’t be in the past, which means his access to the product has expired)

3) Free user can’t see protected content

You’ve created a free product with pages or posts that are only accessible to this membership type. The problem is that the users can’t actually access this content.

1. Log into your DAP system and go to the Products/Levels > Manage page.
2. Select your product in the General Settings tab, then click the ContentResponder tab.
3. In the Content Responder tab, you’ll see “edit” hyperlinks beside each of the pages/posts you’ve protected. Click the one for the page that’s causing the problems.
4. The “Drip Settings” popup will open now. In that popup, set “Is Free? (i.e., Accessible toFree users too?” to “YES”.
5. Click Save/Update resource.

4) I don’t want the links to all my protected blog posts showing up on my blog’s home page

Make sure you have “Sneak-Peek” turned off in the DAP Admin Config section. Once you do that, posts that are protected will not be displayed on the home page as well as if someone tried to visit the link directly.

5) Why do I see the “Lock” symbol on my blog’s home page?

It’s possible that you have no published posts (it’s a new blog), or you have probably protected all of the posts by adding them all to a DAP Product.

6) I have protected a blog post, but the entire blog post shows up, with the lock image at the very bottom

This is probably because you have turned on “Sneak-Peek”, but have not inserted the “More” tag into the post/page in question.

  • Do you want a part of the protected content (like a “snippet”) to show even for users who are not eligible to access the post or page? If yes, then go to “Setup > Config > Advanced > WordPress Sneak Peek: Show snippets of post (upto the `More` break) even for protected posts?” and change the setting to “Y”, and save.
  • If you turn on Sneak-Peek, then you *must* insert the WordPress “More” tag into every single blog post and page that you currently have protected.

So for the above issue, do one of the following…

1) Turn Sneak-Peek to off (set it to “N”)

– OR-

2) Insert the WordPress “More” tag into the post/page.

Doing either one should resolve this issue.

7) Members getting locked out because access end date is in the past

The only time a member’s access end date goes into the past, if their recurring payments are no longer coming in.

Which means, either they have canceled (or gotten a refund), or your membership level’s lifecycle has ended (like, if your Product/Level was a micro-continuity subscription program that lasts only for 6 months).

If the payments are still coming in, their end dates should keep getting extended by DAP automatically.

If payments are coming in, but the dates are not getting extended, then the payment link between DAP and your Payment Processor somehow broke, and you need to visit the Payment Processor integration documentation for your specific payment processor, and troubleshoot why the payments are coming in fine, but DAP is not processing them.

To ensure members’ access does not stop, make sure that their payments do not stop, and the recurring cycles in the product match that of your payment processor. Say, if your payment processor is processing recurring payments every 30 days, then DAP’s recurring cycles (on the Product page) should also be 30. If it’s 31, then DAP’s should also be 31.

Tip: It’s not a bad idea to set DAP’s recurring cycle day to 1 more than your payment processor’s recurring cycle, just in case your payment processor takes an extra day to process the actual payments. So in that case, if you have set your Payment processor to charge every 30 days, you could set DAP’s recurring cycle to 31 (one extra day grace period, just in case the recurring payment does not get processed on time).

8) I have newly setup DAP. Protected a blog post as part of a Product. But I can still access it, and I am not logged in.

If this is a new site that has just setup DAP, it is possible that the DAP changes that need to go into your .htaccess file at the main folder of your blog in question, didn’t go in correctly.

  • Step AA: Open the .htaccess file at the root of your blog, then see if there’s text that looks like this:
    #—– START DAP —–
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !(.*)(\.php|\.css|\.js|\.jpg|\.gif|\.png|\.txt)$
    RewriteCond %{REQUEST_FILENAME} (.*)/wp-content/uploads/(.*)
    RewriteRule (.*) /dap/client/website/dapclient.php?dapref=%{REQUEST_URI}&plug=wp&%{QUERY_STRING}  [L] #—– END DAP —–If you see it, then simply open a ticket, and we’ll troubleshoot.
  • Step BB: If you don’t see it, then log in as WP Admin, go to “Settings > Permalinks”. Then pick a permalink structure OTHER than “default”. Then save the setting. Even if something other than “default” is already picked, simply hit the save button anyway. That’s when the .htaccess gets updated. Now go to Step AA above and verify the text in the .htaccess file. If it’s still not there, just open a ticket.

9) After a member logs in, they’re unable to view the member page – they get a “Sorry, cannot access” type error.

Some questions to ask that will hopefully lead you to the answer…

  • Did you log in as them in a fresh browser and was your experience the same problem? Or is it a user-error on their behalf?
  • What product did they purchase?
  • Do they have valid “non-expired” access to the product?
  • What is the “Logged-In URL” field of that Product in DAP? Is that the right URL to which they should be going to after they log in?
  • If so, then is the “Logged-In URL” page or post actually protected as part of that same product that they actually purchased?
  • If that field is empty, what is the value of the global setting under “Setup > Config > URL to which user is redirected to, right after log in” field?
  • What is the actual URL that they’re “Supposed” to see after they login? If you went there directly, what do you see?

 

NOTES

1)  DAP Admin does not have access to content by default. You need to give access to the DAP admin to the products in the DAP Manage Users Page.

2)  If a user reports they cannot access content, it could be because their access has expired. So…

a) Login as DAP Admin, go to DAP Users > Manage page, search for user by email id (or other).

b) Make sure they have “valid” access to the product

c) Look at their access start and end dates. If access end date is earlier than the current date then you can manually extend access for legitimate users by clicking on the ‘Modify link’ under ‘Product Access’ in DAP manage users page.

d) Make sure that if it’s a PAID USER, then the user record is marked as ‘Paid or has a transaction Id’ under the ‘Trans Id’ column in DAP manage users page.

Users marked as “FREE” can only access content that is marked as “Free” in the DAP products page -> Content Protection area.

6

Plugin Errors

(1) When Activating LiveLinks

If you are seeing an error that looks like this when you try to activate LiveLinks…

Fatal error: Cannot redeclare dap_filter_posts() (previously declared in /home/sitename/public_html/wp-content/plugins/DAP-WP-LiveLinks/DAP-WP-LiveLinks.php:11) in /home/sitename/public_html/wp-content/plugins/DAP-WP-LiveLinks/DAP-WP-LiveLinks.php on line 11

First click on the DigitalAccessPass link on the left side bar of your WP admin panel and see if you able to login to the DAP Admin Panel successfully.

If yes, then  you can ignore this error. If not, try out these solutions one-at-a-time.

Solution A) This could be because you have incorrectly named the DAP or Livelinks folders.

Remember, the dap folder must always be named dap (all lower case – and not, say, dap_v4.3). And the livelinks folder must be named DAP-WP-LiveLinks .

Solution B) Make sure you have installed dap to the root of your site/domain. If you installed it right, you will be able to access this URL:

http://yoursite.com/dap/phpinfo.php

Note: Replace yoursite.com with the name of your site.

Now go back to WP admin panel -> plugins  and de-activate and re-activate the DAP-WP-LiveLinks plugin.

Solution C) Go to /dap folder on your site

Rename dap-config.php to dap-config.old.php

Now go back to WP Admin -> Plugins -> de-activate and re-activate DAP live links plugin.

Solution D) Go to WP admin panel -> plugins

Try to de-activate all active plugins. Just activate DAP-WP-LiveLinks first. See if it works. Then re-activate all other plugins one-at-a-time to find out if there is a plugin conflict.

Solution E) Go to WP admin panel -> Appearance -> Theme

Try to de-activate the currently active theme and use the WP default theme. Now go back to WP admin -> plugins and de-activate and re-activate DAP Live Links plugin and see if that resolves the issue. If yes, it points to a theme issue and you might have to consider switching the theme or contact the theme developer for a possible fix.

Solution F) This applies to DAP installation on a sub-domain or add-on domain.

If you are installing DAP on a sub-domain or an add-on domain, then this problem is likely because the path to the root of your site does NOT match the server document_root.

Here’s how you can figure out the siteroot and document root.

Run this command in a browser window:

http://yoursite.com/dap/getpath.php and note down the path. That’s the path to the root of your site.

Run this command in a browser window:

http://yoursite.com/dap/phpinfo.php and search for document_root. Note down the path. That’s the path to the document root of your site.

NOTE: replace yoursite.com above with the name of your site.

If the only difference is that the first one (getpath.php) has a /dap at the end, then it’s fine. But if getpath.php results in a different path than the one returned by phpinfo.php, then you will have to update wp-config.php with a new siteroot definition using the value returned by getpath.php.

Copy the results of getpath upto /dap as shown below and add it to wp-config.php.

For ex – if getpath.php returns – /home/yoursite/yoursite.com/dap, then this will be what goes into wp-config.php

if ( !defined(‘SITEROOT’) )

define(‘SITEROOT’, ‘/home/yoursite/yoursite.com’);

Please Note :

Replace backticks (‘) above with single quotes in the define statement. When this document is updated, wordpress replaces single quote with backticks, but if you copy and paste the define statement above directly from this document to your wordpress config file, remember to change backticks back to single quote.

Now try to re-activate dap live links plugin.

If it succeeds and installs DAP successfully, then go back to /dap folder on your site. You will now see a new file called dap-config.php. Edit the dap-config.php file.

Add the same line to dap-config.php also.

if ( !defined(‘SITEROOT’) )

define(‘SITEROOT’, ‘/home/yoursite/yoursite.com’);

That’s it. You will not see any of these warning/errors after that.

NOTE: here ‘/home/yoursite/yoursite.com’ is just a sample, you need to use the path returned by http://yoursite.com/dap/getpath.php on your site.

Solution G) It is possible that your web site does not meet the minimum requirements to run DAP .

If you open a ticket and give us your FTP info and your WordPress Admin login info, we can confirm this to you right away.

— *** —

If you are seeing an error that looks like this when you try to activate LiveLinks…

Oops! Could not create the config file (dap-config.php). Please make the ‘dap’ folder writable by doing CHMOD 755 (and if that doesn’t work, then try CHMOD 777.)

Installation failed. Please de-activate LiveLinks and re-activate it when you’ve fixed the issue. (106)

* CHMOD just the dap directory to 777.

* Then de-activate and activate the LiveLinks plugin.

* This time around, it should be able create the dap-config.php file within the dap directory. You should see the successful installation message.

* CHMOD just the dap directory back to 755.

If that doesn’t work, then open a ticket with the FTP info and WP admin info.

————————————————————

(2) Session Error

If you see an error that looks like this…

Fatal error: Dap_Session::isLoggedIn() [dap-session.isloggedin]: The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition “Dap_Session” of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in /home/site/public_html/dap/inc/classes/Dap_Session.class.php on line 41

This is basically caused by someone else’s 3rd-party WordPress plugin that is wiping out the “session” data (or user data stored in memory) which DAP relies on to store the user information. So there are two things you can try…

  1. See if you have a plugin by name “WordPress Automattic Upgrade” in your wordpress plugins page.This has created many issues for so many other plugins too, including LiveLinks. Just de-activate this plugin, and your error should go away. Also, if you are using WordPress version 2.7.1, you don’t really need this plugin any more – the automatic upgrade feature has been built right into this version.
  2. See if you have a plugin for doing “Captcha” – this is where to prevent bots from spamming your comments, your visitor is presented with some kind of an image to verify that they are human. Try with that de-activated.
  3. If none of the above worked, or if you don’t have any of the above plugins active and you’re still seeing the error, then just try de-activating all other plugins temporarily (except LiveLinks, of course), and turn them back on one-by-one.

Refresh your blog page every time you activate a plugin. That way, you will know which is the plugin that is causing the error.

If that still doesn’t help, just open a support ticket and we’ll take care of it.

————————————————————

(3) PDO Error

You see an error like this:

Fatal error: Class ‘PDO’ not found in /home1/knowlee3/public_html/buildamagneticnetwork/dap/inc/classes/Dap_Connection.class.php on line 19

If DAP had been working fine on your web site, and you all of a sudden see this error, then your host quietly pulled the rug from under your feet :-). This appears because they either deliberately or mistakenly disabled the “PDO” library, which is a must-have requirement for DAP to run.

So check with your host and ask them “if they disabled PHP/PDO for MySQL on your server recently”.

————————————————————

(4) Memory Allocation

You see an error like this:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 16 bytes) in /home/yoursite.com/public_html/dap/inc/classes/Dap_Connection.class.php on line 19

Or you see a blank screen after activating DAP LiveLinks.

a) Your server has a low memory limit set by your host, and your host needs to increase the memory allocated to PHP/PDO.

Add this line to the top of your wp-config.php file:

ini_set('memory_limit', '64M');

OR…

b) Sometimes, this is not really related to memory at all, even though the message appears to indicate so. Instead, the issue could be that the database connection parameters in /dap/dap-config.php file are invalid/incorrect. And that manifests itself appearing to be a memory issue.

So, maybe you recently made some changes to your DAP files or web site files, and overwrote/updated your dap-config.php file with the wrong database information. For whatever reason, it’s possible that DAP is unable to connect to the database because of incorrect information in the dap config file. Check the database settings within your dap-config.php file and make sure it matches your wp-config.php file.

————————————————————

(5) Simple-Pie & Memory Allocation

You see an error like this:

Fatal error: Allowed memory size of 37423432 bytes exhausted (tried to allocate 371520 bytes) in /…/public_html/~username/wp-includes/class-simplepie.php

Open the file wp-config.php (which is in your blog’s main folder)

Add this line at the top…

define('WP_MEMORY_LIMIT', '64M');

That should take care of the error.

————————————————————

(6) Data Inserting/Saving/Updating Issues

  • You get a 403/404 error when updating things, or data doesn’t get saved and nothing gets updated, when (for eg.) you try to save the DAP license key in Setup > Config
  • Same kind of issues when trying to update Product settings or Product page doesn’t even load and comes up blank, or
  • You try saving something in DAP and it doesn’t get saved
  • Clicking on double-optin activation link (after going through DAP free signup) ends up in a “Sorry, missing fields” type of message and takes you to the link http://YourSite.com/dap/error.php?msg=MSG_MANDATORY
  • You get random blank pages in DAP Admin
  • You randomly get the “License Error” page even when you’ve actually entered the license key and all pages work most of the time.
  • You were simply sent here by the DAP support team because they suspect it’s this issue (even if you don’t have the same issues listed above)

Weird, inexplicable, illogical stuff happening: This is the typical symptom of something called “Mod Security” being installed on your host, that is preventing DAP from accessing the database.

So please open a ticket with your host, and tell them this…

“I have a WordPress plugin on my site that is showing unexpected behavior and database errors when I try to save any data. The developers tell me that there is probably Mod Security installed on the server where mysite.com is hosted. So ideally, please disable it, in case it is enabled. Or at the very least, please white-list all requests coming from yoursite.com/dap/ so that the plugin is able to do its job.”

Once they fix that, then try whatever was not working before, and this time, it should work fine.

————————————————————

(7) Installation Errors With DAP v4.4.x

a) After installing (or upgrading to) DAP v4.4, your site doesn’t load properly.

b) Or you get a an error that looks like the one below and your WP admin doesn’t load, won’t let you log in, or shows a blank screen.

Fatal error: Call to undefined function mcrypt_decrypt() in /home/XYZ/public_html/yoursite.com/dap/inc/functions_admin.php on line 3839

This means that your server is missing a standard PHP library – usually installed on most web servers – called “mcrypt_decrypt” that is used by the new DAP v4.4 for encrypting users’ passwords. Please ask your web host to enable that library, and after that, if you activate the DAP LiveLinks plugin in WordPress, it should work fine.

If your site is not loading, then temporarily rename the wp-content/plugins/DAP-WP-LiveLinks plugin’s folder name (add an underscore at the beginning or the end) so that your site can load.

————————————————————

(8) PHP Notice: Undefined index

You are seeing errors like this on your site…

PHP Notice: Undefined index: HTTP_HOST in /var/www/my/site/httpdocs/dap/dap-settings.php on line 108
PHP Notice: Undefined index: HTTP_HOST in /var/www/my/site/httpdocs/dap/dap-settings.php on line 110
PHP Strict Standards: Only variables should be passed by reference in /var/www/my/site/httpdocs/dap/inc/classes/Dap_User.class.php on line 272

It’s probably because the PHP error reporting has been set to “Strict” on your server.

Just paste the following line of code towards the top of the dap/dap-config.php file, right after the PHP opening tag (“<?php”)

error_reporting(0);

That should resolve this issue.

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home8/paladinc/public_html/equityarb/wp-includes/class-simplepie.php