DataLife

I don’t, unfortunately. It doesn’t let you edit your reviews after a certain amount of minutes. Otherwise I wouldn’t have needed to triple post earlier :/

Another support agent sent me the documentation.

Can I edit my review?

Sorry for the multiple posts, but it won’t let me edit.

I realized it wasn’t you who mentioned security, but another customer support agent. But my question still stands about any downsides.

Lastly, can you link to the legacy API documentation so I can give it to future developers?

• This reply was modified 2 months ago by DataLife.

Also, is there a downside to using this redirect script for all products, forever?

It would save me money and time in the short-term. However, you mentioned “security” as being a reason PluginEver doesn’t officially offer backwards compatibility with the Legacy API. So should I be concerned using the Legacy API forever?

That’s very nice of you to make the script for me! I will send this to my dev.

Ideally all my future products would use the new API without the layer. So I wonder if this plugin can redirect only requests from a certain user-agent / software? In other words, filter/keep requests from one particular software of mine.

• This reply was modified 2 months ago by DataLife.

Actually, perhaps the actual problem is not the URL, but the response schema of the API. Meaning that the data within the response is accessed differently compared to the older plugin version. The old plugin responds with flat json object, whereas the new plugin seems to respond with multi-level nested data, and our software stumbles and freezes. This is why I asked if there was any change in the response —?are we on to something?

• This reply was modified 2 months ago by DataLife.

Is this better?

// Intercept requests to the old API endpoint
add_action('init', 'intercept_old_api_requests', 1);

function intercept_old_api_requests() {
    if (isset($_GET['wc-api']) && $_GET['wc-api'] === 'serial-numbers-api') {
        add_action('woocommerce_api_serial-numbers-api', 'translate_api_request', 1);
    }
}

function translate_api_request() {
    if (isset($_GET['request'])) {
        // Change 'check' to 'validate', keep other endpoints as they are
        $endpoint = ($_GET['request'] === 'check') ? 'validate' : $_GET['request'];
        
        // Construct new URL for all endpoints
        $new_url = home_url("/wp-json/wcsn/{$endpoint}");
        
        // Preserve all original parameters
        $params = $_GET;
        // Remove 'wc-api' and 'request' as they're not needed in the new URL structure
        unset($params['wc-api'], $params['request']);
        
        // Redirect to the new API endpoint
        wp_redirect(add_query_arg($params, $new_url));
        exit;
    }
    wp_die('Invalid API request', 'API Error', ['response' => 400]);
}

You just repeated the problem back to me, and ignored my questions, which I laid out very clearly in a numbered list.

If I can explain things more clearly, please let me know. Again, we need help with our server-side redirection script, because it didn’t work when we tried it, and we’ve read all the documentation.

• This reply was modified 2 months, 1 week ago by DataLife.

Thank you. We were waiting 3 weeks for basic questions, so we tried on our own and the plugin update took down our desktop software down, and for several hours our user’s desktops would freeze when opening our app.

This is because when we updated the Serial Numbers Pro plugin on our website, the API endpoints changed without our knowledge. I figured there’s no way a company would change a mission-critical API without some kind of versioning/compatibility layer. I trust you have a good explanation for this?

We’re looking for a simple solution to bridge this gap server-side, as it’s impossible to force all our users to update our desktop software simultaneously. Specifically, we need a way to allow our existing desktop software, which uses your legacy API, to work with the new API structure.

We’ve attempted to implement a solution using the following script:

add_action( 'woocommerce_api_serial-numbers-api', 'WCSN_change_action', 1);

function WCSN_change_action() {
    global $wp;
    if (isset( $wp->query_vars['request'] ) && $wp->query_vars['request']=="check") {
        $wp->query_vars['request']="validate";
    }
}

This script allowed our legacy API calls to work with the new API structure for validation. However, our software would still not validate, maybe because of how interpreted the response, even though there is no documented change to the responses. So we had to roll back to SN Pro Version 1.2.0.

Could you please:

1. Confirm if this script should work.
2. Confirm if there have been any changes to the API response structure or content, even if subtle?
3. Provide guidance on implementing a comprehensive solution that ensures full compatibility between our legacy software and the updated plugin?

We’re open to any solution, whether it’s modifying our current script, implementing a more comprehensive compatibility layer, or any other method you recommend.

Thank you for your assistance.

• This reply was modified 2 months, 1 week ago by DataLife.
• This reply was modified 2 months, 1 week ago by DataLife.
• This reply was modified 2 months, 1 week ago by DataLife.

Thanks. I see that when adding it via the button, it uses the MERGETAG instead of the field name. That goes against everything I’ve read about how to use mc4wp over the past two weeks! ??

Anyway I edited the form code you gave me to use the MERGETAG instead, and it works. Then I did the same in CF7 and it works. So we’re good now ??

But, 2 weeks to delete a hyphen. This plugin is great, and it’s free, but that seems like something you (or mailchimp?) might want to fix! Because I did everything according to the guides. Unless I missed something, which is entirely possible.

• This reply was modified 7 months ago by DataLife.

I see, I had to turn off double-optin on the mc4wp settings and now I can signup.

I tested the form with the new line you suggested and same thing: name/email are going in, static custom field isn’t.

Thanks again for your help. Let me know what you want me to try next…

• This reply was modified 7 months ago by DataLife.
• This reply was modified 7 months ago by DataLife.
• This reply was modified 7 months ago by DataLife.

Oh, click the link I put in the last post. The top form is CF7.

Also I’ve been checking the log the whole time, there are no errors.

• This reply was modified 7 months ago by DataLife.

(So the mc4wp form isn’t working even in its default state, oddly.)

Thanks for your continued support.

1. The field doesn’t work with that formatting: https://shaina.link/deleteme

View post on imgur.com

2. Weirdly, even after removing the field, the mc4wp log shows submissions are successful, but *nothing* is showing up in Mailchimp, not even the name/email. I tried this 3 times.

• This reply was modified 7 months ago by DataLife.
• This reply was modified 7 months ago by DataLife.
• This reply was modified 7 months ago by DataLife.

Thanks. Okay I spent a bunch more time on this, and now have the field value properly populating inside the form — you should be able to see it. So what do I need to do to have mc4wp send it to Mailchimp? I’m now trying both of these to see if anything sticks in Mailchimp:

[dynamichidden unique-link "custom_unique_link"]

[dynamichidden mc4wp-unique-link "custom_unique_link"]

As always, CF7 is submitting the fields properly. So it’s just a matter of getting mc4wp to send the custom field to Mailchimp.

What would be amazing is if the mc4wp log would let us see what it’s receiving/sending to Mailchimp, but maybe it’s a niche request ??

• This reply was modified 7 months ago by DataLife.
• This reply was modified 7 months ago by DataLife.