Title: jonpreston's Replies | WordPress.org

---

# jonpreston

  [  ](https://wordpress.org/support/users/jonpreston/)

 *   [Profile](https://wordpress.org/support/users/jonpreston/)
 *   [Topics Started](https://wordpress.org/support/users/jonpreston/topics/)
 *   [Replies Created](https://wordpress.org/support/users/jonpreston/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/jonpreston/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/jonpreston/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/jonpreston/engagements/)
 *   [Favorites](https://wordpress.org/support/users/jonpreston/favorites/)

 Search replies:

## Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[CURCY - Multi Currency for WooCommerce - Smoothly on WooCommerce 9.x] PHP 8.3.32 deprecation: float converted to int in frontend/price.php](https://wordpress.org/support/topic/php-8-3-32-deprecation-float-converted-to-int-in-frontend-price-php/)
 *  Thread Starter [jonpreston](https://wordpress.org/support/users/jonpreston/)
 * (@jonpreston)
 * [1 hour, 29 minutes ago](https://wordpress.org/support/topic/php-8-3-32-deprecation-float-converted-to-int-in-frontend-price-php/#post-18988240)
 * I have now inspected the affected `frontend/price.php` file and found the direct
   cause of the PHP 8.3 deprecation.
 * In `set_cache()`, CURCY uses `$key` directly as an array key:
 * `$this->price[$id][$key] = ...`
 * `$key` is passed from WooCommerce price values and on our site can be a float
   such as `22.05`. PHP 8.3 therefore attempts to convert the float array key to
   an integer, producing:
 * `Implicit conversion from float 22.05 to int loses precision`
 * The same issue occurs in the cache lookups, for example:
 * `isset($this->price[$product_id][$price])`
 * when `$price` is a float.
 * The issue appears to be that CURCY’s internal price cache does not normalize 
   price-based array keys to strings. Casting the cache key consistently to `(string)`
   for both storage and retrieval should prevent the warning without changing the
   price value itself.
 * A third-party plugin may be responsible for WooCommerce returning the price as
   a float rather than a numeric string, but CURCY’s cache code is where that valid
   float value is being used as an array key and where PHP generates the warning.
   
   Hope that helpsI will open a topic in your forum as well to further assist as
   suggested. Thank you so much for taking the time to reply.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[CURCY - Multi Currency for WooCommerce - Smoothly on WooCommerce 9.x] PHP 8.3.32 deprecation: float converted to int in frontend/price.php](https://wordpress.org/support/topic/php-8-3-32-deprecation-float-converted-to-int-in-frontend-price-php/)
 *  Thread Starter [jonpreston](https://wordpress.org/support/users/jonpreston/)
 * (@jonpreston)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/php-8-3-32-deprecation-float-converted-to-int-in-frontend-price-php/#post-18987155)
 * Hi [@mytrinh](https://wordpress.org/support/users/mytrinh/),
 * Thank you for the quick reply.
 * I can confirm that I am already running **CURCY version 2.4.2** on PHP 8.3.32,
   and these deprecation notices are still actively generating in the logs.
 * The reason this might not show up on your test server is likely because `E_DEPRECATED`
   warnings or `WP_DEBUG_LOG` are disabled in your test environment. PHP 8.1+ introduced
   a strict deprecation notice whenever a non-integer float (e.g., `23.52` or `17.50`)
   is implicitly converted to an integer (such as inside bitwise operations, array
   offsets, or integer-type parameters).
 * Here are the exact details from **v2.4.2**:
    - **File:** `wp-content/plugins/woocommerce-multi-currency/frontend/price.php`
    - **Affected Lines:** `1101`, `1103`, `1220`, and `1221`
    - **Trigger:** Price conversion math resulting in floating-point decimals being
      passed directly into code expecting an integer.
 * Could the development team please review those specific lines in `frontend/price.
   php` and wrap the float calculations in explicit casting or `round()` / `intval()`?
   This will resolve the warnings, prevent `debug.log` file bloat, and ensure full
   PHP 8.3 compliance.
 * Best regards,
 * Jon

Viewing 2 replies - 1 through 2 (of 2 total)