joemoe1984

Ok figured it out. Whoever created the image did something weird to the metadata. Since the imageMagick module is loaded in PHP I decided to download and use the CLI tool to inspect its metadata.

Tutorial on installing and using the CLI tool here: How to view image metadata

Instructions in case the link is broken:

Ubuntu/Pop OS
sudo apt install imagemagick

Fedora
sudo dnf install imagemagick

Using the command:

identify -verbose filename.gif

The result was as follows:

identify-im6.q16: memory allocation failed 'filename.gif' @ error/gif.c/ReadGIFImage/1303

Since this is an issue with the file itself and ImageMagick is unable to create file sizes, the Offload Media plugin does not upload the image to S3. Based on that one condition I posted in an earlier response, it looks like the plugin needs those sizes first in order to upload.

The solution is to redo those images so they work with ImageMagick. Closing this issue now.

• This reply was modified 3 years, 5 months ago by joemoe1984.

Doing some deep diving, I am noticing that WordPress is not creating multiple sizes for the image. This might be causing some issues with the plugin as I am noticing that this condition is returning true:

if ( ! empty( $new_sizes ) && ! empty( $missing_sizes ) && array_intersect_key( $missing_sizes, $new_sizes ) ) {

This returns early and doesn’t actually upload the image to S3.

I am going to have to figure out why WordPress is not creating image sizes for certain images. I turned off all plugins and set the theme to default and its persistent with the bare minimum settings.

If I come up with a solution I will post it here and then close this issue. Just in case someone else has a similar issue.

I don’t see any error in the debug log at all. As far as it looks, it seems like it is uploading just fine from the logs.

I want to post here what the issue was.

It was the query for the shopify id in the postmeta table. When that table grows, the query gets slower and slower. This is why the existing orders were taking a while.

Searching the meta_key and meta_value fields is slow because those aren’t KEY fields in that table.

I would recommend creating a new table that stores the post_id (order id) and the shopify_id and make the shopify id a KEY field so that you can index it quicker to check if something is existing or not.

This is what I did and I dropped the query down from 133 seconds to 0.006 seconds.

People with small stores won’t notice these issues but larger stores will.

@amaule07 If you have a developer that can implement that or check to see if thats whats happening for your issue, I would recommend it.

Cheers.

No, it’s not like that. Unlike products, for orders importing, log file only logs failed orders while successful orders are not being logged. This means that the “6mins just to determine that an order already exists” is totally wrong. A lot of successful orders were imported among that 6mins.

I think you are talking about the error logs but I am talking about your log.txt file in the cache folder. I did a tail -f log.txt within the cache folder as I was importing orders. I was watching in real time those messages logging to that file.

The requests, for 25 orders at a time, are taking close to an hour or longer. So no there are no orders importing during that time. otherwise they would have finished by then and started the next round of 25 imports. Also, the Post IDs are right next to eachother meaning that they were created right after eachother. So its next in line with whats being imported.

The progress bar stays gray until one round of imports is completed, then it turns red showing completed/total. Left it running last night but it stopped at 75/3000 (or whatever the total was) before I was logged out.

I had the Network Tab open the whole time tracking the requests. 59 mins was the last successful request from last night.

I also managed to go from a really long time to import to a more manageable time to import 25 orders yesterday at one point. Not sure if it was the settings I was updating or what, but a request for 25 orders at a time took somewhere between 2-3mins. So there is definitely something going on where its struggling. The server is capable of 2-3 minutes per request which I can live with but not a hour.

(I don’t want to hog this support item so I will look into creating a support ticket for the PRO version. Its possible that whatever issues the OP is having for products might be similar to orders)

I am getting the same issue as the OP.

I am using the 1.0.9.6 version of the plugin.

I only have 25 orders at a time running, and its taking way longer than it should. 2CPUs and 4GB of ram should be enough to at least tackle these in around the 2min mark with no visitors on the site yet.

The backend site comes to a crawl while running this thing too. Frontend is fine because we are using a caching solution to handle that with NGINX.

Here is a short snippet of the s2w log file:

[2021-04-22 17:04:37] Order exists, Shopify Order ID: 3758440710339, WP Post ID: 84409
[2021-04-22 17:10:36] Order exists, Shopify Order ID: 3758446280899, WP Post ID: 84410

Take a look at the timestamps. 6mins just to determine that an order already exists? That seems like maybe there is some inefficiencies in reading the database records in a growing database.

It wasn’t always this slow but it definitely progressively got slower and slower. New orders are happening far faster on Shopify than anything is importing (especially now that it is pretty much not importing at this rate). We can’t even catch up.

Has this plugin been tested on a database with over 50k orders? I feel like 2CPU cores and 4GB of ram should be sufficient no?

One more thing, the Database is AWS RDS so its on a different server. So those resources listed are strictly for PHP, NGINX and Docker

• This reply was modified 3 years, 7 months ago by joemoe1984. Reason: Mentioned separate Database instance

Ok thanks. Marking this as resolved for now since this is being addressed.

Sorry I should be more specific. This is the French Canadian translation file. I just updated to 4.6.6 for the events plugin and it is still not there.

You have the following translated:
fr-ca.po
fr_FR.po

But the one that is missing this translation is the fr_CA.po file.

Ah yes, I am using 0.8. I thought because I couldn’t update it that I had the most recent version but it turns out I have to update through the network admin on a multi site install.

My bad.

It looks like this plugin is pretty inactive. I don’t think this plugin works with the newer WooCommerce versions. I can verify that it doesn’t work with WooCommerce version 2.5. If you have WooCommerce 2.2 you might be able to use this plugin but I would suggest another plugin as you would be stuck at 2.2 for a while until someone updates this plugin.

Hint: it hasn’t been updated in 2 years so don’t get your hopes up with it being updated.

Sorry but do you really think this plugin deserves a 1 star rating based on the fact that it doesn’t auto save when you accidentally close the webpage before you are finished editing?

I have been using the ACF plugin for a little while now and I can honestly say that it is a very well built plugin. Its ease of use is superior to any other plugin you will find in its category.

You can try the simple fields plugin but I think you will have the same issues plus more. At the end of the day you will probably come back to ACF because it really is the best out there.

I tried it with 2.4.6 and I still got the exhausted memory error. I increased the max memory but I don’t think I should have to do that to make it work.

I haven’t had a problem before.

I will do an update tomorrow and let you know in a few days. I will be pretty busy tomorrow.

@trueyouministries and @colourman

Becareful with posting the debugging info. It has the password you entered for your email on the site. That is a hackers wet dream right there.

Edit your post to remove the Password part or edit the password to read “password” or some other placeholder text

No worries. I think the problem might be bigger than expected. Every little thing that I do on the admin side just messes stuff up.

I updated the permalinks in Settings > Permalinks ( I did not change anything just updated) and the whole url structure changed.

What used to be https://website.com/clients now returns a page not found or the 404 error page.

One thing I should note is the wordpress files are not in the root directory they are in a separate folder i.e. ‘wordpress’. I have not changed any of template files or anything that would change the way it used to work before. Everything has broken simply by playing with the admin interface.

I also tried starting from scratch with a new install and using the plugin and importing the pods through the Migrate Package. When I imported the pods I got to see them in the admin panel. I also added in the data through an sql file (just for the pods tables). This worked a little differently then it did before but it was showing up in the admin. I still couldn’t get them to show up in their respected urls.