lneve

It’s all a ton of work converting my code. I’ll stick with the old version of this plugin.

Oops, my old insert_php code should have been:

[su_row][su_column size=”2/3″]
[insert_php]
echo “Hello World”;
[/insert_php]
[su_column size=”1/3″]
[insert_php]
echo “Goodbye World”;
[/insert_php]
[/su_column][/su_row]

Here is my old insert_php code:
[su_row][su_column size=”2/3″]
echo “Hello World”;
[su_column size=”1/3″]
echo “Goodbye World”;
[/su_column][/su_row]

It prints out:

Hello World Goodbye World

You say to convert it to a snippet like so:
$blockA = ‘echo “Hello World”;’;
$blockB = ‘echo “Goodbye World”;’;
$html = ‘[su_row][su_column size=”2/3″]’ . $blockA . ‘[/su_column]’;
$html .= ‘[su_column size=”1/3″]’ . $blockB . ‘[/su_column][/su_row]’;
echo do_shortcode($html);

This results in:

echo “Hello World”; echo “Goodby World”;

That’s obviously not what I want.

“something A” and “something B” are two blocks of PHP commands. They can’t just be concatenated and assigned to $html as you do above. What am I missing?

I see the problem. With do_shortcode you need to include both the opening and closing tags. That’s why they were acting weirdly.

So my problem is that I have a lot of content like this that worked just fine before but which I don’t know how to easily convert to use your 2.x plugin:

[su_row][su_column size=”2/3″]
[insert_php]
BLOCK A
[/insert_php]
[/su_column][su_column size=”1/3″]
[insert_php]
BLOCK B
[/insert_php]
[/su_column][/su_row]

Block A and Block B need to share variables and could easily do so before. But now I have to create separate snippets for them in 2.x and so they can no longer share variables. Is that correct? Is there any way to put both blocks in a single snippet?

SOLVED: I thought I had tried this but apparently not. I simply had them configure our proxy with *.google.com and then added the WP_PROXY_HOST and WP_PROXY_PORT to my wp-config.php and now everything is working. Thanks everyone for their input. It all helped.

What I don’t understand is why the server firewall even comes into play here. The browser communicates with Google from within an iframe, right? So isn’t all the recaptcha traffic to and from the browser?

So how did you fix your problem, ultimately. Did you just open up the server firewall to google.com? I’m ready to try that if that worked for you.

The staging website works but the production website does not. Both use exactly the same code and database (it’s copied over). So it can’t be any of the themes or plugins. Could it be something about the production website not allowing direct outbound connections (it’s behind a proxy). But the recaptcha gets a green check mark, so it’s working fine. What else relies on outbound connections?

I have the same problem. I remove recaptcha and everything works. I have none of Akismet, cache plugins, non-empty comment blacklist.

We don’t want some fix that will be overwritten by an upgrade. We want a real fix.

This same problem as plagued me for years. I have cleared the cache and it doesn’t help. I have also checked it in a private window and the behavior is the same. Why would you expect different behavior in a private window?

A “false positive” would be where the compatibility checker says it’s not compatible but it still works perfectly well. My tests show that the compatibility checker is correct and it will not run with PHP 7. So it needs a fix.

It is NOT a false positive. We upgraded our development instance to PHP 7 and upon finding that SU wasn’t working, had to back it out. We await a fix, but as far as I can tell haven’t heard anything from the authors.

Ditto here.