The reason why your affiliate program may not be working as intended, is almost always because of incorrect setup and/or testing parameters.
Here are some more troubleshooting steps:
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
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.
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
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.
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.
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.
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.
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
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…
Steps to troubleshoot
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.
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:
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.
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.
There are a few different reasons why this may not be working.
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.
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.
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.
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
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.
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.
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.
Make sure you have set the thank-you message with the right merge tags for Email and Password.
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.
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
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…
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.
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.
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…
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”.
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”.
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.
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.
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.
This is probably because you have turned on “Sneak-Peek”, but have not inserted the “More” tag into the post/page in question.
So for the above issue, do one of the following…
1) Turn Sneak-Peek to off (set it to “N”)
2) Insert the WordPress “More” tag into the post/page.
Doing either one should resolve this issue.
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).
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.
Some questions to ask that will hopefully lead you to the answer…
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.
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:
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’) )
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’) )
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.
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…
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.
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”.
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:
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.
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…
That should take care of the error.
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.
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.
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”)
That should resolve this issue.