looksink

If you’d like to use an existing Google Ads account, you can definitely link it during the setup.

No, I definitely can’t. Glad to know I’m supposed to be able to, though.

I have access to dozens of Google Ads accounts, but the “Set up your accounts” step of your setup wizard doesn’t let me choose an account. The WordPress.com, Google, and Google Merchant Center sections all have a green “? Connected” status, but in the Google Ads section, there’s just a “Create Account” button.

My Google account is assigned as a user to two different Google Ads manager accounts: a test account that has no active Google Ads accounts in it, and my company’s account. The latter is the one that has access to many active Google Ads accounts. Could this by why your setup wizard isn’t letting me choose an existing Google Ads account? Maybe you’re not checking for Google Ads accounts under manager accounts that I have access to, or maybe you’re only checking the first one, which only has inactive accounts in it?

Thanks!

@simplysaru, what if I don’t want to use Google Ads at all?

Or, what if I want to use Google Ads but I already have a Google Ads account?

Requiring the creation of a Google Ads account doesn’t make any sense.

Thanks for the patch, Jacob! Can you give an explanation of the bug and your patch? I assume from your patch that the form fields were somehow missing an ‘id’ and ‘value’, and maybe these missing entries were causing validation to automatically succeed?

How does the Conditional Logic plugin factor into this? Does it have a bug that causes these values to be removed? Or just never set in the first place?

I also run a website that’s getting Canadian pharmacy spam, despite using reCAPTCHA on the form. Upgrading to Ninja Forms 3.4.24.3 didn’t help.

This patch avoids including pluggable.php. After applying it and re-enabling the Pardot plugin, my non-prefixed password in the database was successfully encrypted and prefixed with NACL::.

I don’t know if it could cause other problems, but it seems to be working for me.

diff --git a/trunk/includes/pardot-settings-class.php b/trunk/includes/pardot-settings-class.php
index e21232a..39cdecd 100755
--- a/trunk/includes/pardot-settings-class.php
+++ b/trunk/includes/pardot-settings-class.php
@@ -1237,4 +1237,7 @@ HTML;
  * Instantiate this class to ensure the action and shortcode hooks are hooked.
  * This instantiation can only be done once (see it's __construct() to understand why.)
  */
-new Pardot_Settings();
+function pardot_settings_instantiate() {
+   new Pardot_Settings();
+}
+add_action( 'plugins_loaded', 'pardot_settings_instantiate' );
diff --git a/trunk/pardot.php b/trunk/pardot.php
index 1a4fefe..269818d 100755
--- a/trunk/pardot.php
+++ b/trunk/pardot.php
@@ -48,12 +48,6 @@ if ( ! defined( 'PARDOT_JS_CACHE_TIMEOUT' ) ) {
 }

-/* This require is needed for wp_salt() which is used in the old method of decrypting if openssl is available
- * otherwise we'll get an undefined function error for wp_salt() during the password reencryption
- */
-if ( !function_exists('wp_salt') && defined( 'ABSPATH' ) && defined( 'WPINC' ) ) {
-   require_once ( ABSPATH . WPINC . '/pluggable.php' );
-}
 require( PARDOT_PLUGIN_DIR . '/includes/pardot-api-class.php' );
 require( PARDOT_PLUGIN_DIR . '/includes/pardot-api-functions.php' );
 require( PARDOT_PLUGIN_DIR . '/includes/pardot-forms-shortcode-popup-class.php' );

• This reply was modified 4 years, 8 months ago by looksink. Reason: WordPress style

Thanks for working on this!

The proposed commit might seem to fix the problem, but I think it could lead to sporadic unexpected behavior.

The old_pardot_decrypt function is called indirectly by the Pardot_Settings constructor, which means that the timing of the require_once line will be more or less the same. Instead of happening at line 55 of pardot.php, it’ll happen at line 62, when pardot-settings-class.php is included, because that’s the file that defines and then instantiates the Pardot_Settings class.

The only difference is that pluggable.php won’t always be included too soon. But if and when it is included too soon, it will still cause conflicts with other plugins.

To avoid conflicts, you need to refrain from including pluggable.php and put off calling wp_salt until after WordPress itself has included pluggable.php. That happens around line 374 of wp-settings.php. Just above this line, there’s a loop that loads all the plugins; just after it, there’s the plugins_loaded action hook. Maybe you could move the instantiation of Pardot_Settings (or at least the call to upgrade_old_password) into a function that you then attach to the plugins_loaded hook?

The hotfix has not been a good solution for me. After commenting out line 55 of pardot.php, my website works fine for a few days, but eventually the fact that wp_salt isn’t defined causes an error, and WordPress stops working. (“There has been a critical error on your website.”) It starts working again if I temporarily uncomment line 55, then disable and re-enable the Pardot plugin. This has happened three times.

The last time I tried commenting out line 55, I first made sure the password stored in my pardot_settings option had one of the prefixes that indicates it’s a new, correctly-encrypted password. It did, so I figured that the old_pardot_decrypt function wouldn’t get called again, and it wouldn’t matter that wp_salt wasn’t defined. But this morning, the error happened again. When I checked the pardot_settings option, I found that the password no longer began with one of the four-letter prefixes.

• This reply was modified 4 years, 8 months ago by looksink.

Same thing happened yesterday on a store I host. Most orders are successful, but one is Pending Payment, and the error message is the same as above. The person who placed the order reports that the transaction is showing on her bank account.

I do see a POST from VISA at the time the order was placed:

198.241.206.38 – – [08/Apr/2019:21:03:54 +0000] “POST /wc-api/WC_Tech_Autho HTTP/1.0” 200 412 “-” “-”

Are there any other logs we can check to provide more information?

WordPress 5.1.1
WooCommerce 3.5.7
Authorize.net Payment Gateway For WooCommerce 5.0

Thanks!

I compared 4.3.2 and 4.3.3 to see what changed. Here’s what I found.

• The plugin now indicates that it’s been tested with WooCommerce 3.5.3 and WordPress 5.0.3.
• The plugin’s description and admin screen were changed to include this message: “New Hash update will be released before Jan 26, 2019.”

So it seems 4.3.3 was a minor release to let people know that the hash update is coming soon.

Thanks for replying, Ishan!

Are you still on track to release an update within the next few days?