ouija

Excellent! Thank you for your instructions, really helped me figure out how to debug issues with JavaScript minification, and it appears that the error is being caused by:
/wp-content/plugins/wordpress-seo-premium/assets/js/dist/frontend-inspector-1921.min.js
which is a file related to the YoastSEO Premium plugin.

Adding this file to the Exclude JavaScript from processing options seems to have corrected the issue.

Thanks again!

Update: This might be an issue related to the latest version of the Yoast SEO plugin, as I attempted to revert WP-Optimize to v3.2.6 and getting same error with it now (and I had updated Yoast SEO at the same time), but can’t say for certain because I also didn’t revert back the version of Yoast.

Same issue here. Just wanted to comment so I’m notified when update released, thanks! Will roll back for now.

Hey,

Thanks for the update — Glad to see this as an actual option now, and just wanted to post back saying that my changes here are NO LONGER necessary in v3.6.6+ (both issues appear to be addressed in v3.6.6 with having this new “legacy submissions” option enabled), so there is no need for my any of my code above, as the _form_id issue appears to be resolved as well.

Hopefully this “legacy submissions” option won’t be removed anytime soon (as I did note that it is labelled as being temporary in the changelog), as I much prefer the legacy method over the new submissions/modal editor method.

I’ll be posting an update to this thread if/when it is removed I guess! ?? Thanks for now!

Yes, they do have someone reading this page — Bugfixes and releases take time, don’t be so entitled to expect an update or response asap ?? There were some major changes done recently, and unfortunetly, not all of the kinks have been worked out, apparently.

Revert back to version 3.6.1 or earlier if need be…

• This reply was modified 3 years, 4 months ago by ouija.

@stuartsequeira All good! Documentation is a dev’s worst nightmare, and being one myself I can understand the oversight.

I look forward to seeing methods on how to add metaboxes to this new submissions page and the actual modals themselves; The method I’ve devised works but I’m not a huge fan of how I’m actually achieving this, so seeing how you’d suggest to go about this would be helpful.

Thanks!

I’m not 100% certain if this is the underlying cause of issues related to no submissions being displayed for other languages, but submissions not being displayed for me were related to admin users with any other role than “administrator”, and unfortunetly, as of Ninja Forms 3.6.1 or greater, you’ll need to add a filter to your functions.php if you too are experiencing the same issue.

Alternativly, you could also install the User Role Editor plugin and modify whatever role you need to have this manage_options permission:

Again, I cannot confirm if this will fix the issue with no submissions appearing for differenct languages, but this may help. Otherwise, there may be an issue with special characters being returned via the REST API method that is now being utilized, which is breaking the code from rendering (resulting in no submissions appearing)

The problem is that as of Ninja Forms > 3.6.1, they’ve moved away from using the WordPress Posts Editor (for the custom nf_sub post type) in favor of a new custom admin page for the submissions — and somehow neglected to detail this in the release notes.

For example, the old submissions page/editor was found at the url of /wp-admin/edit.php?post_type=nf_sub (initial page for listing all forms) OR /wp-admin/edit.php?post_status=all&post_type=nf_sub&form_id=#&nf_form_filter&paged=1 for a specific form (where # in the url is the ID related to the form)

This update now utilizes a custom admin page at the URL of /wp-admin/admin.php?page=nf-submissions (initial page for listing all forms) OR /wp-admin/admin.php?page=nf-submissions&form_id=# for a specific form.

Note that this new custom admin page for Ninja Forms Submissions actually utilizes ninja-forms-submissions/submissions/get REST API endpoint for populating this page with submission data, and the default requirements for accessing this endpoint rely on the user’s assigned role having the manage_options permission.

You can, however, override this behavior by use of some new filters, as you’ve mentioned above or as per: https://gist.github.com/New0/06d5b7664a8cfbb256a13bc68de0aa98#gistcomment-3931738

You could also install the User Role Editor plugin and modify whatever role you need to have this manage_options permission:

Another issue I ran into was in regards to some custom metaboxes that I’ve added to the submissions post editor (via add_meta_boxes actions) no longer work, due to the wordpress post editor no longer being utilized, and instead submissions are being loading in a custom “popup modal” editor — I’m developing my own work around for this currently, which is a bit “hacky” to say the least, but is the only way I can figure out how to do so unless a developer for Ninja Forms can shed light on how to customize the submission “modals” under this new admin page.

Hopefully this helps! It certainly threw me off last week and has taken me serveral days to adapt to this latest update of Ninja Forms (with development still ongoing) — after almost 5 years of it functioning great without any of these issues prior to this!

I would just like to say to the developers that changes of this magnatitude should always be detailed in the release notes, so that users aren’t left scratching thier heads as to why nothing is functional like it was prior to the latest update

• This reply was modified 3 years, 4 months ago by ouija.
• This reply was modified 3 years, 4 months ago by ouija.
• This reply was modified 3 years, 4 months ago by ouija.
• This reply was modified 3 years, 4 months ago by ouija.

This may be due to the fact that as of Ninja Forms > 3.6.1, they’ve moved away from using the WordPress Posts Editor (for the custom nf_sub post type) in favor of a new custom admin page for the submissions — and somehow neglected to detail this in the release notes.

For example, the old submissions page/editor was found at the url of /wp-admin/edit.php?post_type=nf_sub (initial page for listing all forms) OR /wp-admin/edit.php?post_status=all&post_type=nf_sub&form_id=#&nf_form_filter&paged=1 for a specific form (where # in the url is the ID related to the form)

This update now utilizes a custom admin page at the URL of /wp-admin/admin.php?page=nf-submissions (initial page for listing all forms) OR /wp-admin/admin.php?page=nf-submissions&form_id=# for a specific form.

Note that this new custom admin page for Ninja Forms Submissions actually utilizes ninja-forms-submissions/submissions/get REST API endpoint for populating this page with submission data, and this is where you’re likely now having issues, as the default requirements for accessing this endpoint rely on the user’s assigned role having the manage_options permission.

You can, however, override this behavior by use of some new filters, as per: https://gist.github.com/New0/06d5b7664a8cfbb256a13bc68de0aa98#gistcomment-3931738

Another issue I ran into was in regards to some custom metaboxes that I’ve added to the submissions post editor (via add_meta_boxes actions) no longer work, due to the wordpress post editor no longer being utilized, and instead submissions are being loading in a custom “popup modal” editor — I’m developing my own work around for this currently, which is a bit “hacky” to say the least, but is the only way I can figure out how to do so unless a developer for Ninja Forms can shed light on how to customize the submission “modals” under this new admin page.

Hopefully this helps! It certainly threw me off last week and has taken me serveral days to adapt to this latest update of Ninja Forms (with development still ongoing) — after almost 5 years of it functioning great without any of these issues prior to this!

I would just like to say to the developers that changes of this magnatitude should always be detailed in the release notes, so that users aren’t left scratching thier heads as to why nothing is functional like it was prior to the latest update

• This reply was modified 3 years, 4 months ago by ouija.
• This reply was modified 3 years, 4 months ago by ouija.

Figured out the issue — for some reason, the X-WP-Nonce header is NOT being set properly when using performing test calls using the SwaggerUI interface with a user logged in to WordPress…

Not sure what is causing this to happen now, as previously this issue did not exist, but this appears to be what is causing the problem.

Will post back if I can figure out a solution to this.

• This reply was modified 3 years, 4 months ago by ouija.

Update: Upon further investigation, the issue seems to be that IF I am logged into WordPress, I cannot access the rest api without a 401 error (which is odd); If I don’t have a session set (not logged in), then it works…

Strange.. I _think_ this might have something to do with WordPress 5.6 rolling out integrated support for “Application Passwords” versus WooCommerce REST API tokens, and for whatever reason, when you are *logged in* and trying to use a WooCommerce based token for accessing the API, it doesn’t work… (but it does if you are NOT logged in)

It’s a stupid thing… still trying to figure out what the heck is going on with it..

• This reply was modified 3 years, 4 months ago by ouija.

Fixed it by adding a *.xsl filter to the the CDN Settings page:

Managed to figure out how the plugin works in relation to logging data to these tables; Here’s a method I’m using via functions.php to disable this (and you can also then empty this wp_wcfm_detailed_analysis table, as well as the wp_wcfm_daily_analysis table:

function remove_action_wcfm_save_page_analytics_data() {
    global $WCFM;
    remove_action( 'wp_footer', array( $WCFM->frontend, 'wcfm_save_page_analytics_data' ) );
}
add_action( 'wp_head', 'remove_action_wcfm_save_page_analytics_data' );

Enjoy.

I too just noticed that I am getting this error since applying the latest NinjaForms update back near the beginning of December 2020:
Uncaught TypeError: dateObject.pikaday.setMinDate is not a function

And upon further investigation, discovered that it was due to NinjaForms dropping the old Pikaday plugin that it uses for datefields, and now includes the Flatpickr plugin instead (which is fantastic, since it’s a more robust datepicker and my preferred plugin, and I was already previously using this in the same platform and other projects).

However, this means using an alternate method when it comes to customizing the date fields, since the methods that were specific to the Pikaday plugin are no longer applicable.

So instead of using a method like so to set a minimum date on the datepicker:
dateObject.pikaday.setMinDate( new Date() )

You’ll need to update your code to use an initialization method specific to the Flatpickr plugin, like so:
dateObject.set("minDate", new Date());

And the error should be resolved! Note that you will need to update *any* similar functionality in regards to date fields and NinjaForms.

Hope this helps!

• This reply was modified 4 years, 1 month ago by ouija.
• This reply was modified 4 years, 1 month ago by ouija.
• This reply was modified 4 years, 1 month ago by ouija.
• This reply was modified 4 years, 1 month ago by ouija.

I’m also having issues with the COD plugin (which I’ve posted about on GitHub), where I updated to latest WooCommerce release 4 days ago (4.5.2) while running latest version of WordPress 5.5. (along with latest version of WC-Vendors 2.2.1) and the COD payment gateway [WC_Gateway_COD] constantly returning “Invalid Payment Method” validation error at checkout; Issue wasn’t occurring prior to update and reverting back to 4.4.1 does fix this issue.

• This reply was modified 4 years, 5 months ago by ouija.
• This reply was modified 4 years, 5 months ago by ouija.
• This reply was modified 4 years, 5 months ago by ouija.