Signature
do_action( 'mam_ride_share_driver_update' );No PHP arguments. The contract is in the request and the acting user’s state:
| Input | Source | Description |
|---|---|---|
| Acting user | app token (mam_user_id()) |
Must have the driver role (or manage_woocommerce, or mam_wc_delivery_driver_home_screen returning true); otherwise responds Not authorized. |
actual_lat / actual_lon |
request | Driver GPS; validated to ±90/±180 (out-of-range becomes 0). |
current_assignment |
user meta | The driver’s active order/task id; a stale id pointing at a deleted order is treated as none. |
The hook name is shared with mam-woocommerce-ride-share: both plugins implement the same home-screen button subaction, so a driver app build works against either workflow.
What it does
The driver home screen’s button (sub_action: mam_ride_share_driver_update) posts here on every tap:
No active assignment → punch toggle. Toggles tsl_activity_user_is_punched_in (1 on duty ↔ 2 off duty) and stamps tsl_activity_user_active_date with the site-local date. This is the Go on Duty / Go off Duty flow.
Active assignment with no transport_status yet → sets it to order_en_route and notifies the customer (wc-rc-driver-enroute).
Active assignment in a trip → advances one trip stage per tap, stamping each stage with time + GPS and notifying the customer where noted:
Current transport_status |
Becomes | Meta stamped | Customer notification |
|---|---|---|---|
order_en_route |
Enroute to Pickup |
enroute_to_pickup (time/lat/lon) |
wc-rc-driver-enroute |
Enroute to Pickup |
Arrived at Pickup |
arrived_at_pickup |
wc-rc-driver-arrived-at-pickup |
Arrived at Pickup |
Departed Pickup |
departed_pickup |
— |
Departed Pickup |
Arrived at Destination |
arrived_at_dest |
— |
Arrived at Destination |
Completed (order → Completed) |
trip_completed; current_assignment user meta cleared |
wc-rc-driver-completed-trip |
Each advance also writes a Product Vendors order-history line (mam_wc_pv_order_history). If the current assignment isn’t assigned to the acting driver (assigned_to_driver / driver_id), the handler requires mam_wc_delivery_user_can_manage_transport and otherwise refuses.
The driver’s last reported GPS is stored per driver in the last_driver_location user meta (['lat' => ..., 'lon' => ...]).
The response is {"status":"success","jsonData":<refreshed phone data>} — the refreshed phone data is what flips the home-screen button to its next title (Arrived at Pickup, Departed Pickup, …).
Notes
- This trip ladder is distinct from the check-in ladder in
mam_check_in— it is the ride-share-style stage machine used by the driver home screen’s single-button flow; the open/available order lists advance viamam_check_in. - The handler terminates the request (
wp_send_json+die()). - Interop: mam-woocommerce-ride-share registers its own handler on this same hook and shares the driver contract (the same button subaction,
current_assignmentand punch user metas, and thedriver_id/transport_status/etaorder metas). Because both handlersdie()after responding, whichever responds first wins — run one of the two plugins as the fulfillment owner per app.
Related articles
- Recipe: Set up delivery drivers
- Hooks:
mam_check_inand order advancement - Plugin: mam-woocommerce-delivery
Metadata
| Field | Value |
|---|---|
| Article type | Hook Reference |
| Plugin slug | mam-woocommerce-delivery |
| Applies to plugin version | 1.4.1+ |
| Category | Extending MAM Suite |
| Hook type | request-driven handler (registered on the mam_ride_share_driver_update hook; dispatched as an app api_call subaction) |
| Audience | PHP developer |
| Last verified | 2026-06-10 |
