I'm building a small plugin (WordPress/WooCommerce) that sends order data from a placed order to an external system.
The sequence of the process is simple. When this action is triggered:
add_action('woocommerce_thankyou', array($this, 'xc_woocommerce_thankyou'));
I use wp_remote_post to send the order data to my external system.
The problem is, I'm having to run these tests a lot because I'm pulling data from various metadata sources (from other plugins) in WooCommerce and so I need to test repeatedly. This takes a lot of time as I have to set the cart up again and again before placing the order.
My question: is there a way to "reverse" the "Place Order" so that the cart gets reinstated so that I can run it repeatedly for tests?
woocommerce_thankyou
hook runs every time the thankyou page loads. So process your order and once you land on the thank you page just keep refreshing the page and your method will run each time with the same order number and cart information.
Because of this I would recommend using the
woocommerce_order_status_processing
hook after you have finished your testing or similar as it only runs once. This method also allow you to if there is an issue re-send the order by changing the order status to pending and then back to processing.
Related
I am currently looking into helping someone using Wordpress and Google Sheets. Essentially, they use Google Sheets data as a backend and Wordpress will display that as a table in a post.
The only issue is this data is refreshed every five mins by an add-on they are using. However, it would be best if the data was updated real time. I am a full stack developer, but not overly familiar with Word Press, is there a way to 1) get the table data to update in real time? Or 2) have the table data loaded on page refresh, like a typical UI to backend service call would?
You can use the wp_update_post() function or the REST API at any time to update the content of any page, or if the table is stored in an option, use update_option().
Then, it's just a matter of whether you want to scan for changes on the server side, or can send a webhook of some kind when the row is updated.
I can think of a few options.
Set up a Cron Job at the server level to check the google sheet for changes, and use either function above to update the table. I don't really recommend that for this because it won't be "live" updates, and may run more (or less) often than it needs to.
See if the "addon" can post the updated row to the WordPress REST api (or custom function handler)
Use one of the Sheets Triggers (onEdit?) in the sheet's Apps Script to fire a remote request to your site with the updated row's value (or the whole sheet?) and update it via the REST API or custom function handler with wp_update_post or update_option.
Use a third party "webhook tool" to hook the Sheet to your site. A tool like Zapier or IFTTT comes to mind.
I'd probably lean towards number 3 as it lets you tie straight into the Google Sheet with Apps Script, and POST just the updated row to your WordPress' site via the API, which provides the following benefits:
• Updates your site "live", as soon as an update is made to the sheet
• Doesn't require server-side set up
• Low amount of data transmitted over the wire
• No needless checks/requests
• No other third-party tools required
Woocommerce shipping calculations running too often.
Woocommerce shipping setup works great until you build a custom shipping plugin that uses external quoting systems via HTTP API calls, at which point you realize that the shipping is calculated dozens of times unnecessarily during the order process - slowing everything down.
We make API calls to external servers at our Australian Postal System and also a courier aggregator system to get post and shipping rates. This takes about 5 seconds to complete the two API calls and since the calculate_shipping() function seems to be called on every cart addition & modification, on entry to the checkout page and then on every single keystroke for relevant address fields in the checkout page there are 5-second delays and unnecessary HTTP calls everywhere.
The ajax calls from every keystroke on the checkout page also seem to be queued up and process one after the other so the user can sit watching for 30 seconds while the shipping options are populated then cleared several times before being able to choose one.
Another silly consequence is that the errors that come back from the quoting of an incomplete address end up scrolling the screen up to the top where the notices are being displayed which stops the user from completing typing the address.
So the question is How to stop WC from calling calculate_shipping() until all shipping fields have been completed and maybe the last field has lost focus - or any alternative suggestions to do similar and avoid the multiple calls.
In order to remove the shipping calculations on every cart addition, I have simply tested for the current request URI and return straight out if it is not
if ('https://aaa.bbb/checkout/' !== $_SERVER['HTTP_REFERER']) {
return;
}
Seems to be ok, however, I expect there are some complications later as otherwise why would WC be doing this on every cart addition.
On the checkout, though it's a different story.
I need the shipping to run, but not on every new character typed into an address field as seems to be the default functionality.
There seems to be a timer in play and if you take more than a seconds pause during typing your address it fires update_checkout() or similar which calls calculate_shipping() and I so end up contacting the post servers and couriers servers to ask for a new quote. (they will tire of this DOS attack I'm sure)
I've been looking into the checkout.js script but don't really want to mess with WC functionality and not be able to update so not sure if I want to change this.
None relevant at this stage
What I would like is for shipping not to be calculated until all items are in the cart and the user has finished typing in their address - anything else seems a bit silly.
This question relates to WordPress's wp-cron function but is general enough to apply to any DB-intensive calculation.
I'm creating a site theme that needs to calculate a time-decaying rating for all content in the system at regular intervals. This rating determines the order of posts on the homepage, which is paged to allow visitors to potentially view all content. This rating value needs to be calculated frequently to make sure the site has fresh content listed in the proper order.
The rating calculation is not heavy but the rating needs to be calculated for, potentially, 1,000s of items and doing that hourly via wp-cron will start to cause problems for sites with lots of content. Ignoring the impact on page load (wp-cron processes requests on page loads once a certain interval has been reached), at some point the script will reach a time limit. Setting up the site to use "plain ol' cron" will solve the page loading issue but not the timeout one.
Assuming that I have no control over the sites that this will run on, what's the best way to handle this rating calculation on a regular basis? A few things that came to mind:
Only calculate the rating for the most recent 1,000 posts, assuming that the rest won't be seen much. I don't like the idea of ignoring all old content, though.
Calculate the first, say, 100 or so, then only calculate the rating for older groups if those pages are loaded. This might be hard to get right, though, and lead to incorrect listing and ratings (which isn't a huge problem for older content but something I'd like to avoid)
Batch process 100 or so at regular intervals, keeping track of the last one processed. This would cycle through the whole body of content eventually.
Any other ideas? Thanks in advance!
Depending on the host, you're in for a potentially sticky situation. Let me outline a couple of ideal cases and you can pick/choose where you need to.
Option 1
Mirror the database first and use a secondary app (WordPress or otherwise) to do the calculations asynchronously against that DB mirror. When they're done, they can update a static file in the project root, write data to a shared Memcached instance, trigger a POST to WordPress' admin_post endpoint to write some internal state, whatever.
The idea here is that you're removing your active site from the equation. The last thing you want to do is have a costly cron job lock the live site's database or cause queries to slow down as it does its indexing.
Option 2
Offload the calculation entirely to a separate application. Tracking ratings in real time with WordPress is a poor idea as it bypasses page caching and triggers an uncachable request every time a new rating comes in. Pushing this off to a second server means your WordPress site is super fast, and it also means you can have the second server do the calculations for you in the first place.
If you're already using something like Elastic Search on the site, you can add ratings as an added indexing facet. Then just update posts as ratings change, and use the ES API to query most popular posts later.
Alternatively, you can use a hosted service like Keen IO to record and aggregate ratings.
Option 3
Still use cron, but don't schedule it as a cron job in WordPress. Instead, write a WP CLI routine that does the reindexing for you. Then, schedule real cron jobs to process the job.
This has the advantage of using PHP's command line version, which can be configured to skip the timeouts and memory limits imposed on the FPM/CGI/whatever version used to serve the site. It also means you don't have to wait for site traffic to trigger the job - and a long-running job won't block other cron events within WordPress from firing.
If using this process, I would set the job to run hourly and, each hour, run a batch of 1/24th of the total posts in the database. You can keep track of offsets or even processed post IDs in the database, the point is just that you're silently re-indexing posts throughout the day.
After taking some online tutorials I am willing to create my own custom theme for my myself. This is going to be an online Contact Lense store! So far I have learned how to generate and use Custom Post Types, Custom Taxonamyies, Metaboxes , and Option pages.but there is still one confusing part left for me(hopefully not more! :-))
I need to get some user inputs through HTML Select Options like following image to finalize the users orders:
Now my question is:
1- Do I have to create some thing lik Metaboxes to manipulate these data from users?
2- can I handle these kind of data through simple Form ans Post function in PHP? If so where should I store these data? Do I have to create a table on my own to handle these things?
I really appreciate your time regrading this post,
What you're asking for carries a little more complexity than you think!
Let's break this down into its meaningful steps:
A user visits your shop, and decides that they like what they see and wants to make an order
The user fills out a form defining their exact eye requirements, quantity, as well as their contact information
Upon completing this form, a new order has been created
But wait.... how will you get paid? What happens if the user's computer explodes before the payment goes through? How will you know to send them their contacts without first knowing the payment even succeeded?
This is where things start to get tricky. You need to be able to keep a record of orders for the sake of your users, but you also need to look out for your own interests too. Your business is doomed to fail if you're sending out expensive products to people without the proper assurance that you're getting paid.
This is where you'll need to set up a Merchant Account with a service like PayPal or Google Checkout. As much as I despise PayPal, their Instant Payment Notification (IPN) System has been very reliable for me. What this does is automatically send a POST request to your server with all of the information you need to finalize the checkout process and alert your user that their payment has either succeeded or failed.
So with this in mind, how does this affect our step-by-step process?
A user visits your shop, and decides that they like what they see and wants to make an order
The user fills out a form defining their exact eye requirements, quantity, as well as their contact information
Upon completing this form, a new order has been created with a status of pending
The user is then sent to PayPal/Google Checkout to enter their Credit Card information to complete their purchase
PayPal/Google processes the payment
PayPal/Google sends your server the results of the processed payment
The corresponding order is updated with a status of Payment Received or Payment Failed for your own records
You send out the product to a very satisfied customer
So what will this mean from a Wordpress standpoint?
My first suggestion:
Check if a Plugin already exists that can handle this for you!!!
Seriously, this will make your life much easier. Handling people's money as well as your own stock is a nightmare all in itself, you don't want to be responsible for handling the code that drives it, or the possibility of security holes that you might not know about (that other plugins may have already addressed). WooCommerce is a popular one. See if that can handle what you need.
If a Plugin can't do it for you, then you'll need to:
Register a Custom Post Type for Orders
Create a new Order Post using wp_insert_post when a user submits the form with their POST data
Save the relevant POST data you need as metadata using update_post_meta
Send PayPal/Google/Whatever some Custom Information it needs to hang on to - in this case, the newly created Order Post ID - so that it can send it back to your own server
Set up a side-script to process the data sent by PayPal/Google Checkout/Whatever and send an email to the user detailing the status of their purchase and update the corresponding Order Post ID that was sent back by PayPal/Google Checkout/Whatever
(Optional) Set up a CRON Job to periodically scan all Pending orders in case a user's session was interrupted, or they bailed at the last second during checkout and send them an email notifying them about this and provide them a link to your website to reopen, reevaluate, and resend the order, or cancel and clear it from your database
Quite honestly, this would take even a seasoned Developer at least a few weeks worth of work just to get it in working condition. Presentation is a whole different animal.
Hopefully this will give you a step in the right direction. I doubt anybody here will give you the code to do what you need, because there's just too much to post. Entire libraries are built just for these kinds of things.
Good luck!
Sorry if the title's a bit vaque, I promise I'll clear it up bellow:
First of all, a while ago I asked a question about selling serial keys :
How can I execute a custom script after purchase with Ubercart for Drupal
The information I posted there may help clear things up in this question but I doubt it much because this question is a bit more general.
Basically, I don't want to execute my custom code until I know the payment has been cleared and the moneys in my account. I was a bit unsure what the conditional action thats trigger is 'Customer completes check out' did though? When it says they completed checkout does it necessarily mean successfully and the money is in my account or not?
If not, how do I make Ubercart wait until it knows I've got the money from any PSP (e.g. Google Checkout, PayPal, etc) to execute my custom code? I can't work it out, is it even possible?
It's not documented or exposed as something that should be reliable but I think that using the 'Customer completes check out' trigger is the way to go.
Bear in mind that the following applies to Ubercart 6.x-2.4. (Latest version as of today)
From what I looked at the code, it seems that the trigger is only executed on successful orders. Whether a successful order means that you have received payment, that depends a lot on your current configuration and the different payment gateways or method you are using, but in general situations and configuration.
That trigger is only launched from one function:
function uc_cart_complete_sale($order, $login = FALSE);
If you do a module-wide search on when that function is executed, it should give you a rough idea on the different situations. Basically I found out that it's being executed from a few payment modules (paypal and 2checkout for example) as well as when you reach the cart/checkout/complete drupal page, which is generally on successful orders. The paypal module, which you specifically asked, seems to be calling that function when a 'Completed' IPN status is received.
It shouldn't be hard to try out a few purchases (right and wrong) and see if your trigger executes only when the order is properly charged.