{"id":18962014,"date":"2026-07-10T17:26:30","date_gmt":"2026-07-10T17:26:30","guid":{"rendered":"https:\/\/wordpress.org\/support\/?post_type=topic&p=18962014"},"modified":"2026-07-10T17:47:14","modified_gmt":"2026-07-10T17:47:14","slug":"problems-in-plugin","status":"publish","type":"topic","link":"https:\/\/wordpress.org\/support\/topic\/problems-in-plugin\/","title":{"rendered":"Problems in plugin"},"content":{"rendered":"\n

Version 1.0.1 has serious reporting bugs<\/p>\n\n\n\n

1. It probably excludes completed orders<\/strong><\/p>\n\n\n\n

The code converts statuses using:<\/p>\n\n\n\n

'wc-' . ltrim($s, 'wc-')\n<\/code><\/pre>\n\n\n\n
The second argument to ltrim()<\/code> is a set of characters<\/strong>, not a literal prefix. Consequently:<\/p>\n\n\n\n
processing -> wc-processing\ncompleted  -> wc-ompleted\ncancelled  -> wc-ancelled\n<\/code><\/pre>\n\n\n\n
The default statuses are processing<\/code> and completed<\/code>, so completed orders will likely be silently excluded from both the source report and daily-revenue trend.<\/p>\n\n\n\n
The correct form is approximately:<\/p>\n\n\n\n
$s = sanitize_key((string) $s);\n\nreturn str_starts_with($s, 'wc-')\n    ? $s\n    : 'wc-' . $s;\n<\/code><\/pre>\n\n\n\n
This bug appears in multiple paths and must be fixed everywhere, including the legacy-order queries.<\/p>\n\n\n\n
2. Its PHP 7.4 compatibility declaration is wrong<\/strong><\/p>\n\n\n\n
The plugin says it supports PHP 7.4, but repeatedly calls:<\/p>\n\n\n\n
str_contains()\nstr_starts_with()\nstr_ends_with()\n<\/code><\/pre>\n\n\n\n
Those functions require PHP 8.0 or later. On PHP 7.4, report execution will fatal-error.<\/p>\n\n\n\n
The developer should either declare\u00a0PHP 8.0+<\/strong>\u00a0or replace those calls with PHP 7.4-compatible implementations.<\/p>\n\n\n\n
3. Large date ranges can consume excessive resources<\/strong><\/p>\n\n\n\n
The date parameters are sanitized but not strictly validated or limited. The plugin:<\/p>\n\n\n\n
    \n
  • Builds one PHP array entry for every day in the selected period.<\/li>\n\n\n\n
  • Retrieves one database row per order and aggregates the results in PHP.<\/li>\n\n\n\n
  • Describes the queries as \u201caggregated,\u201d even though the main source query is not aggregated in SQL.<\/li>\n<\/ul>\n\n\n\n
    A shop manager selecting an extremely large range could cause a heavy database query, high PHP memory use, or a timeout.<\/p>\n\n\n\n
    4. Its HPOS support is brittle<\/strong><\/p>\n\n\n\n
    It does query wc_orders<\/code> and wc_orders_meta<\/code>, so it understands HPOS storage. But it:<\/p>\n\n\n\n
      \n
    • Directly couples itself to WooCommerce table structures.<\/li>\n\n\n\n
    • Does not declare HPOS compatibility through WooCommerce\u2019s FeaturesUtil<\/code> mechanism.<\/li>\n\n\n\n
    • Executes a second legacy-table query even when HPOS is active, attempting to find orders not present in HPOS.<\/li>\n<\/ul>\n\n\n\n
      That is less robust than using supported WooCommerce order\/query APIs.<\/p>\n\n\n\n
      5. The advertised meta-key settings do not exist<\/strong><\/p>\n\n\n\n
      The plugin initializes a list of possible attribution meta keys and tells the administrator to configure the correct meta key in \u201cSettings.\u201d However:<\/p>\n\n\n\n
        \n
      • There is no settings screen or save handler.<\/li>\n\n\n\n
      • The private option-update function is never called.<\/li>\n\n\n\n
      • The reporting function ignores the supplied $metaKeys<\/code>.<\/li>\n\n\n\n
      • It always uses three hard-coded WooCommerce attribution keys.<\/li>\n<\/ul>\n\n\n\n
        Therefore, the advertised support for custom attribution metadata is effectively unimplemented.6. It can misclassify attribution<\/p>\n\n\n\n
        The normalization code tends to label a source value of google<\/code> as Google Ads<\/strong>, without examining UTM medium. It also collapses most referring domains into a generic Referral<\/code> category.<\/p>\n\n\n\n
        That can give misleading marketing results even after fixing the completed-order bug.7. \u201cRevenue\u201d means order total, not net sales<\/p>\n\n\n\n
        It sums\u00a0total_amount<\/code>. It does not subtract refunds or reproduce WooCommerce Analytics\u2019 net-sales calculation. Its revenue result may include shipping and tax and may differ materially from WooCommerce\u2019s standard reports.<\/p>\n\n\n\n
        I would not rely on version 1.0.1 in production<\/strong> until at least the following are fixed:<\/p>\n\n\n\n
          \n
        1. Replace all faulty ltrim($s, 'wc-')<\/code> status handling.<\/li>\n\n\n\n
        2. Require PHP 8.0+, or implement PHP 7.4-compatible string helpers.<\/li>\n\n\n\n
        3. Validate dates and impose a sensible maximum report range.<\/li>\n\n\n\n
        4. Compare its counts and totals against known completed and processing orders.<\/li>\n\n\n\n
        5. Clarify whether \u201crevenue\u201d means gross order total or net sales.<\/li>\n\n\n\n
        6. Add a proper HPOS compatibility declaration.<\/li>\n<\/ol>\n","protected":false},"template":"","class_list":["post-18962014","topic","type-topic","status-publish","hentry"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/18962014","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic"}],"about":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/types\/topic"}],"version-history":[{"count":1,"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/18962014\/revisions"}],"predecessor-version":[{"id":18962029,"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/18962014\/revisions\/18962029"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/media?parent=18962014"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}