joshuaiz

Hi @jillmolloy. I ended up staying with rolling back to the 4.1.8 Stripe Add-on to make it work with WC Rest Payment.

Unfortunately, it doesn’t look like WC Rest Payment is being updated or maintained and after having a look through the plugin code, there didn’t seem to be anything obvious to fix.

I also contacted WooCommerce support and while they were helpful, didn’t seem eager to want to fix this. In fact, they stated that the WooCommerce support for the REST API was not intended to be used for payment(!?). If you can’t create a working store, what is it for then?

Rolling back to 4.1.8 of the Stripe Add-on is only a temporary solution so what I’m planning is to port everything over to WPGraphQL and bypass the REST API entirely.

There’s a WooCommerce plugin for WPGraphQL that is still in early stages but I’m following the development on Slack and it’s coming along: https://github.com/wp-graphql/wp-graphql-woocommerce

Hello,

I can confirm that my transaction flow was broken with WooCommerce Stripe 4.2.3 in my headless WP + WooCommerce + Stripe app.

Rolling back to WooCommerce Stripe 4.1.8 fixed it.

In my case, I was getting a resource_missing error and what it looks like is that the token is created but by the time the request is sent to Stripe from WC, the token is invalid.

Or, the new plugin is requiring createSource instead of createToken and thus something is missing when the request is sent to Stripe with only a token.

In any event, this is a breaking change and should be looked into as my transactions were failing 100% of the time with 4.2.3 and not at all with 4.1.8.

Thanks!

I’m happy to file a separate issue on GitHub with more info if that would be helpful.

Cool…thanks for the update.

All that said, tried some of the other file manager plugins that seem to use the same interface (but are not as good) and their drag-and-drop was working so maybe see how they did it.

One I looked at was this paid plugin on CodeCanyon: https://codecanyon.net/item/file-manager-plugin-for-wordpress/2640424

…which had drag-and-drop working but was not as easy to use as yours ??

Thanks!

This is resolved. Had to uncheck Force Inline. D’oh!!

Thanks – use this plugin on every site now!

Just use this on line 191 of itap-settings.php:

@do_settings_fields('import_tweets_as_posts-group', '');

with an empty second argument and then the plugin settings will load.

Had to completely delete the user and re-authorize with Instagram. Now it is importing correctly.

Perhaps Instagram changed their authorization protocol so I suggest doing this if you are not able to import

Ahhh found it using the relevanssi_hits_filter here:

add_filter('relevanssi_hits_filter', 'pages_first');
function pages_first($hits) {
    $types = array();
 
    $types['page'] = array();
    $types['post'] = array();
 
    // Split the post types in array $types
    if (!empty($hits)) {
        foreach ($hits[0] as $hit) {
            array_push($types[$hit->post_type], $hit);
        }
    }
 
    // Merge back to $hits in the desired order
    $hits[0] = array_merge( $types['page'], $types['post'] );
    return $hits;
}

Yep browser cache completely cleared including all cookies. Tried with a fresh browser: I have Safari, Safari Dev Preview, Chrome, Chrome Canary, Chromium, Firefox and Firefox Nightly.

Clearing cache and cookies with a fresh browser then loading the page shows this behavior and is repeatable.

See here:

Before cookie is set (showing unfiltered custom post types and excluded categories):

After viewing a page and cookie is set; posts are filtered as per widget settings and showing posts correctly:

Ideally you would only need to generate retina images since the last migration as the rest would have already been generated.

Alas, since there is no db entry there is no way to check to see which images need to be generated.

This might be a little crazy but I also use EWWW Image Optimizer along with your plugin and EWWW does record what images have been optimized in the db so conceivably you could use those entries as a check but I’m assuming that anything like that would be super hacky.

Hi Jordy!

Thanks for the reply. After speaking with Delicious Brains they basically suggested the same thing.

So is there some kind of action I could fire to automatically regenerate (or generate) the retina images on the target site once the migration is done using the wpmdb_migration_complete hook?

Then this could be automated every time a migration is run.

User error in my case – retina images were on my local install but not on my live site.

Same issue for me – completely stopped working as of the latest update. No srcset images are added.

Hey Jeff,

6.0.8 seems to fix the issue. Thanks so much and sorry to be a PITA.

Marking this as resolved.

Strange. The file is there. The plugin directory and /lib directory are 755. The files themselves are 644.

I upgraded the plugin through the WP admin normal updater.