Jan Martin

Thank you Takayuki,

for your quick reply! Very much appreciated.

Yes, you are right, and as I mentioned, using the HTML above works just fine with regards to MailChimp by putting the HTML directly into the Form tab field.

But it does not work with regards to CF7, because when using HTML, the checkboxes does not show up as mail-tags in the Mail tab field and they can not be included in the CF7 form that will be sent as mail. Usually, checkboxes included as CF7-tags will be accessible as mail-tags in the Mail tab field.

As it is now, when I receive an email from CF7, I will have to log into MailChimp to see what checkboxes the user checked.

A funny thing is that Flamingo is able to grab the checkboxes from the HTML code, and I can see which checkboxes that have been checked in Flamingo. So I wonder why CF7 can’t grab them and present them as mail-tags in the Mail tab field, so that I can include them in the mail sent by CF7?

Another issue with using HTML instead of CF7-tags, is that the CF7 form gets really long and messy, when you include several checkboxes using HTML as you will have to wrap them in all the HTML and CSS that CF7 otherwise so neatly does automatically (I have 9 separate checkboxes that CF7 will create 117 lines of HTML for). If it would be possible to use brackets like this, within the CF7-tag, then several separate checkboxes could very neatly be included in the CF7-form (9 checkboxes would just be 9 lines of CF7-tags).

So any way of supporting this with CF7-tags or is it something that could be available in the near future?

Thank you very much for your great plugin and great support,

Jan Martin

Dear Renzo,

I would love to start using your plugin!
However, I am using groups, so I currently have to use another plugin.

So, I really look forward to group support in your plugin.

Keep up the good work!

Jan Martin

Nice work ffitalia!

For anyone else who wants to implement this, there are two small things to note, in order to get the above to work:

D) When you copy the code on line 206-335 into the file my_slide_widget.php, make sure to enclose those code lines with opening and closing tags, i.e. <?php and ?> as such:

<?php
Here you paste line 206-335.
?>

E) There is a missing closing tag in the row with wp_dropdown_categories, i.e. that row should be:

<?php wp_dropdown_categories(array('taxonomy'=> 'post_tag','hide_empty' => 0, 'name' => $this->get_field_name( 'category' ) , 'selected' => $category )); ?>

Cheers

My pleasure and very much appreciate your efforts, support, plugin and future roadmap! Wish you and your team all the best for 2016! Cheers

Hi Evan,

Thanks, I just noticed that you signed up to the list.

I tried to replicate the error again, just like I described for you, but now I am not getting the “We received an unexpected error: null”.

It is strange. I haven’t done much changes since my last message to you 2 weeks ago, except upgrading your plugin to version 6.0.3.5. I have now just updated to version 6.0.3.7 and that version also seems to work OK.

Maybe MailChimp has done some changes to their code that solved the problem?

With regards to your last paragraph in your response above, the links provided by MailChimp works fine for updating the profile.

So, I guess we can close this ticket for the time being, and if I encounter the error again I will let you know.

Thanks a lot for great support!

Hi Evan,

Thanks a lot for the tip hat enabling the Debugging will change the error messages from the Custom Messages to the error messages as sent by MailChimp. That explains why I first got the General Error Message I had set myself, but later started to receive the “We received an unexpected error: null”. Obviously it was because I later enabled the Debugging. I would suggest that you better clarify that under the check box for the Enable Debugging by adding something like “If you encounter an issue with Easy Forms for MailChimp you can toggle on debugging to display advanced error messages instead of the Custom Messages and start logging errors.”.

(Another thing you could clarify with regards to error messages, is to add a note under Custom Messages mentioning that some error messages in the form are generated through HTML5 Form Validation and will be presented in the language as set by the browser. I noticed this confuses some of your users.)

Anyway, if I turn off the debugging, and try to subscribe with an already subscribed email, then the Custom Message that will be returned is the General Error Message, which is incorrect. The error message that should be returned if a user is already subscribed should be the Email Already Subscribed error.

The Custom Messages I used, were in Swedish, but I have now done a form for you in English, with English Custom Messages and the error is still the same. I also tried changing a field in MailChimp that had a Field Label with a Swedish character, but even if I remove the Swedish character, I still get the same error.

I have included a form using your plugin here: https://www.miamitravel.se/halloween-miami-beach/

Please scroll down to the form in cyan color and the 3 input fields and a button saying “Yes, Please!”.

Right now I have enabled the Debugging so that you can see the actual error messages returned from MailChimp.

In that form I have also included all Field Labels in that mail list, i.e. mail address, name and surname.

To replicate the error you will have to subscribe with an email twice. The first time you will receive an optin email from MailChimp as usual. When you confirm the subscription and then try to subscribe again with the same email in the form above, you should receive the error “We received an unexpected error: null”.

In the sidebar to the right I have also included a similar form using the standard MailChimp embed code where you can subscribe to the same mail list. If you try to subscribe in that form with an email that you have already subscribed in the other form using your plugin, you will receive a correct error message saying that the user is already subscribed and providing a link for the user to update the user’s profile (the text is in Swedish) and MailChimp will then send an email for the user to update their profile.

As I mentioned before, if I instead change the Optin Settings > Update Existing Subscriber from ‘No’ to ‘Yes’, things works properly and the already subscribed users details will be updated in the MailChimp mail list. But setting it back to ‘No’ and I will receive the incorrect behavior from your plugin.

Please let me know what else I can do assist you in finding the cause of this.

Cheers

Hi Tracy,

and thank you very much for your quick reply and useful recommendations.

Your link to the shortcode options was very helpful, as I hadn’t found it yet.
I wasn’t aware of the custom_title, which basically can solve my problem.

After going through close to 30 form plugins, I found your plugin to be the best so far.
So, as a suggestion to make your plugin hopefully even better, let me give you some clarifications on my previous two bullets.

So, from what I understand with regards to titles, your plugin and widget now has Form Name, Widget Title, title=“1” and custom_title.

I still think there are many use cases where, what I would call Form Title is very useful.

1. I think your current Form Name should, as the name implies, be an internal name for the admin, to make it easy to distinguish between different forms. The admin may have 10 different forms, where the title could be “Newsletter” for all of those forms. It would then, from the admin point of view, be confusing to set all the Form Name to “Newsletter”. To make it easier, the admin should set each Form Name to something that is explanatory for the admin, and then as you recommend, the admin could instead set the custom_title to “Newsletter”. Which, would solve the problem. However, as soon as the admin wants to update the title, all pages with that shortcode has to be updated. I assume the purpose of the forms is to have a central location where you can change the title in one place and it is then updated on your whole site, and that is where my suggested Form Title would be very useful. The custom_title could still be useful, if the admin wants to override the central Form Title on a single page.
2. You are correct that your widget has a Widget Title. Sorry, I was a bit unclear. The Title I would like to be able to enable in the Widget is the one I call Form Title. Even if you don’t implement Form Title, I think it should be possible to have widget-forms that look similar to the shortcode-forms, i.e. make it possible to either use title=“1” in the widget or set the custom_title. Of course you can use the Widget Title, but that title is part of the theme and not your form and so the appearance of the widget-form will differ from the shortcode-form. What I will do currently to resolve the issue, and have uniform forms in the widget-area and post/page-area, is to instead of your widget, add a text widget where I in HTML add your short code with a custom title, e.g. [yikes-mailchimp form=”1″ title=”1″ description=”1″ custom_title=“Newsletter” submit=“Send”]. However, I think your widget would be much more complete and beautiful if you, just like the checkbox for “Display Form Description”, added another checkbox “Display Form Title”, which would enable and show the Form Title in the widget (or the Form Name if you don’t like the idea of a Form Title).

The field I call Form Title, could be an input field below the Form Name in the Form Builder, and it could default to the Form Name when it is empty. Or it could be a Form Field in the Form Fields & Interest Groups-box that you can add to the form, just like any other field.

What I found so beautiful with your plugin is that I can have many forms centrally located, easy to update with immediate effect on my site. That is what a form is for. But to be useful I will now have to use the Form Name as the Form Title, and as I have many forms with the same titles, I will unfortunately have to keep a separate logg of which form is which.

You can consider this support request resolved, but as explained, please consider adding this feature in the future.

Thanks again for great support and a great plugin.

Thanks a lot Support,

For the very quick reply.

I had a look at your support forum and found these two links related to this problem:
https://www.dfactory.eu/support/topic/feature-request-prettyphoto-allow_expand/
https://www.dfactory.eu/support/topic/responsive-lightbox-not-displaying-properly-on-iphone/

Where the second link provides CSS code, which worked for me after I changed the .pp_details to a width of 100% as follows:

/* prettyPhoto styling for small screens */
/* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */
@media only screen and (max-width: 479px) {
.pp_pic_holder.pp_default { width: 100%!important; left: 0!important; overflow: hidden; }
div.pp_default .pp_content_container .pp_left { padding-left: 0!important; }
div.pp_default .pp_content_container .pp_right { padding-right: 0!important; }
.pp_content { width: 100%!important; height: auto!important; }
.pp_fade { width: 100%!important; height: 100%!important; }
a.pp_expand, a.pp_contract, .pp_hoverContainer, .pp_gallery, .pp_top, .pp_bottom { display: none!important; }
#pp_full_res img { width: 100%!important; height: auto!important; }
.pp_details { width: 100%!important; padding-left: 3%; padding-right: 4%; padding-top: 10px; padding-bottom: 10px; background-color: #fff; margin-top: -2px!important; }
}

I could also suggest to include the below CSS within the brackets above in order to improve the readability on small devices and to break the top title (div.ppt) when needed:

div.ppt{width:100%!important;}
div.pp_default .pp_description {margin: 0px 20px 5px 0!important;font-size: 17px!important;font-weight:100!important;line-height:1.3em!important;}
div.pp_default .pp_nav {margin-top:5px!important;}
a.pp_close {right:5px!important;top:5px!important;}

Please consider including the above CSS in your plugin because there are still millions of people using small devices and they will definitely have a bad experience of prettyPhoto without it and I guess a lot of people using your plugin don’t even realize those people are having a bad UI experience.

Cheers

Thanks a lot Bartosz for the very quick reply and great to hear that there will be a fix for it.

I’ve gone through all other lightbox plugins out there, and your plugin rocks.

Keep up the great work!

I also have this exact problem. PrettyPhoto looks great except on small screens where the lightbox becomes super small as the padding occupies most of the screen, which makes PrettyPhoto useless.

Any suggested solution?

Cheers