krmoorhouse
Forum Replies Created
-
Thanks for pointing this out. We typically use sprintf for all of the reasons you’ve listed, but every once in a while, something slips through the cracks.
I’ve submitted a patch for the issue, and it should be resolved in a future release.
@webdados This is an error that is thrown by the deprecated portion of our codebase, which is no longer supported.
To resolve the error, please upgrade your Ninja Forms to version 3.
(Settings -> Advanced -> Upgrade to THREE)-KR
- This reply was modified 3 years, 8 months ago by krmoorhouse.
This issue should be resolved as of version 3.5.2.
-KR
You are correct. This is the purpose of our Stripe and PayPal add-ons. The core Ninja Forms plugin does not have a premium version. All add-ons integrate with the free plugin, and we do not take any percentage of the transactions made by your users.
If you have any further questions regarding our add-ons and their features, please contact us using our support form (https://ninjaforms.com/contact/). This allows us to respond to your more quickly and with more in-depth answers.
Thank you,
-KRThank you for posting that fix, @emielb. It saved us some time in tracking down a solution, and it should be included in the next Ninja Forms release.
That said, we can’t promise that you won’t see more IE11 issues going forward. Official Microsoft support for it ends in August of this year, and as we update our javascript code to be more in-line with modern standards, it’s very possible that there might be other conflicts. This is already the 2nd case of IE11 specific conflicts this year, and it’s only the beginning of March.
I realize that none of us can control the web browsers that our customers choose to use, but if possible I would be advising them to look into alternative web browsers.
It looks like there’s a difference in how MariaDB and MySQL handle “IF NOT EXISTS”, which is a statement we use upon install/upgrade to determine if all of the correct database tables are in place for Ninja Forms to work.
Gotta love it when system architectures don’t speak the same language, right?
I’ve added a bug report for this, and our devs will need to look into it. Thanks for the error messages though. That should point them straight to the problem.
*Context*
It was pointed out to me, after the fact, that I should provide additional information about how to practice responsible disclosure.
The best method of reporting a security threat in a plugin is to contact the plugin author privately first. In this case, you could reach out to our support staff at ninjaforms.com/contact
Once an issue has been publicly reported, anyone that was previously unaware of it now has the option to leverage it, making all users of the software more vulnerable, simply as a result of easily searchable web knowledge.
If you’d like more information on responsible disclosure, please see https://blog.detectify.com/2018/02/27/guide-responsible-disclosure/
Our development team is currently developing an important patch to track down an existing issue in our system. In order to best address that issue, we will be pushing out a completed patch on Monday, which will also include a fix for this issue as well.
While we appreciate you pointing out this issue to us, we would have preferred that you practiced responsible disclosure in this matter. That would have allowed the least amount of stress on both our team and on our users, who are now more vulnerable due to this early, public report.
-KR
- This reply was modified 5 years, 3 months ago by krmoorhouse.
Hey,
Some of the styling that can be applied through the form builder introduce elements that are reliant on dashicons to function. So, our structural styles have dashicons as a dependency.
Ideally, we would prefer to only require that dependency in cases when we can detect that it is necessary, but that’s a future solution. At the moment, we’ve chosen to err on the side of caution.
If you’d like to manually enqueue our stylesheet in the same function that you’ve used to remove dashicons, you should be able to do so with the following:
wp_enqueue_style( ‘nf-display’, Ninja_Forms::$url . ‘assets/css/display-structure.css’ );
-KR
Hey,
We haven’t deprecated that class. So, if it’s missing, something is wrong.
Have you recently upgraded from our 2.9x codebase to THREE? If so, that would potentially have a breaking affect on your custom code.
If not, I’d recommend reaching out to our support staff at https://ninjaforms.com/contact/ so that we can get some server environment data from you that we don’t want to ask for on a public forum.
It’s altogether possible that if our support team is unable to find anything wrong with your actual Ninja Forms installation, they will also point you to our developer slack channel: https://developer.ninjaforms.com/slack/
If there’s not a problem with the plugin itself, someone there should be able to help you track down what’s going on in your custom code.
-KR
Hey,
You can get the basics from some of our older documentation here: https://developer.ninjaforms.com/codex/custom-server-side-validation/
It’s a little dated, but the code should still work. You’ll need to make sure that you set the headers to Content type JSON in the response function.
If you have additional questions along this line, please visit our developer slack channel: https://developer.ninjaforms.com/slack/
-KR