Ali Khallad

I see, the WP Hook action will only provide submission values at this stage and we wanted to keep the values passed to a minimum to avoid complexities. The reason for this is because there are other hooks for submissions that holds all the details. We plan to extend this with more actions in the future, these actions will have more data and we want to do it correctly.

Could you use this hook “mf_submission_completed” or this one “mf_process_entry_actions”? would they work for your case, if not I’ll go ahead and make the necessary adjustements to include form id in the action. However, for post ID, we do not collect this info, but you could use get_page_by_path core function and pass the “referrer” slug from the entry data to it to retrieve the post id.

Let me know if this help, or we still need to make adjustements to the plugin.

May I ask at what stage are you interacting with this array? what hook are you using and what do you need this info for?

Note that Mega Forms does not interact with the posts table, it has it’s own forms table so there is no post ID at any stage.

If you need to pull specific data, just let me know what info is available for you and what you need to pull and I’ll share the correct steps.

We’ve added this to the latest version 1.2.8

Thanks again for the suggestion.

• This reply was modified 2 years, 4 months ago by Ali Khallad.

Hey, thanks for the suggestion!

I’ll add this in the next release, are there any other additions you’d like to see along with this one?

I’ll try to push this change tomorrow.

Hello,

Thanks, we appreciate the kind words and happy that you like our plugin.

Yes, we were using ‘megaforms_’ and ‘mega_form’ prefixes at the begining for the initial version that was very small and simple but decided to use ‘mf_’ later and didn’t think about changing the existing prefixes. However, since you mentioned this point, I’ll make sure to release a new update shortly that tackles this point.

Hello, thank you so much for reporting this!

We have fixed the PHP 8 compatibility issues in the latest release 1.2.6

Please don’t hesitate to contact us if you notice more issues.

Thanks,
Ali

Awesome, happy you got it sorted. We are trying to keep the plugin as light as possible to maintain good performance that’s many features are not available by default. However, this seems like a good feature that a lot of people could use, so I’ll make sure to add it next time.

Thanks,
Ali

Hello Alicia, thanks for reaching out.

Conditional emails are not supported yet, we can work it out via some custom snippet, but the actual option to make this happen has not been built yet.

How soon do you need this feature, I might be able to build it into the next version?

Awesome, feel free to open another ticket if you run int other issues.

Hello,

Feel free to uncheck the option altough not necessary. This option will try to output the button automatically on thank you page. If the default thank you page is changed this option might not work, which is why we made a shortcode availabe.

The shortcode will uses the same CSS classes used for default notifications. Due to the large number of theme out there, it’s almost impossible to try and match all of them, so sometimes if the existing CSS classes doesn’t have an effect, you’ll need to write custom CSS to make them look as you want.

Let me know if this answers your question!

Thanks,
Ali

Thank you, we are happy you liked the plugin.

Regarding the create account button, you could disable it and use the shortcode to display it in a different place, that might help you sort the issue. Otherwise, feel free to open a ticket with all the details and I’ll be more than happy to help.

Hello again, I just published a new update where I replaced the cookie prefix from “mf” to “wordpress_mf”, this should help with caching plugins that are excluding the “wordpress_” prefix from being cached.

I’ll go ahead and mark this as resolved. Feel free to open another ticket if you run into this issue again.

Thanks,
Ali

That’s perfect.

Can you please test something for me. Restore WPRocket options and add this to your wp-config.php file

define("MF_SESSION_NAME", "wordpress_mf");

This will change the session cookie name so that it starts with “wordpress_”. If WPRocket is excluding cookies starting with “wordpress_” by default, I might need to change the default cookie name to account for this and avoid the need for special configuration.

Can you please test and let me know if the issue is gone?

Thanks,
Ali

Hello, thanks for reporting this!

May I ask where is your website hosted?

Did you have the issue after the update? or was it an old issue?

The error is caused when the session id is found in the cookies, that could happen when there is some special caching implemented on the server. The session id is used for additional security, but it’s not absolutly necessary and can be disabled. However, it’s better to fix than disable if that’s possible.

Thanks

Thanks for the suggestion, this feature is added into the most recent release 1.0.4.

Please do not hesitate to open another ticket if you’re still having issues.

Thanks