Can anyone please explain why Magento runs order email in cronjob?
I set up cronjob to send email every 5 minutes.
Is there any issue if I switch to instant sending the customer an instant email confirmation?
My customer asks why he can't receive the order confirmation instantly.
Can anyone please explain why Magento runs order email in cronjob?
Well their changelogs don't really explain why, but generally the reasons for moving processes to a cron job are:
It goes from synchronous to asynchronous
The processing time doesn't matter as much
The web server doesn't need to handle it (timeouts may not be relevant, memory limits may be larger, interference with the web server pool may be lessened)
I set up cronjob to send email every 5 minutes. Is there any issue if I switch to instant sending the customer an instant email confirmation?
Not really, no. Other than that it would be a regression in Magento capability. If you take the checkout process for example, when you place your order there is a variety of things that happen; save quote, convert quote to order, prepare payment, capture payment, create invoice, save everything, etc... In this case they've taken the time it takes to generate and send the order email out of this process to improve the checkout speed.
Yes - you can put it back to being sent instantly if you'd like, but my suggestion to you would just be to run your cron every minute instead of every five minutes.
Generally you should employ a rule of "try not to touch core Magento functionality unless you have to.". Hope this helps!
Related
I am experiencing a very frustrating issue with SagePay Direct when a card payment initiates a 3DSecure challenge.
Customers are reporting either a hanging iFrame, or payment declined response. Whats worse is that in some instances, Sage takes the payment but the user is unaware of this and tries to buy again
Looking at my logs my code is working as expected and is loading the iFrame with the returned ACSURL as the src.
After searching the web, it appears it is a known issue with a timeout occurring on the secure merchant issuer that i hand off to.
The trouble i have is that i have no control of the response(or lack of) from the issuer as its in an iFrame.
Sage have not been very helpful with this problem only going as far as to say "we have heard of customers who experience this issue"
Does anyone have any experience of this problem and know how to resolve it? I guess the bottom line is to turn off the 3DSecure checks but this seems counter productive to the new EU ruling coming into force at some point.
Worth pointing out that this is only affecting a small percentage of my customer base and a lot of transactions are processing successfully (even with the password challenge) but the customers who experience problems are rightly shouting loudly.
anyone any ideas?
Thanks
We process up to 1000-2000 transactions daily via SagePay, using the Direct protocol. They are very cheap but their service is in all honesty fairly terrible. We have a single digit quantity of transactions every day that fail in this way. We've also got another provider and don't experience the same issues.
We have a routine job that asks the SagePay Reporting API about transactions that failed, to see what the current status is (did SagePay get the transaction? was it successfully authorised? etc). This API is utterly, utterly terrible and was a nightmare to integrate with, but it's useful as at least we can refund customers without having to log into the SagePay dashboard.
One thing that we discovered (that isn't documented anywhere on the SagePay site as far as I can tell) is that you're limited to one transaction at a time, or around 20-30 transactions per minute by default. If you go over this (a temporary peak or whatever) your transactions queue up and are delayed. If it gets really busy it completely falls over, and takes a while to recover. We had to switch SagePay off entirely for a few hours due to this (we've got backups in place).
Anyway, so it turns out our transactions were all being processed on one TID (short for Terminal ID). This is akin to a physical card terminal in a shop which can only process one transaction at a time. We asked SagePay support for more and we now have 10-15.
I hope this helps you. I'd recommend implementing a fallback payment supplier in case SagePay fails. A year or two ago they had a 3 day(!!!!) outage which was fairly devastating for us. We now take this seriously!
We've recently had an increase in what I believe may be the same thing. Basically the customer would be sent off to the 3ds page, then returned to the callback page, but for reasons I can't explain the PHP session wouldn't reestablish. The POST response to the callback page was enough to identify the order and complete it (as we'd taken payment), but the customer would then subsequently be prompted to log in again - they'd then see their basket as still having products in and place a second order (that would go through successfully).
After many hours debugging and making changes I managed to replicate this on a development server whilst using mobile emulation...
Long story short, what I have done is to add:
session_regenerate_id();
When I perform the initial vsp register CURL (this is the CURL where you get given the ACSURL). So far, this seems to be enough to ensure that the session gets reestablished when the customer returns to the callback page.
Hello fellow programmers. I google it before posting! Still confused about .
So here is the idea.
Users are planning post to be posted on their social media (concrete time ).
They can change post time even 2 minutes before . Cron would work as expected if it run every minute ,but it seems old solution. On the other hand queue works different (as far as I get) , trying to make better performance which means if there are high number of requests it will not post !!
Is there anything I am missing???
Thanks in advance
I personally prefere old and reliable concepts over new and unreliable one.
About cron - I did set it to run regularry user script (under the user account) and then user can modify that script how often he wants and cron runs it regularry without need for reloading configuration. And the user script can do anything user can - so it can check if time is larger than some value and some unsent messages are pending and eventually send everything needed. So even if it fails send on scheduled time (maybe server down or anything else), it would be send next time the cron hits (maybe every minute)
I am in a bit of a bind and not too sure where to start with this..
I have a model that stores a users Drivers License info and it is nested to an Admin user, to be able to create it from the admin show page.
what I am looking to achieve is a query that validates todays date against the expiry date of the license. And then use that information to send a notification to the proper person. i will re use this to send a notification one month out that the license is about to expire...
My biggest problem is how to actually query this, i am not sure if a cron job is in order or if this can be done in the controller directly? I've read a few articles where it was either or but I've never done a cron job in the past.
Any help here would be greatly appreciated.
Consider sidetiq gem
It's workd together with Sidekiq and allows to perform some periodic jobs.
That's pretty simple to implement and manage.
Also you can give a try to whenever but it's just a cron wrapper.
I strongly recommend to use sidetiq.
General approach
Just implement some daily job which will:
collect drivers licences you need to notify users about
notify users with any prefferied way :)
Also please note that all that jobs will run in background.
You can find more info in sidekiq and sidetiq wikis.
Use a StackOverflow Q&A thread as an example - when you vote up, vote down, or favorite a question, you can see the UI quickly respond to that action with changes in the # of up-votes on the side.
How can we achieve that effect? If send every of such action to back-end for processing and use the returned response to update UI, you will see a slow update and feel the glitches. But if put some of the logic on the front-end, you will also need to take care of the fraud/abuse etc before reflecting the action on UI, i.e - before changing the # of up-votes, don't you need to make sure that's a valid click by an valid user first?
You make sure that a valid user is using the app before a user clicks on anything. This is done through authentication, and it must include various protection mechanisms against malicious users.
When a user clicks, a call is made to a server. In a properly architected app this call is lightweight, and the server responds very quickly. I don't know why you believe that "you will see a slow update and feel the glitches". Adding an upvote to the database should take a few hundred milliseconds at most (including the roundtrip from the client), especially if the commit is asynchronous or a memcache is used.
If a database update results in a need to do some complex operations, typically these operations are not done right away. For example, a cron job may run periodically to compute new rankings, etc., precisely because you do not want every user to wait. Alternatively, a task is created and put in a task queue to be executed when resources are available - again to make sure that a user does not wait.
In some apps a UI is updated immediately after the call to the server is made, before any response from a server arrives. You can do it when the consequences of a failed call are negligible. For example, if an upvote fails to be saved in the database, it's not a disaster, especially if it happens once in a million tries. Again, in a properly architected app calls fail extremely rarely.
This is a decision that an app developer needs to make. I would not update a UI before a server response if such an update may lead a user to believe that some other action is now possible. For example, if a user uploads a new photo, I would not show icons to edit or share this photo until I know that the photo is safely saved.
I am getting started on Heroku and concerned whether it will charge me for a mistake I do. For example, filling up the database over 5MB.
So, is there a way to set billing limit to an Heroku or notification system to send a notification when I go over the price limit?
Thank You in Advance!
Dont think so. But heroku only bills u if you actually signed up for something, like an addon, that is non free. If you use up 5 megs of database, they would send u an email telling you that you are over the limit, and would simply stop all INSERT operations to the database.
Another thing to note is not to leave heroku console on longer than necessary, since that requires another worker and is billable.
All limits are soft limits. The new row limits imposed on the database plans if exceeded will trigger an email notification for you to take action.