variable mismatch

https://make.www.ads-software.com/core/2018/12/13/backwards-compatibility-breaks-in-5-0-1/

Form element no longer passes KSES
Prior to 5.0.1, the $allowedposttags array contained an entry for the <form> element and some of its attributes. Because of that, Contributors and Authors could use it in posts.

The element was removed in 5.0.1, except for situations where a plugin has explicitly registered input or select fields via the wp_kses_allowed_html filter. If a Contributor or Author includes <form> in their post, it will be removed when the post is saved. It will also be stripped from arbitrary content that plugins pass to wp_kses_post() or wp_kses_allowed_html( ‘post’ ).

If a plugin author wants to restore the original behavior, they will need to add form, input or select tags via wp_kses_allowed_html. Please exercise caution when doing so, because this could re-introduce a vulnerability. Make sure only trusted users are allowed to add <form> tags.

What plugin are you using for your forms?

I’m not using any plugin to create the forms. I’ve written the html code for them directly into the page.

OK, then see the “make” article posted above.

So I need to “add form, input or select tags via wp_kses_allowed_html” ??

Is there an example somewhere that I could look at to show how this gets accomplished?

Thanks,

– David.

see https://codex.www.ads-software.com/Function_Reference/wp_kses_allowed_html and https://hookr.io/filters/wp_kses_allowed_html/

Based on what I’ve read, I think the following PHP code, placed somewhere prior to where the <form …> element appears in the html code, ought to restore the functionality of the <form> element:

function my_filter_function_name(  $string  ) { 
  $string['form'] = array ('class' => array(), 'action' => array(), 'method' => array(), 'style' => array() );
  return $string;
}
add_filter( 'pre_kses', 'my_filter_function_name' );

But it isn’t working, so evidently I’ve overlooked some crucial step or I have simply gotten something wrong. Maybe both.

– David.

• This reply was modified 5 years, 11 months ago by Steven Stern (sterndata).

You’re replacing the entire array. I think you should be adding to the array passed in.

I’ve now added the following code to both the page with the <form> in it, as well as to the page that does the processing when the user clicks on the submit button:

function my_filter_function_name(  $string  ) { 
  $string +=  ['form' => array ('class' => True, 'action' => True, 'method' => True, 'style' => True)];
  $string +=  ['input' => array ('class' => True, 'action' => True, 'method' => True, 'style' => True)];
  $string +=  ['select' => array ('class' => True, 'action' => True, 'method' => True, 'style' => True)];
  return $string;
}
add_filter( 'pre_kses', 'my_filter_function_name' );

However, the “A variable mismatch has been detected.” error message still arises when the user clicks on the submit button.

• This reply was modified 5 years, 11 months ago by Steven Stern (sterndata).

I’m still struggling to try to restore the functionality that the WordPress upgrade broke. Something that I’m wondering… since the form that is coded into the html of the page in question does indeed get shown to users, along with the data entry fields and a button that can be pressed (and which ought to take the user to another page that does the processing), then this would seem to imply that tags such as “form”, “input” and “select” are not being automatically removed from the page’s html, and as such it seems that using a filter to avoid having them removed is not the correct course of action to be taking.

So unless my logic is flawed, then I think I’m back to asking my original question… how can I tell if there truly is a variable mismatch (as is being reported by the error message)? I note that the URL that is normally displayed after the user clicks the submit button and is taken to the secondary page for processing is actually the same URL as the original page (i.e., the original “www.mysite.org/?page_id=1234” URL remains on display) even though the new page actually has its own distinct page_id. Might that be the source of the reported variable mismatch? If so, how can I tell? And more critically, what can I do about it?

Thanks,

– David.

According to what I see in trac, the problem introduced in 5.0.1 will be fixed in 5.0.3.

Okay, I’ll wait for 5.0.3 to come out.

Thanks,

– David.

WordPress 5.0.3 has been released, and I’ve upgraded my site to 5.0.3.

However, the “A variable mismatch has been detected.” error message persists.

What can I do?

I’ve been having this issue too. I just want to use <form></form> on a page and it’s impossible to use. I’ve tried adding the filter as described above and nothing.

Can someone please just outline how to make in page/post forms work?

Can somebody who is “in the know” please say either when WordPress will fix this bug, or otherwise offer a reasonably clear description for how to work around it?

Thanks.