GrahamWharton

Members
  • Content Count

    13
  • Joined

  • Last visited

  • Days Won

    2

GrahamWharton last won the day on February 21

GrahamWharton had the most liked content!

Community Reputation

2 Neutral

About GrahamWharton

  • Rank
    Member
  1. I don't think M2ePro is compatible with Magento 2.3 due to the introduction of MSI, which M2ePro doesn't support. That being said, the problem you are seeing above, is most likely due to a lack of static content being deployed.
  2. I asked them recently and the reply I got was that they pretty much don't know when it will be released. I also notice that the latest release is tagged in github as "1.3.5 (FINAL RELEASE)". I wonder what the relevance of FINAL is?
  3. Yes I noticed that the m2e cron servers were constantly prodding my server to trigger the m2e cron job every minute. I've currently got them banned by my firewall to stop them from triggering the cron. If you allow the m2epro cron service to trigger your cron jobs, are they triggering only the cron jobs for m2epro, or are they triggering all Magento cron jobs? i.e do you still need a method of triggering the rest of Magento's crons. What url do they use to trigger? Looking at the m2epro code though, if your php max execution time is >= 300s and the cron is triggered by the front end and not the cli/crontab (because max execution time = 0 for cli/crontab), then no matter the method of triggering (and I would imagine also included in this is the m2epro cron service) then the random delay of 0-60 seconds is added to every cron execution. I'd still much rather trigger the cron jobs myself though. My system is in the Google cloud, and I use the Cloud Scheduler to ping off a request to /cron.php through my front end load balancer, so a random frontend will be chosen to run the cron every minute. That works really well for me. I've dropped my php max execution time to 299 seconds for the cron.php script and that gets rid of the random delay, so I'm happy. (although max execution time should really be a lot lower than that for the cron!)
  4. Interestingly, as max_execution_time is always 0 for cli, the load distribution will only ever come into effect when running cron by triggering http://<frontend>/pub/cron.php
  5. OK, tracked this down eventually, and it is by design. The M2ePro cron module tries to be clever and applies a random delay to the start of the cron jobs in an attempt to distribute load on a server. It only does this load distribution under certain conditions. If you are in developer mode, it does not distribute load. If the php max_execution_time setting is under 300 seconds it does not distribute load. To distribute load, each cron job is delayed by a random delay anywhere between 0 and 60 seconds. This is pretty poor in my opinion. What happens if the cron job is deleyed by 59 seconds. It will most likely still be running when the next cron initiation is attempted resulting in skipped crons. Time for a module override me thinks to get rid of this pesky load distribution. This should really be a setting that we can turn on/off.
  6. Firstly, the sending of emails with the from address not set, or set to your account, e.g www-data@ is a bug in Magento. It is due to be fixed in the next release. There are fixes available on github. https://github.com/magento/magento2/pull/18472 https://github.com/magento/magento2/pull/18471 With regard to your issue concerning the emails being sent, I too had this happening recently. Ive been running my store for over a year now and it has never happened but totally randomly (or more probably related to something else I was tweaking) Magento started sending customers confirmation emails when the order was dragged down from ebay into Magento. And then after a couple of days, it stopped doing it and has never done it since. I have, and always have had auto invoice turned on. I've never got to the bottom of why it started, and why it stopped.
  7. Magento 2.2.7 Ess M2ePro 1.3.5 I've been noticing that my cron jobs on Magento are taking a long time to complete. I run the job using an HTTP get request to https://<server>/pub/cron.php every minute. See the screenshot for timings for the M2ePro module. My store only has 80 items listed and only perhaps 10-20 sales per day, so can't see why it should be taking so long. Anyone seeing anything similar before I dive into a deep debug. Cheers Graham
  8. Yeah, sorry. I should have come back and updated this. It is indeed working now.
  9. I have a feeling this is ebay's problem. Seems to work ok on my dev install getting a token from ebay sandbox.
  10. Magento 2.2.7 M2Epro 1.3.5 Click Get token Enter ebay username and password Click Login I am presented with the ebay homepage with the address bar showing "https://www.ebay.com/n/error?statuscode=500" My token is not renewed. Anyone else able to renew their token? I guess my integration will stop working when the token expires in 2 weeks.
  11. Hi, Has anyone else noticed the following behaviour in M2ePro 1.3.3 Import order from ebay where order country is set to a country that requires state/region in Magento (i.e has a drop down list of regions) and the ebay order does not have the region set, or the region does not match one of the items on the Magento drop down list. The order will be imported, but M2ePro will silently set the region on the order to be the first region on the Magento list regardless of whether it is right or not. Quite a few of the countries that have preset regions, dont actually use them anymore and are rarely entered by users, therefore for all of these items the region is incorrectly set by M2ePro. The countries affected by this are USA Canada Germany Austria Switzerland Spain France Romania Finland Estonia Latvia Lithuania Brazil Croatia India This has resulted in several packages of mine going missing. I noticed as I had several packages destined for Spain that all went missing, and then I noticed that the address had incorrectly had "A Coruña" added to the shipping address. I checked the M2ePro code and traced it, and it looks like for eBay orders it is done on purpose. For Amazon orders in M2ePro if the region is not set and is required, the order is not created, but for ebay it just silently sets it to the first region and creates it. I wrote an addon module that overrides this behaviour and if it finds the region is not set but is required it refuses to create the order, and it then logs a critical notification so the Magento operator is alerted to the fact that they need to go in and set the region manually in order to create magento order. I wonder how many people are sending orders out to the wrong address because of this.
  12. I really do wish this could be fixed soon. Running Magento CE 2.1.8 and M2EPro 1.2.1. It adds a new tracking reference every 6 minutes. It only adds the tracking reference for the last order created. This means if you get two orders in quick succession, then chances are the second but last order won't have many duplicated entries against it, but if there is a big gap between orders then the second but last order will have a lot of entries.... If that makes sense. Having a new entry added to the database every 6 minutes means 87000 odd entries every year your shop is running which are needlessly being added to the database, not to mention rendering your packing slips utterly useless. I see no option other than to stop adding tracking information in ebay which is a pitty. Regards Graham