Enis

@kbjohnson90, why not minifying them?

I think that would be the best solution for a number of reasons:

• it would eliminate the problem at its root
• it would reduce the output size, improving the overall performance
• it can be easily implemented

@kbjohnson90, I look forward to it. Thanks for the heads up.

Do you approximately know when you are going to fix it?

Sweet. Thank you!

@mte90, when do you plan to apply that fix?

I don’t mean to hurry you. I need to know it just to schedule my work accordingly.

Hi, @krmoorhouse and @allenjaym ??

I’m the OP of the thread referenced.
I confirm that I’m using the latest version of NF and I have the very same problem mentioned here.

I suggested to either externalise that js or to put it all in a single line—i.e. minify it.

Is any of those a viable solution?

• This reply was modified 7 years, 10 months ago by Enis.

Meanwhile, NF support answered privately.

Here’s their answer:

You have diagnosed the issue correctly. It happens from theme or plugins modifying the default behavior of the_content filter. We have no way of preventing that other than recommending that you don’t use plugins or themes that mess with this core behavior. You can also try using the “append to form” option in the sidebar of the post or page editing screen instead of the shortcode.

Best regards,

James
WP Ninjas, LLC

Of course, I don’t agree with the given solution.

First off, too many plugins add filters to the_content and the_content is not a place to put javascript on.

I suggested to either:

• externalise the js code—header, footer or external files are all fine places
• write it all in one line, with no new lines

Either solution would be absolutely painless and would fix a problem that’s going to become common and relevant for NF user.

I hope they will realise what a major flaw adding js code in that unfortunate place is.

• This reply was modified 7 years, 10 months ago by Enis.

I agree: Ninja Forms shouldn’t put js code there.

Thanks for the quick fix.

I hope Ninja Forms developers realise what a major flaw that js in that awkward place is.

Yes, it did ??

Thank you!

Same problem here. The update did fix the issue ??

• This reply was modified 7 years, 10 months ago by Enis.

Thank you, @m1il0s!

I haven’t had the chance to check if populating the categories fixes the problem, yet, so I’m leaving the ticket open until I can verify if populating the categories fixes the issue.

No, I haven’t.

I also tried to hack the database and change the values manually, in order to make them match, but it didn’t work.

The problem persists.

Sweet. Thank you!

There’s only one term: “24/7”.

The php log doesn’t add anything new:

[01-Mar-2017 09:02:04 UTC] PHP Warning:  preg_match(): Unknown modifier '7' in /home/***/public_html/wp-content/plugins/glossary-by-codeat/public/includes/Glossary_Tooltip_Engine.php on line 300

No problem for the delay ??

Unfortunately, the site is not public.

However, it runs on Genesis, should it help pinpoint the problem.