Andy Cook

“Grant Leadin access to” give specific user roles access to the Leadin contact data. So if you have editors, authors, etc that you’d like to let see the contacts in Leadin in the WordPress Dashboard, you can just check off those checkboxes in your settings and they’ll be able to view (and modify) contacts.

If you don’t want a specific user role to be able to view and modify contacts, then just leave those checkboxes unchecked for that role and those logged in users can’t get at your contacts database.

Hope that answers your question and let me know if I need to be more clear.

To publicly document the fix for this ticket, the issue ended up being that the li_tags table wasn’t present in the database.

We fixed the problem by manually creating the table with the default MySQL query:

CREATE TABLE li_tags (
tag_id int(11) unsigned NOT NULL AUTO_INCREMENT,
tag_text varchar(255) NOT NULL,
tag_slug varchar(255) NOT NULL,
tag_form_selectors mediumtext NOT NULL,
tag_synced_lists mediumtext NOT NULL,
tag_order int(11) unsigned NOT NULL,
blog_id int(11) unsigned NOT NULL,
tag_deleted int(1) NOT NULL,
PRIMARY KEY (tag_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Leadin should work with most WordPress form plugins and custom built HTML forms. The only exceptions are forms that are not enclosed in a HTML <form> tag or if the form is loaded through an iFrame. If the form submits through Javascript we can’t detect that it’s a form, or if it’s an iFrame we can’t detect the submission because of cross site security reasons.

Also, does your theme call the wp_footer method anywhere? Leadin uses WordPress’s built in method to enqueue Javascript files into the footer, so if your theme isn’t hooked into that method then the plugin won’t load the tracking code. Usually you’ll see a call in your main theme to get_footer, which includes the footer.php file. Inside of footer.php is where wp_footer() is usually called.

Do you mind shooting me an email with a link to the form that isn’t capturing submissions and I’ll take a deeper look? My email is andy@leadin.com. Cheers!

Hmmm – so this looks like a Mandrill issue… Do you mind reaching out to them to see if they can help you debug what might be causing the HTML email issues?

Sorry I don’t have a better answer for you right now. I did install Mandrill on my local installation and our Leadin.com installation to check this out initially and our emails were sending correctly, so I’m not sure if it’s a glitch with your account.

Thanks for forwarding that over, Scott. So this looks like a bug I thought we solved long again, which is that long emails need to be word wrapped to break long strings so that email clients can parse them.

There’s more detail on the reason here:

http://stackoverflow.com/questions/459281/do-you-use-word-wrapping-within-emails

Do you have access to the Leadin plugin code? If you do, can you modify line 33 temporarily in /wp-content/leadin/inc/class-emailer.php, which looks like:

$body = wordwrap($body, 900, "\r\n");

to 72 characters instead, which will end up looking like:

$body = wordwrap($body, 72, "\r\n");

I want to test whether or not this is a wordwrap issue and our character break limit is too high, but I can’t do it without modifying the file via FTP access to your server and then pointing the Leadin email address to my address to verify if that fixes the issue.

If that’s the culprit, we’ll figure out how to modify the plugin permanently to solve this issue. Thanks!

The only obvious issue I can think of is that you might not have cURL enabled on your server, but Leadin should detect that and disable you from using the MailChimp power-up if that’s the case.

We don’t have a log setup for the API calls, but that’s probably a good idea. Do you mind emailing me your FTP credentials so I can hop on the server and debug if this is a Leadin issue or an error with the MailChimp API. I know it’s suboptimal, but it’s really hard to us to debug issues like this because we don’t have server access by default and everyone’s server stack is different.

I’m pretty sure you have my email already, but just in case it’s andy@leadin.com.

Thanks!

tl;dr – We’re working on redesigning our popups tool and adding some improvements to address these issues among others. I logged all your feedback into our feature backlog, so we have it all for our team to check out when we start development on those improvements.

I responded inline to try to address all the issues:

The form is configured to slide in from the bottom, right. It never appears on Android phones. I am able to reproduce this on my own phone, running Kit Kat and both the Chrome browser and the Android browser. The form does appear on iPads. My WordPress site is running WP 4.1 with an unmodified Twenty Fifteen theme.

Right now the Leadin popup is not configured to run on mobile devices. This is because we got a lot of complaints from our early users around a sub optimal experience on mobile devices using the default responsive design, so in the essence of speed we just disable the mobile popup saying to ourselves “we’ll fix it when we have more time”, but we never have more time so we didn’t get around to it.

People running form-fill-in plugins report that their email address gets filled into all three fields that I have enabled; email address, first name, and last name. This is confusing since there are no labels for what should be in the fields, other than the default text which is gone by the time the form-fill-in plugin does it’s work.

I’ll try to fix this behavior. Do you know what browsers these reports are coming from?

After being confused by the form-fill-in glitch, people dismiss the form and then have no way to return to the form and subscribe.

The form is defaulted to not show for two weeks after the user closes the popup, This was based on early feedback from visitors on sites using Leadin of the popup being annoying and disruptive after the visitor closed it out, indicating that she wasn’t interested in the offer. We do have plans to add in a persistent icon that minimize the popup form, but we need to do the design work to make sure it works across all devices.

Thanks so much for the feedback! Your thoughts help us improve the product and we really do read every email or support thread. We’ll have some solutions to these glitches soon for you – stayed tuned!