| [ Index ] |
PHP Cross Reference of Drupal 6 (yi-drupal) |
[Source view] [Print] [Project Stats]
(no description)
| File Size: | 1739 lines (65 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
| hook_add_to_cart($nid, $qty, $data) X-Ref |
| Do extra processing when an item is added to the shopping cart. Some modules need to be able to hook into the process of adding items to a cart. For example, an inventory system may need to check stock levels and prevent an out of stock item from being added to a customer's cart. This hook lets developers squeeze right in at the end of the process after the product information is all loaded and the product is about to be added to the cart. In the event that a product should not be added to the cart, you simply have to return a failure message described below. This hook may also be used simply to perform some routine action when products are added to the cart. param: $nid param: $qty param: $data return: |
| hook_add_to_cart_data($form_values) X-Ref |
| Add extra information to a cart item's "data" array. This is effectively the submit handler of any alterations to the Add to Cart form. It provides a standard way to store the extra information so that it can be used by hook_add_to_cart(). param: $form_values return: |
| hook_calculate_tax($order) X-Ref |
| Calculate tax line items for an order. param: $order return: |
| hook_cart_display($item) X-Ref |
| Control the display of an item in the cart. Product type modules allow the creation of nodes that can be added to the cart. The cart determines how they are displayed through this hook. This is especially important for product kits, because it may be displayed as a single unit in the cart even though it is represented as several items. param: $item return: |
| hook_cart_item($op, &$item) X-Ref |
| Add extra data about an item in the cart. Products that are added to a customer's cart are referred as items until the sale is completed. Just think of a grocery store having a bunch of products on the shelves but putting a sign over the express lane saying "15 Items or Less." hook_cart_item() is in charge of acting on items at various times like when they are being added to a cart, saved, loaded, and checked out. Here's the rationale for this hook: Products may change on a live site during a price increase or change to attribute adjustments. If a user has previously added an item to their cart, when they go to checkout or view their cart screen we want the latest pricing and model numbers to show. So, the essential product information is stored in the cart, but when the items in a cart are loaded, modules are given a chance to adjust the data against the latest settings. param: $op return: |
| hook_cart_pane($items) X-Ref |
| Register callbacks for a cart pane. The default cart view page displays a table of the cart contents and a few simple form features to manage the cart contents. For a module to add information to this page, it must use hook_cart_pane to define extra panes that may be ordered to appear above or below the default information. param: $items return: |
| hook_cart_pane_alter(&$panes, $items) X-Ref |
| Alter cart pane definitions. param: $panes param: $items |
| hook_checkout_pane() X-Ref |
| Register callbacks for a checkout pane. The checkout screen for Ubercart is a compilation of enabled checkout panes. A checkout pane can be used to display order information, collect data from the customer, or interact with other panes. Panes are defined in enabled modules with hook_checkout_pane() and displayed and processed through specified callback functions. Some of the settings for each pane are configurable from the checkout settings page with defaults being specified in the hooks. The default panes are defined in uc_cart.module in the function uc_cart_checkout_pane(). These include panes to display the contents of the shopping cart and to collect essential site user information, a shipping address, a payment address, and order comments. Other included modules offer panes for shipping and payment purposes as well. return: |
| hook_checkout_pane_alter(&$panes) X-Ref |
| Alter checkout pane definitions. param: $panes |
| hook_download_authorize($user, $file_download) X-Ref |
| Give clearance to a user to download a file. By default the uc_file module can implement 3 restrictions on downloads: by number of IP addresses downloaded from, by number of downloads, and by a set expiration date. Developers wishing to add further restrictions can do so by implementing this hook. After the 3 aforementioned restrictions are checked, the uc_file module will check for implementations of this hook. param: $user param: $file_download return: |
| hook_file_action($op, $args) X-Ref |
| Perform actions on file products. The uc_file module comes with a file manager (found at Administer » Store administration » Products » View file downloads) that provides some basic functionality: deletion of multiple files and directories, and upload of single files (those looking to upload multiple files should just directly upload them to their file download directory then visit the file manager which automatically updates new files found in its directory). Developers that need to create more advanced actions with this file manager can do so by using this hook. param: $op param: $args return: |
| hook_file_transfer_alter($file_user, $ip, $fid, $file) X-Ref |
| Make changes to a file before it is downloaded by the customer. Stores, either for customization, copy protection or other reasons, might want to send customized downloads to customers. This hook will allow this to happen. Before a file is opened to be transfered to a customer, this hook will be called to make any altercations to the file that will be used to transfer the download to the customer. This, in effect, will allow a developer to create a new, personalized, file that will get transfered to a customer. param: $file_user param: $ip param: $fid param: $file return: |
| hook_line_item() X-Ref |
| Used to define line items that are attached to orders. A line item is a representation of charges, fees, and totals for an order. Default line items include the subtotal and total line items, the tax line item, and the shipping line item. There is also a generic line item that store admins can use to add extra fees and discounts to manually created orders. Module developers will use this hook to define new types of line items for their stores. An example use would be for a module that allows customers to use coupons and wants to represent an entered coupon as a line item. Once a line item has been defined in hook_line_item, Übercart will begin interacting with it in various parts of the code. One of the primary ways this is done is through the callback function you specify for the line item. return: |
| hook_line_item_alter(&$item, $order) X-Ref |
| Alter a line item on an order when the order is loaded. param: &$item param: $order |
| hook_line_item_data_alter(&$items) X-Ref |
| Alter the line item definitions declared in hook_line_item(). param: &$items |
| hook_order($op, $arg1, $arg2) X-Ref |
| Perform actions on orders. An order in Übercart represents a single transaction. Orders are created during the checkout process where they sit in the database with a status of In Checkout. When a customer completes checkout, the order's status gets updated to show that the sale has gone through. Once an order is created, and even during its creation, it may be acted on by any module to connect extra information to an order. Every time an action occurs to an order, hook_order() gets invoked to let your modules know what's happening and make stuff happen. param: $op param: &$arg1 param: $arg2 |
| hook_order_actions($order) X-Ref |
| Add links to local tasks for orders on the admin's list of orders. param: $order return: |
| hook_order_pane() X-Ref |
| Register callbacks for an order pane. This hook is used to add panes to the order viewing and administration screens. The default panes include areas to display and edit addresses, products, comments, etc. Developers should use this hook when they need to display or modify any custom data pertaining to an order. For example, a store that uses a custom checkout pane to find out a customer's desired delivery date would then create a corresponding order pane to show the data on the order screens. hook_order_pane() works by defining new order panes and providing a little bit of information about them. View the return value section below for information about what parts of an order pane are defined by the hook. The real meat of an order pane is its callback function (which is specified in the hook). The callback function handles what gets displayed on which screen and what data can be manipulated. That is all somewhat out of the scope of this API page, so you'll have to click here to read more about what a callback function should contain. |
| hook_order_pane_alter(&$panes) X-Ref |
| Alter order pane definitions. param: $panes |
| hook_order_product_alter(&$product, $order) X-Ref |
| Allows modules to alter ordered products when they're loaded with an order. param: &$product param: $order return: |
| hook_order_state() X-Ref |
| Register static order states. Order states are module-defined categories for order statuses. Each state will have a default status that is used when modules need to move orders to new state, but don't know which status to use. return: |
| hook_payment_gateway() X-Ref |
| Register payment gateway callbacks. return: |
| hook_payment_gateway_alter(&$gateways) X-Ref |
| Alter payment gateways. param: $gateways |
| hook_payment_method() X-Ref |
| Register callbacks for payment methods. Payment methods are different ways to collect payment. By default, Übercart comes with support for check, credit card, and generic payments. Payment methods show up at checkout or on the order administration screens, and they collect different sorts of information from the user that is used to process or track the payment. return: |
| hook_product_class($type, $op) X-Ref |
| Perform actions on product classes. param: $type param: $op |
| hook_product_description($product) X-Ref |
| Return a structured array representing the given product's description. Modules that add data to cart items when they are selected should display it with this hook. The return values from each implementation will be sent through to hook_product_description_alter() implementations and then all descriptions are rendered using drupal_render(). param: $product return: |
| hook_product_description_alter(&$description, $product) X-Ref |
| Alters the given product description. param: $description param: $product |
| hook_product_types() X-Ref |
| List node types which should be considered products. Trusts the duck philosophy of object identification: if it walks like a duck, quacks like a duck, and has feathers like a duck, it's probably a duck. Products are nodes with prices, SKUs, and everything else Übercart expects them to have. return: |
| hook_shipment($op, &$shipment) X-Ref |
| Handle additional data for shipments. param: $op param: &$shipment return: |
| hook_shipping_method() X-Ref |
| Define callbacks and service options for shipping methods. The shipping quote controller module, uc_quote, expects a very specific structured array of methods from the implementations of this hook. The weights and enabled flags for shipping methods and types are set at the Shipping Quote Settings page under Store Configuration. They keys of the variables are the ids of the shipping methods. The "quote" and "ship" arrays of the method are both optional. return: |
| hook_shipping_type() X-Ref |
| Define shipping types for shipping methods. This hook defines a shipping type that this module is designed to handle. These types are specified by a machine- and human-readable name called 'id', and 'title' respectively. Shipping types may be set for individual products, manufacturers, and for the entire store catalog. Shipping modules should be careful to use the same shipping type ids as other similar shipping modules (i.e., FedEx and UPS both operate on "small package" shipments). Modules that do not fulfill orders may not need to implement this hook. return: |
| hook_store_status() X-Ref |
| Add status messages to the "Store administration" page. This hook is used to add items to the store status table on the main store administration screen. Each item gets a row in the table that consists of a status icon, title, and description. These items should be used to give special instructions, notifications, or indicators for components of the cart enabled by the modules. At a glance, a store owner should be able to look here and see if a critical component of your module is not functioning properly. For example, if the catalog module is installed and it cannot find the catalog taxonomy vocabulary, it will show an error message here to alert the store administrator. return: |
| hook_tapir_table_alter(&$table, $table_id) X-Ref |
| Allow modules to alter the TAPIr table after the rows are populated. The example below adds a value for the custom 'designer' column to the table rows. Each table row has a numeric key in $table and these keys can be accessed using element_children() from the Form API. param: $table Table declaration containing header and populated rows. param: $table_id Table ID. Also the function called to build the table |
| hook_tapir_table_header_alter(&$header, $table_id) X-Ref |
| Allow modules to alter TAPIr table headers. This is most often done when a developer wants to add a sortable field to the table. A sortable field is one where the header can be clicked to sort the table results. This cannot be done using hook_tapir_table_alter() as once that is called the query has already executed. The example below adds a 'designer' column to the catalog product table. The example module would also have added joins to the query using hook_db_rewrite_sql() in order for table 'td2' to be valid. The 'name' field is displayed in the table and the header has the title 'Designer'. Also shown are changes made to the header titles for list_price and price fields. param: $header Reference to the array header declaration param: $table_id Table ID. Also the function called to build the table |
| hook_uc_checkout_complete($order, $account) X-Ref |
| Take action when checkout is completed. param: $order param: $account |
| hook_uc_form_alter(&$form, &$form_state, $form_id) X-Ref |
| Allow modules to modify forms before Drupal invokes hook_form_alter(). This hook will normally be used by core modules so any form modifications they make can be further modified by contrib modules using a normal hook_form_alter(). At this point, drupal_prepare_form() has not been called, so none of the automatic form data (e.g.: #parameters, #build_id, etc.) has been added yet. For a description of the hook parameters: |
| hook_uc_invoice_templates() X-Ref |
| Add invoice templates to the list of suggested template files. Allows modules to declare new "types" of invoice templates (other than the default 'admin' and 'customer'). return: |
| hook_uc_message() X-Ref |
| Convenience function to display large blocks of text in several places. There are many instances where Ubercart modules have configurable blocks of text. These usually come with default messages, like e-mail templates for new orders. Because of the way default values are normally set, you're then stuck having to copy and paste a large chunk of text in at least two different places in the module (when you're wanting to use the variable or to display the settings form with the default value). To cut down code clutter, this hook was introduced. It lets you put your messages in one place and use the function uc_get_message() to retrieve the default value at any time (and from any module). The function is very simple, expecting no arguments and returning a basic associative array with keys being message IDs and their values being the default message. When you call uc_get_message(), use the message ID you set here to refer to the message you want. Note: When using t(), you must not pass it a concatenated string! So our example has no line breaks in the message even though it is much wider than 80 characters. Using concatenation breaks translation. return: |
| hook_uc_payment_entered($order, $method, $amount, $account, $data, $comment) X-Ref |
| Take action when a payment is entered for an order. param: $order param: $method param: $amount param: $account param: $data param: $comment |
| hook_uc_price_handler() X-Ref |
| Use this hook to define price handlers for your module. You may define one price alterer and one price formatter. You may also define options that are merged into the options array in order of each price alterer's weight. |
| hook_uc_product_default_classes() X-Ref |
| Define default product classes. The results of this hook are eventually passed through hook_node_info(), so you may include any keys that hook_node_info() uses. Defaults will be provided where keys are not set. This hook can also be used to override the default "product" product class name and description. |
| hook_uc_product_models($node) X-Ref |
| Notify core of any SKUs your module adds to a given node. NOTE: DO NOT map the array keys, as the possibility for numeric SKUs exists, and this will conflict with the behavior of module_invoke_all(), specifically array_merge_recursive(). Code lifted from uc_attribute.module. |
| hook_uc_stock_adjusted($sku, $stock, $qty) X-Ref |
| Allow modules to take action when a stock level is changed. param: $sku param: $stock param: $qty |
| hook_ucga_display() X-Ref |
| Used to determine whether or not UC Google Analytics should add e-commerce tracking code to the bottom of the page. The Google Analytics module takes care of adding the necessary .js file from Google for tracking general statistics. The UC Google Analytics module works in conjunction with this code to add e-commerce specific code. However, the e-commerce code should only be added on appropriate pages. Generally, the correct page will be the checkout completion page at cart/checkout/complete. However, because modules can change the checkout flow as necessary, it must be possible for alternate pages to be used. This hook allows other modules to tell the UC Google Analytics module that it should go ahead and add the e-commerce tracking code to the current page. A module simply needs to implement this hook and return TRUE on the proper order completion page to let UC Google Analytics know it should add the e-commerce tracking code to the current page. The implementation below comes from the 2Checkout.com module which uses an alternate checkout completion page. return: |
| hook_ucga_item_alter(&$item, $product, $trans, $order) X-Ref |
| Allows modules to alter items before they're added to the UC Google Analytics e-commerce tracking code. The UC Google Analytics module constructs function calls that work through the Google Analytics JS API to report purchased items for e-commerce tracking purposes. The module builds the argument list for each product on an order and uses this hook to give other modules a chance to alter what gets reported to Google Analytics. Additional arguments passed to implementations of this hook are provided for context. param: $item param: $product param: $trans param: $order return: |
| hook_ucga_trans_alter(&$trans, $order) X-Ref |
| Allows modules to alter transaction info before it's added to the UC Google Analytics e-commerce tracking code. The UC Google Analytics module constructs function calls that work through the Google Analytics JS API to report order information for e-commerce tracking purposes. The module builds the argument list for the transaction and uses this hook to give other modules a chance to alter what gets reported to Google Analytics. param: $trans param: $order return: |
| hook_update_cart_item($nid, $data = array() X-Ref |
| Handle requests to update a cart item. param: $nid param: $data param: $qty param: $cid |
| Generated: Mon Jul 9 18:01:44 2012 | Cross-referenced by PHPXref 0.7 |