Find a WooCommerce order missing from the administration list

Identify the correct store and order

Under WooCommerce > Orders, first record the administration domain and network subsite, if any. Retrieve the number the customer saw, checkout time and, if available, the WooCommerce order reference. A displayed number may be customized by a plugin. A payment, invoice or cart reference is not necessarily the order's numeric ID.

Open the All tab, clear search and remove date, customer and status filters. Also check Trash if displayed. A filter for Completed orders hides a Processing order even when its ID is correct. Try a known neighboring order to verify that the screen lists data for this store. The first expected result is knowing whether the absence concerns one order, the account or the entire list.

If an authorized shop manager finds the order while another account cannot access the screen, inspect the second account's permissions. Do not assign Administrator just for this check. If both authorized accounts observe the same discrepancy, request a read by ID in the storage WooCommerce uses.

Approach 1. Start again from the list and order record

This procedure requires an account authorized to view the store's orders. Open WooCommerce > Orders from that store's menu without reusing an old bookmark. Check the site name at the top of administration. On a network, open administration for the subsite that received the order. An account authorized on another subsite may display a working list without this sale. Then record the selected status, month, customer filter, search field and page number.

Reset filters to All dates and All customers if available. Clear search, return to the first results screen and choose All. If several pages remain, then search by reference in this cleared list. Test the same method on a neighboring order whose time and number you know. A search unable to find even the known control cannot establish that the first order is absent. In that case, check the search criterion, screen type and any remaining filters.

If an internal link to the order record already exists in a working note or authorized export, open it from administration on the confirmed domain. The expected result is the order record with its status and date. An on-screen order number may differ from the storage ID, especially with custom numbering. Record the identifier from the order-record link or a recognized export. Avoid deriving it by stripping letters from an invoice number. If only a commercial number is available, ask the maintainer to find the mapping through the mechanism assigning it.

An order in Trash requires another check. Review status and history before restoration. It may be an intentional deletion or a duplicate already handled. A draft from block checkout may also exist in storage before the customer confirms the order. Finding that draft does not prove an order was placed. Compare its status, checkout traces and the number of the actual object the customer believes they confirmed. The first approach ends when you find the record or isolate a filter, access issue or absence requiring another investigation.

Choose the correct control when searching is ambiguous

If the customer has several nearby orders, compare creation dates and totals in records already accessible to the authorized person. Use the store's displayed time zone. An order created near midnight may fall on the next day in UTC logs and appear on another day or month than the customer indicated. Before concluding that a date filter hides data, remove it and then check the record's time. Payment or shipping date is a different field. In versions offering a date-type selection for the filter, record the value chosen for comparison.

If the customer filter finds nothing, check whether the sought order was linked to an account. A guest order may be associated with a billing address without belonging to the registered account selected. The My Account list shows the logged-in customer's path. It does not replace checking the store or a manager reading the order. First compare a known order of the same type, guest or account-linked, with identical search parameters.

If the number came from an invoice or refund, request the original order's identifier. Do not choose a record by numeric proximity. Numbering plugins and accounting documents may use their own sequences. A record separating number, ID and object type avoids modifying another purchase's record.

Separate list permissions from data

Ask an already authorized shop manager to repeat the search on the same domain with the same parameters. Keep the original account available for the final check. If the manager opens the order while the original account receives a denial or cannot see the section, consult Users > All Users with an authorized administrator to confirm its role. A role plugin, access limited to certain orders or an administration customization may impose another rule. Give the administrator an example of a visible and hidden order without transferring personal data they can already read in the store.

Comparing accounts requires neither sharing a password nor making the original account an administrator. If access is genuinely missing and site policy permits it, correct the capability or role through the intended channel while retaining its initial value. Then verify the same record and an action the account should still be unable to perform. If a temporary setting was applied on a copy, restore it after testing. Rollback must concern the added permission or changed rule without touching the order or its commercial status.

Interpret results on a real WooCommerce list

On an isolated copy, prepare two fictional orders with different dates and statuses, without a real gateway or external email. First verify that an authorized manager sees both without filters. Then apply one date or status filter and record which disappears. Remove it and verify the same record returns without changing its ID or status.

Compare with an account lacking management permissions: knowing the record's address must not grant data access. For technical reading, separately compare a known order, a checkout draft and an ID confirmed absent on that copy. A draft does not prove purchase confirmation; absence does not prove deletion.

This procedure is a proposed staging exercise. Record versions, active storage and results actually obtained on your copy before drawing a conclusion about production.

Approach 2. Read the identifier through WooCommerce

This procedure suits someone authorized to use WP-CLI on the server or a representative copy. It requires the order's positive internal ID and confirmed WordPress path. Choose the correct site with --url, especially in multisite. Reading goes through WooCommerce and its active storage. The fragment displays neither address, customer name nor payment method. It changes no state. Like any command loading WordPress, it nevertheless uses plugins installed on the target. Check the path before running on hosting containing several copies.

Save the fragment below in a private file named lecture-commande.php, outside the publicly served directory. The next section's command loads it after WordPress starts. The tool returns ID, storage, status and UTC date when the object is an order. A refund or other object is not an order record. Read any PHP warnings separately from JSON. If WordPress loading fails, resolve that error before interpreting missing output.

<?php
if (!isset($args[0]) || !ctype_digit((string) $args[0]) || (int) $args[0] < 1) {
    fwrite(STDERR, "Indiquez l’identifiant interne positif de la commande.\n");
    exit(1);
}
if (!function_exists('wc_get_order')) {
    fwrite(STDERR, "WooCommerce doit être actif dans cette installation.\n");
    exit(1);
}

$id = (int) $args[0];
$order = wc_get_order($id);
$active_store = \Automattic\WooCommerce\Utilities\OrderUtil::custom_orders_table_usage_is_enabled()
    ? 'hpos' : 'posts';
$result = ['id' => $id, 'stockage_actif' => $active_store];

if ($order instanceof WC_Order && $order->get_type() === 'shop_order') {
    $created = $order->get_date_created();
    $result += [
        'resultat' => 'commande',
        'statut' => $order->get_status(),
        'date_utc' => $created ? gmdate('c', $created->getTimestamp()) : null,
    ];
} else {
    $result['resultat'] = $order ? 'objet_autre_type' : 'absente_du_stockage_actif';
}

echo wp_json_encode($result, JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR) . PHP_EOL;

Run the read on the correct installation

Replace the path, staging domain, fragment path and number 123 with your authorized values. Start with a control order visible in the same list, then repeat the command with the sought ID. A commande result lets you compare status with filters. A checkout-draft status points toward the checkout confirmation process. An absente_du_stockage_actif result describes only what WooCommerce finds in this context. Removing the tool means deleting only the private file created for this test.

wp --path="/chemin/recette" --url="https://recette.example.test" eval-file "/chemin/prive/lecture-commande.php" 123

Interpret an absent identifier without recreating the order

Under WooCommerce > Settings > Advanced > Features, record the selected order storage. The exact name and compatibility option may vary by version. If HPOS is active, a row in a historical WordPress table may represent a copy, compatibility trace or transition record. If post tables are authoritative, reading only HPOS tables creates the inverse problem. Compare the WooCommerce read with the store setting and report a mismatch to the synchronization administrator. Do not switch storage to make an ID appear. A switch requires its own inventory and rollback procedure.

If the read finds nothing and the customer genuinely saw a confirmation result, reconcile the first checkout event at the recorded time. Ask the administrator to check WooCommerce > Status > Logs, the relevant integration log and server errors over a short interval. A store may be connected to a test environment, another subsite or an importer that creates orders separately. The log may show a rejection or exception before saving. Missing traces may also result from log retention or late logging activation. Record what is actually observable before assigning a cause.

If a financial reference exists, the store administrator must reconcile it with the payment tool in the correct account and mode. Avoid another attempt with the customer or creating a second order to make screens agree. A transaction, thank-you page and stored order are three different pieces of evidence. If a legitimate order needs regularization, the team must first establish what was charged, confirmed and shipped. The pending-order reconciliation guide covers that step.

Validate the correction and retain a stable control

After removing a filter, repeat the search with the same number and confirm that opening it leads to the expected record. After correcting permissions, check both the original account and an already authorized manager. If a custom rule caused the problem, disable only that rule on the copy and repeat the check before any live change. Record the previous setting. Correcting a view does not require changing order status. If the rule unintentionally broadens access scope, restore its initial state.

If no order was created, the next observation must concern a new staging checkout without a real gateway. Record whether WooCommerce creates a draft, an order ID and then a final status matching the simulated operation. Check that the order also appears in a manager's list with filters reset. For the reported order, keep the domain, supplied number, ID if known, date, active storage and both reading results. This record supports further reconciliation without triggering another sale.

Search without adding an order plugin

The native list and reading through wc_get_order() cover two complementary free needs: finding an accessible record and checking whether WooCommerce recognizes an ID in its active storage. Installing a second order manager before this reconciliation may add new filters without explaining the initial discrepancy.

If a known order appears through technical reading but not in the list, record its exact status and the plugins customizing statuses or permissions. On the copy, compare a native list with those customizations isolated one by one. Keep the same account and ID. If the order reappears, correction concerns the selection rule; do not convert an order to ‘Completed’ to force it into a tab.

After correction, check a second status and an order that must remain inaccessible to the limited account. Success must restore the intended view without broadening permissions or modifying commercial data.