Many issues

Hi, thanks for the feedback! We will review each and decide on implementing fixes or improvements.

Hi, we have implemented fixes for your items 1 and 3 (which will be available within the next couple days). For item 2, we already provide a unique DOM ID for the Ajax message:

https://d226aj4ao1t61q.cloudfront.net/lkfixe4w_screenshot2015-06-17at10.13.51am.png

Is that enough for what you need to do?

For item 4, I am not sure how we would allow custom response messages. We hard-code “Contact added” and “Contact updated” in our API response (as well as any error messages). The only option I can think of is to update the plugin code to override this message.

Regarding item 5, I haven’t seen this error yet. Can you provide an example of what the error is, and how we can replicate it (I have a local install of WordPress). Then we can fix that also.

Thanks!

Item 2, a class for success vs error messages, isn’t solved by just an id on the div. Developers can style the div, yes, but we are not able to follow common patterns like making the div green on success or red on failure.

Item 4, vague messages, put yourself in the shoes of someone signing up via the form, “Contact added” is pretty robotic. The website owner may want to make that more user friendly, eg “Thank’s for signing up, please check your email to confirm your subscription.” There’s also the issue of languages other than English.

Item 5, inline JS. Add this code to your functions.php file for your theme:

function move_jquery_to_footer() {

	// trash jQuery, add it back, enqueue it
	wp_deregister_script( 'jquery' );
	wp_register_script('jquery', '/wp-includes/js/jquery/jquery.js', false, '1.11.0', true );
	wp_enqueue_script( 'jquery' );
}
add_action( 'wp_enqueue_scripts', 'move_jquery_to_footer', 100 );

This moves jQuery to the footer. Any plugins, themes, etc that declare a dependencies on jQuery will automatically be loaded after jQuery is loaded, meaning they will also be moved to the footer.

For inline js like what’s in your plugin, it may be better to not use wp_enqueue_scripts to load your js, but use wp_footer with a very late priority like 99999. Right now you just output the js with the form, which is why an error happens.

Item 2 will be fixed/improved. I have added either “form_result_success” or “form_result_error” class names to that div based on the Ajax response code.

Item 4: I don’t see an easy/quick way to improve this without having to build a new plugin feature that allows admin users to set custom response messages. For example, on success you could type in the value you want to have displayed. Same for error. As the messages are just generic responses from our API, they were not really meant to be displayed to a public user, but instead the developer using our API should read the response and display a custom message accordingly. We just haven’t built-out our WordPress plugin far enough to allow that yet. I love the idea and will add it to our development queue.

Regarding translations, I agree that needs to be improved also. The API responses (that are currently displayed) are translated based on the ActiveCampaign user settings (within ActiveCampaign). But I don’t see why we can’t translate the response (again?) within WordPress before displaying/returning it to the UI. Something we can test and consider.

Item 5: I see the error now after applying your code into my theme file: jQuery is not defined. We do, in fact, output the JavaScript when the form is embedded onto the page (it’s actually saved with the form HTML code when we cache it into the WordPress database). I am open to suggestions on how to improve this. My question: is this something common that users do in WordPress (moving jQuery to the footer with custom theme code)? Just wondering how many users would actually need a fix for this, or if it’s something that only power-users know how to do.

Item 4 About translations. It really depends upon your user base and they languages they speak. It’s quite common for plugin developers to allow for translations within their plugin through WP’s built in i18n functions. Personally, I wouldn’t start down that path until users needed it.

As for something that will allow users to easily change their confirmation/error messages, that is pretty common.

Item 5 I honestly don’t know how many developers move jQuery to the footer. Most likely it’s more common with custom themes rather than off-the-shelf ones.

My recommendation would be to store the html and js in different fields, then use wp_footer to put the js into the footer at the very end.

About the API vs the WP plugin. The plugin allows non-developers to put your forms into their pages, along with do some configuration, without needing a developer to do it for them. It works, it just has minor issues that only developers would find.