s2If php condition with "higher than" not working

[clavaque]

@jaswsinc I tried this in my clean installation:

[s2Get constant="S2MEMBER_CURRENT_USER_REGISTRATION_DAYS" /] 
[s2If php="S2MEMBER_CURRENT_USER_REGISTRATION_DAYS > 10000"]bigger than 10000[/s2If]

And it outputs this:

423
bigger than 10000

I also tried something obviously very wrong like:

[s2If php="400 > 10000"]bigger than 10000[/s2If]

And that also outputs "bigger than 10000".

Here's the related ticket: https://websharks.zendesk.com/agent/#/tickets/3815

[clavaque]

Could s2Drip also be affected by what's causing this problem in s2If's PHP condition?

[jaswrks]

Thanks for the report! Taking a look now.

[jaswrks]

Hmm. WordPress is parsing the shortcode attributes into the following, for some reason.

Array ( [php] => 400 [0] => > [1] => 10000″ )

[jaswrks]

Could s2Drip also be affected by what's causing this problem in s2If's PHP condition?

That is possible. I'm taking a closer look at what's changed in WP v4. It seems there is a problem with the > symbol, at the very least.

[clavaque]

Array ( [php] => 400 [0] => > [1] => 10000″ )

That's so weird...

taking a closer look at what's changed in WP v4

Great, thank you! :)

[jaswrks]

Internally the shortcode is becoming the following (for some reason), which explains why we see the attributes being passed incorrectly. This seems like a WP bug to me, but I'm taking a look at the reasons why this is happening.

[s2If php=”400 > 10000″]

[clavaque]

Okay.

[jaswrks]

The wptexturize filter is to blame for this, it seems.
Here is a quick fix while I investigate further.

remove_filter('the_content', 'wptexturize');

[jaswrks]

Referencing: http://codex.wordpress.org/Plugin_API/Filter_Reference/no_texturize_shortcodes

[jaswrks]

Referencing: https://core.trac.wordpress.org/ticket/29608

[clavaque]

The wptexturize filter is to blame for this, it seems.

Maybe related: #343

[jaswrks]

This is a WordPress bug that has been fixed (https://core.trac.wordpress.org/ticket/29608). Hopefully we'll see this fix in a new release shortly. It it scheduled for release in WP v4.0.1.

For now, using a > or < symbol in a shortcode will result in unexpected behavior. A short-term fix is to create this directory and file: wp-content/mu-plugins/wp-bug-fix.php.

<?php
remove_filter('the_content', 'wptexturize');

BTW, turning this filter off speeds up your WP installation and will result in fewer headaches, even after the bug has been resolved. I turn this off on every WP install that I have anyway.

[clavaque]

Cool.

Maybe we can add a setting in s2Member -> General to disable it, making it easier for site owners to have control over it.

It'd also affect how the rest of their content will look, though, right?

[jaswrks]

It'd also affect how the rest of their content will look, though, right?

Yes, but only in very subtle ways that are mostly related to fancy quotes. No biggy.

Installing this plugin will fix the issue in WP v4.0:
https://wordpress.org/plugins/quotmarks-replacer/

[clavaque]

Great! Thanks for the workaround! :)

[clavaque]

It'd be good to write a blog post about it with your finding and the workaround, so it goes out to those in the email list to be aware of. And we could also add a note about it in the next release, even if nothing changed in s2Member, so that others that aren't in the list can find out too.

[jaswrks]

Referencing: http://codex.wordpress.org/Shortcode_API#HTML

[jaswrks]

This bug did not get fixed in WP v4.1 either.

To prevent further reports of this problem and broken shortcodes that use >< symbols, I am updating the s2Member codebase so that wptexturize is removed automatically when s2Member is running.

[jaswrks]

Next Release Changelog:

• (s2Member/s2Member Pro) WP Core Compat.: This version of s2Member forces the wptexturize filter off in WordPress, due to a bug that was introduced in recent versions of the WordPress core; which results in broken shortcodes in some scenarios. Until the underlying bug is fixed in the WP core, the wptexturize filter must be disabled to prevent corruption of any WordPress shortcode that may contain < or > symbols.

  See this GitHub issue for further technical details. Also referencing: this WordPress core bug report.

[jaswrks]

Work from this issue went out with the release of s2Member v150102.
http://www.s2member.com/changelog/#s2-changes-v150102