Bartek

Hi @tomasbud

I must admit, I fooled myself, after 2 years of developing the plugin 😅 Actually, there’s no order.billing_phone placeholder in ShopMagic, and it is not because it’s free version – we just never implemented such placeholder. It seemed so obvious to me, that I was sure we did…

Anyway, order.billing_phone from now on is added to our backlog and will be introduced. Fortunately, there is a possibility to get customer number with customer.phone placeholder (which definitely is implemented).

I hope this helps 🙂

I’ve investigated the issue, and it seems LiteSpeed caching plugin on LS servers can produce such results in some configuration (I recreated it with standard recommended settings, but more aggressive caching surprisingly didn’t bring up the issue).

Unfortunately, at the moment the issue is a bit stuck, due to limited cache purging possibilities exposed by LiteSpeed plugin API (you can easily purge the whole website cache, which wouldn’t be appreciated, but tagging a specific URL is difficult).

You mention it doesn’t occur in other plugins. Well, I wouldn’t totally agree, but what makes ShopMagic special is the fact we use REST API for administrative side. Cache plugins usually skip admin area, but REST API is a part of regular WordPress website, subjected to regular caching rules.

Finally, we will get to the bottom of the issue, and it will be fixed. I’m glad that you have found a workaround for the meantime. Again, I apologize for the inconveniences.

Hi @toddi2303!

Checkout fields are saved as an order meta values, so any $order->get_meta('_<field_name>') should be able to retrieve custom values (mind the underscore at the beginning of the field name).

Alternatively, there’s a class \WPDesk\FCF\Free\Integration\Integrator in our codebase, which provides an API to access fields and its values in specified order. To make use of this class, you need to hook into flexible_checkout_fields/init.

Here’s an example for getting order field value:

add_action(
  'flexible_checkout_fields/init',
  static function ( $integrator ) {
    // Get value of custom field for order #13.
    $field = $integrator->get_field_value( 'custom_field', 13 );
    // ...
  }
);

Hi @araislamara!

I can see some mistakes in your code:

1. You don’t attach, but fire an action. Use add_action, not do_action
2. You are trying to attach to hook from within REST API callback, but this way, you try to hook into action after it has been executed. It isn’t possible in WordPress, as you should attach all your hook callbacks before a hook will be dispatched (i.e. with do_action)

To do this correctly, you should first hook into Flexible Wishlist, and from within, register a REST API route. It is important to preserve a correct order of execution.

Here’s an example:

function get_wishlist_products_by_user( $wishlist_repository, $user_id ) {
  /** @var array $wishlist One user can have multiple wishlists */
  $wishlists = $wishlist_repository->get_by_user( $user_id );
  $product_id = [];
  foreach ( $wishlists as $wishlist ) {
    $wishlist_items = $wishlist->get_items();
    foreach ( $wishlist_items as $wishlist_item ) {
      $product_id[] = $wishlist_item->get_product_id();
    }
  }
  return $product_id;
}

// Hook into Flexible Wishlist initiation point
add_action(
  'flexible_wishlist/init',
  // Here we can access WishlistRepository, which we will need to get products for user
  function ( $_, $wishlist_repository ) {

    // Register our REST API route
    add_action(
      'rest_api_init',
      // This may be done better with OOP and keeping wishlist repository as class field
      // Otherwise, we need to pass it down as closure argument
      function () use ( $wishlist_repository ) {
        register_rest_route(
          'my_flexible_test',
          '/v1',
          [
            'methods' => 'GET',
            'callback' => static function () use( $wishlist_repository ) {
              return rest_ensure_response(
                get_wishlist_products_by_user( $wishlist_repository, 1 )
              );
            },
            'permission_callback' => '__return_true'
          ]
        );
      }
    );

  },
  10,
  2
);

Hi @jarwu

The issue is fixed in 3.0.13, so please do another upgrade.

Best regards,
Bartek

Hi @chaosproz

Another way to solve this issue would be to upgrade ShopMagic to the latest 3.0.13 release. Our customers have confirmed that it restores correct state of ShopMagic.

We are deeply sorry for the troubles that the bug caused.

Best regards,
Bartek