arlingtoner

Nice to see even noncritical issues addressed. A tidy debug.log helps debugging and is appreciated even though, I hope, it isn’t the most important thing that you got done this week. In any case, a big ??(hopefully a thumbs up emoji) for your extra effort.

Looks good to me. If you close incidents, then please close this one.

It doesn’t. I think that I’m already pretty conversant with how to move data from one page to another after reading the multiple WPForms documentation on the subject. Perhaps that my code has been working for almost a year reinforces that.

What would help is finding out if you’ve tested with WP_DEBUG set to true on your site. As my rather detailed look at the 1.7.2 code earlier in this thread indicated (do you have a rebuttal for it?), the symptoms I experienced are only when that is done.

You can’t replicate this? What exactly have you tried? I can try comparing that to what I have.

I’ve looked at the WPForms Lite 1.7.2 source code and here is what I’ve taken away.

The root of the problem is that I have WP_DEBUG defined as true in the site’s wp-config.php file. That leads to the following:

When WPForms wants to get the value of the {field_id=”1″} smart tag in my form’s Confirmation Redirect URL, it eventually gets to get_value() in …src\SmartTags\SmartTag\FieldId.php. There it uses the WordPress apply_filters_deprecated() which uses the _deprecated_hook() in wp-includes\functions.php which cares about the value of WP_DEBUG. Because it is true on my site (I’ve been doing some debugging), I get the mysterious deprecated message on my page and in my debug.log.

If that was all that happened, it would be unaesthetic and I would complain because there is no good reason for WPForms to be triggering a user-level message that isn’t about a user action but rather about internal WPForms code. (And note the WPForms Lite changelog for 1.6.7.1 where I believe action was taken not to produce a deprecation message.)

However, something worse happens. get_value’s call to apply_filters_deprecated() seems to do what it is supposed to do, that is, return the email address entered into Field ID #1 of my form, for example, “eric_baatz%40yahoo.com”. And the code somehow continues on to produce the following in my debug.log:

[06-Jan-2022 21:14:55 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/dh_bbfafd/tsglma.org/wp-includes/functions.php:5586) in /home/dh_bbfafd/tsglma.org/wp-includes/pluggable.php on line 1340
[06-Jan-2022 21:14:55 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/dh_bbfafd/tsglma.org/wp-includes/functions.php:5586) in /home/dh_bbfafd/tsglma.org/wp-includes/pluggable.php on line 1343

The end result of whatever that path does is a blank/white page with the three warnings on it and the browser’s URL having not changed, rather than changing to that of the form’s Confirmation Redirect URL. From a user’s perspective, that says my form no longer works, which I claim should not be dependent on the site’s WP_DEBUG value alone.

The simplest solution here seems to be not to produce the deprecation message.

> I was not able to replicate the issue on my test site with Lite plugin.

Did you have “define(‘WP_DEBUG’, true);” in the site’s wp-config.php?

I must be missing something here as the URL in your message seems to be the same as the one in my message, where the only double quotes are around the number one (“1”).

First, thank you for going beyond your mission and commenting on my code.

1. However, the code does follow the format that you suggest. TSGL_EAFTTR is the FORM_ID and ‘0’ is the FIELD_ID.

2. I suggest that bits of custom code are within your support mandate as multiple WPForms pages show custom code (for example, https://wpforms.com/developers/wpforms_process_validate_text/) and I would like to think that you want to keep their advice useful and working. For instance, you would be interested in fixing the publicly-available error reporting mechanism that I had reported could be broken. if it was broken.

3. Fortunately, it is not, and you can close this ticket. My problem was that the FIELD_ID of ‘0’ should have been ‘1’. I suspect that I altered the form and didn’t notice the FIELD_ID change, so I didn’t update my error checking code.

Anyway, Happy New Year!

Do you think that a user should be able to do anything in a form’s field that causes a fatal error? Rather I think that they should get a warning that says something like “tisk, tisk, please enter fewer than 63 characters” similar to the warnings they get for many other types of bad input.

Oops, my mistake. The field is an Email address field, not a Single Line Text field.

> TablePress does actually have its own integration into the WordPress search…

That is good to know. How should I have found that out? As my search needs are pretty simple, had I known, I perhaps wouldn’t have immediately gone with a plugin. In doing so I lost the chance to find by experimentation that tables are searched. (Although I have to admit that I wouldn’t have guessed that due to the “on the fly” generation of the table through the shortcode mechanism, but maybe as a WordPress newbie, I’m still too ignorant about such things.)

Wow. Thanks. I’ll give it a try today.

That is wonderful, although surprising to hear, as I’m running Ivory Search 5.2.1. Is there anything that I need to do to take advantage of the capability?

I have a page that contains a TablePress table that has two columns and eight rows (see https://www.eribaa1.dreamhosters.com/planning-committee/). One of the columns contains names, one of which is “John Demoy”. The other column contains rows of strings, one of which is “Emeritus” in several rows.

When I run a query for “John Demoy” (AND search with fuzzy search in my pages, posts, and media with the default WordPress Search Engine), I get several hits, but not one for the page that contains the table I mentioned above. A search for just “Emeritus” does find the page, but I believe that is because the word is in the text above the table.

If you want to give things a spin, go to https://www.eribaa1.dreamhosters.com/search/, which is a front to a number of Ivory Search forms that I’ve created.

Thanks for the clear answer. And while I do appreciate protection from SQL injection and the like…

1. Is there documentation that I missed about the form field that warned/told me about that behavior? If not, it would be nice to have such documentation.

2. You folks doing anything else I don’t know about with user input? It seems like I don’t have to do anything to protect against SQL injection because you’re doing it. Anything else I don’t have to do?

3. Is it possible to have your filtering occur after I have my shot at messing with the user input, that is, execution-wise, move you code after the hook I use to do my error checking?

Looking at my message on the forum gives what is probably a big hint. Its title is supposed to be ‘Mysterious “%Da”‘ (Mysterious, double quote, percent sign, uppercase D, lowercase a, double quote) but I see only ‘Mysterious “”‘ (Mysterious, double quote, double quote). Some sort of HTML filtering?