Adapt Your Add-Ons & Themes To Cs-Cart 4.3.7

Common Changes

  • Upgrade center. The schema of a content upgrade package is now an object of \Tygh\UpgradeCenter\ContentSchema. Backward compatibility is preserved. You can use this schema as an object in your own upgrade validators.
  • Behaviour of the {btn} backend template function has changed:
    • Permission checks for the $href parameter now use the GET method. Permission checks for $dispatch use POST.
    • The method parameter has been added. Its value can be GET or POST. This parameter affects permission checks. Also, if method == "POST", the cm-post class will be added to the link automatically.
    • We don't recommend passing cm-post in the $class parameter.
  • All requests performed with methods of \Tygh\Http class now have default connect timeout value of 10 seconds.

Hooks Changes

New Hooks

  • fn_set_hook('is_order_allowed_post', $order_id, $auth, $allowed); - Checks if an order is available for a customer.
  • fn_set_hook('checkout_place_orders_pre_route', $cart, $auth, $params); - Performs actions before order placement redirect on checkout.
  • fn_set_hook('get_languages', $params, $hash_key, $field_list, $join, $condition, $group_by, $order_by, $limit); - Modifies the get languages list by specified parameters SQL query parameters.
  • fn_set_hook('get_all_languages', $edit, $field_list, $join, $condition, $group_by, $order_by, $limit); - Modifies the all languages list SQL query parameters.
  • fn_set_hook('get_simple_languages', $include_hidden, $field_list, $join, $condition, $group_by, $order_by, $limit); - Modifies the simple languages list SQL query parameters.
  • fn_set_hook('get_available_languages', $area, $include_hidden, $field_list, $join, $condition, $group_by, $order_by, $limit); - Modifies the available languages list SQL query parameters.

Changed Hooks

  • fn_set_hook('is_order_allowed', $order_id, $allowed); is now deprecated.
-fn_set_hook('buy_together_get_chains_pre', $parms, $auth, $lang_code);
+fn_set_hook('buy_together_get_chains_pre', $params, $auth, $lang_code);
-fn_set_hook('convert_price_pre', $price);
+fn_set_hook('convert_price_pre', $price, $currency_code);
-fn_set_hook('convert_price_post', $result, $price);
+fn_set_hook('convert_price_post', $result, $price, $currency_code);
fn_set_hook('send_form', $page_data, $form_values, $result, $from, $sender, $attachments, $is_html);
fn_set_hook('send_form', $page_data, $form_values, $result, $from, $sender, $attachments, $is_html, $subject);

Core Functions

Changed Functions

-function db_paginate(&$page, $items_per_page, $total_items = 0)
+function db_paginate(&$page, &$items_per_page, $total_items = 0)
-function fn_blog_get_pages($params, $join, $condition, $fields, $group_by, &$sortings, $lang_code)
+function fn_blog_get_pages(&$params, $join, $condition, $fields, $group_by, &$sortings, $lang_code)

New Functions

  • \Tygh\Database\Connection::hasTable($table_name, $set_prefix = true) - Checks if the table exists in the database.
  • db_has_table($table_name, $set_prefix = true) - Short code for \Tygh\Database\Connection::hasTable, checks if the table exists on current connection.
  • fn_get_subscriber_id_by_email($email = '') - Gets a subscriber identifier by email.
  • fn_exim_find_feature_group_id($name, $lang_code) - Finds a product feature group id by the name.
  • fn_exim_find_feature_id($name, $type, $group_id, $lang_code) - Finds a product feature id by params.
  • fn_extract_addon_package($file_name) - Extracts an add-on package to a temporary directory.
  • fn_validate_addon_structure($addon_name, $path) - Validates an ad-on package structure.
  • fn_get_subscribers($params, $items_per_page = 0, $lang_code = CART_LANGUAGE) - Gets the list of subscribers.
  • fn_update_subscriber($subscriber_data, $subscriber_id = 0) - Updates subscribers and subscriptions.
  • fn_is_order_allowed($order_id, $auth) - Checks if an order is available to view for a customer.
  • fn_discussion_check_thread_permissions($thread, $auth) - Checks access permissions to a thread object (e.g. an order).
  • fn_paypal_checkout_place_orders_pre_route(&$cart, $auth, $params) - Provides the token and handles errors for checkout with In-Context Checkout.
  • fn_form_builder_get_form_subject($form_structure, $form_data) - Gets an email subject for the submitted form.
  • fn_sort_tree($items, $subitems_field = 'subitems', $order_by = array('position'), $order = 'asc') - Sorts the multi-level tree.
  • \Tygh\Web\Session::requestGetSessionID() - Returns the session identifier contained in the HTTP request or nulls, if the request doesn't contain the session ID.
  • \Tygh\Snapshot::getModifiedFiles($ext = 'php', array $directories = array(), array $exclude = array()) - Gets modified files.

Question on the new store import marketplace addon.

Can it be configured to only do products/users/orders instead of attempting everything else? This issue I'm trying to address is problems with export/import where import fails and it's been over 2 weeks between bugtracker and helpdesk and I still can't "Actualize" my upgraded development store because import fails.

Would like to just be able to do the actualize portion of the store import but restricted to just products, users, and order data.

Question on the new store import marketplace addon.

Can it be configured to only do products/users/orders instead of attempting everything else? This issue I'm trying to address is problems with export/import where import fails and it's been over 2 weeks between bugtracker and helpdesk and I still can't "Actualize" my upgraded development store because import fails.

Would like to just be able to do the actualize portion of the store import but restricted to just products, users, and order data.

The store import add-on is not intended to be used for syncing data between production and development environments.

It was my understanding that this is exactly what the "actualize" step does and then the development environment is changed to be the production environment. Unfortunately you can't 'actualize' without it trying to change all the blocks, layouts and other 'presentation' data when all that is many times needed is to sync orders, customers and products.

It would be really helpful if the store_import could be used in a mode that just dealt with orders, customer, products to transfer from one lower version to a higher one. It would not need to do pages, or any addons at all. Just need to make up for the gap between an upgrade and production for sites that have lots of customized templates/files. This would be DB only.

I.e. be able to do the actualize step without having it try to do the pseudo upgrade of addons and all the other stuff it tries to do to get the base data into the DB. Make it so an upgraded store can be refreshed with current data from the production version of the upgraded store.

Hello Yakulakov, Abolshakov and other fellow CS-Cart developers and architects.

I developed a payment processor plugin, that by design embeds its HTML-form into iframe and displays at checkout.

Before version 4.3.7 I used a hack: I added a line


into my payment processor params template:

/design/backend/templates/views/payments/components/cc_processors/my_iframe_payment_processor.tpl

Now I see that version 4.3.7 offers official way of creating payment add-ons with this fuctionality:

Add-ons: Payments: Ability to create payments working in the iframe mode via the add-on was added

Can you show an example and explain it in more details, how to build proper iframe payment addon for 4.3.7 and up?

Thank you in advance!

Hello, Zahhar.

I added a line


into my payment processor params template

You still have to add this setting to your payment processor params template so that CS-Cart will treat your processor as one working in iframe mode.

Now I see that version 4.3.7 offers official way of creating payment add-ons with this fuctionality

Before version 4.3.7, processor scripts working in iframe mode could be loaded only from app/payments. Now they can also be loaded from app/addons/[addon_name]/payments.

Can you show an example and explain it in more details, how to build proper iframe payment addon for 4.3.7 and up?

You can use this sample add-on.

skirll_qc.php and skrill_ewallet.php payment processors that come with CS-Cart can function in iframe mode and can be used as examples, too.

Great example!

Thanks a lot, mschekotov!

I noticed, that you have used solely

fn_finish_payment($order_id, $pp_response, false);

when payment is succesfully processed, while skrill_qc.php and skrill_ewallet.php use these 2 fucntions one after another:

fn_finish_payment($_REQUEST['order_id'], $pp_response);
fn_order_placement_routines('route', $_REQUEST['order_id']);
Can you explain, when I need to use fn_finish_payment() and when fn_order_placement_routines()? Or I mush use both of them always?
Can you explain, when I need to use fn_finish_payment() and when fn_order_placement_routines()? Or I mush use both of them always?

fn_finish_payment() is used to set status of order accordingly to the payment gateway response. It's called when payment gateway reports the status of payment processing.

fn_order_placement_routines() is used to redirect customer to "Your order has been received" page when payment is succesful or to the checkout page when errors occur. In provided example it happens when customer clicks "Continue" in iframe.

These functions are used consequentially in Skrill because of the payment gateway architecture: some links in iframe cause customer to be redirected to payment_notification controller of CS-Cart.

UPD: I moved add-on into another repository, the most recent changes can be found at https://github.com/cscart/addons/tree/master/iframe_payment