Closed k1sul1 closed 5 years ago
Polylang isn't affected, as it uses {{ }}
as matchers.
/"%[^%%\n]+%/
looks like it would "handle" the situation, but that would break <input %SOMETHING%>
, as it depends on double quote. [" ](%[^%%\n]+%)
looks even more terrifying, but it seems to work in the cases I can imagine happening:
But there's always going to be a corner case that breaks it. I think we have to make a breaking change to get this to work properly. Changing %
to ##
or something should do the trick, 1.5 was kinda released already, so uh...
Can we call the next release 2.0? It's a lot of features we've shipped and I'd like to follow semver to at least some degree.
Changing the matcher sounds reasonable to me, even it will cause a breaking change. By continuing using %
we will set ourselves to harm's way because it might cause unpredictable issues later on. We also need to ship another breaking change, #144.
Versioning next release to 2.0 👌
I got a report from someone saying that using
%
in a form stops the form from being rendered.Example:
<label style="font-weight:bold; font-size:120%"><input type="text" name="doge"></label>
It was an assumption of mine that everyone would use classes and ids to style their forms, but I was wrong on that.
The current workaround is to either disable the feature by overwriting the class, or not using inline styles with
%
signs.The proper fix is probably changing the regular expressions, and I suck at regular expressions. Pls help.
https://github.com/libreform/wp-libre-form/blob/master/classes/class-wplf-dynamic-values.php#L6 https://github.com/libreform/wp-libre-form/blob/master/classes/class-wplf-polylang.php#L6
The user who reported this was apparently having this issue with the dynamic values feature, but it's possible that it occurs when the Polylang feature is used, so it's worth taking a look at both of them.