example32_axZmMode.php HOME Examples overview Download Ask a question / privacy policy / imprint

AJAX-ZOOM mouseover extension, product detail page fictive example

Besides the modules/plugins for e-commerce systems like Magento, for which there are already modules available, you can implement this zoom on hover extension into your system manually. In the source code of this file, you can see all needed HTML markup and JavaScript that triggers AJAX-ZOOM mouseover extension with default parameters and some content data such as 360-degree rotations, regular images, and videos.

The product data to the right (or bottom on mobile devices) imitates the product detail page commonly used in the majority of shopping cart systems. The functioning part is the product variation switch or color swatch, here labeled as "color variant". The example only aims to show a more or less clean implementation of how the zoom on hover AJAX-ZOOM extension looks in place of a different one and how you can connect it to color- or product variants in general.

Product detail page title

Mouseover Zoom loading...

$495.90 * %

$879.90 (43.6% saved)

Color variant

  • Availability: available
  • Free of shipping costs!
  • Prices incl. VAT
  • Brand: Xanthippe
Order number: AZ10123

A few important extension options (demo) - show / hide
Inner zoom:
- enabled - disabled
"position": "inside" // or "right", ...
- enabled - disabled
"axZmMode": true // or false
Max zoom on click:
- enabled - disabled
"maxZoomMode": true // or false
- enabled - disabled
"galleryDivID": "az_mouseOverZoomGallery" // or false
Gallery position:
"thumbSliderPosition": "left-bottom"
For full list of options (documentation) and background information, please see example32.php

Implementing at frontend template with product variants

The mouseover extension provides all API methods (see the source code of this example) that you need to cope with the selection of single or multiple variants of a product. In this demo, for simplicity, we only define ids for each variation element. In your application, you should look for events and JavaScript functions, which trigger when the user selects or clicks on the UI that represents the variations and then hook on these events to trigger the change for images, videos and 360 animations. These integrational steps do not directly relate to the AJAX-ZOOM viewer. AJAX-ZOOM does only offer the methods to change the content over JavaScript, which is sufficient to implement it into your system and cope with the potential complexity of variations.

Please note that if you are pulling the data about product images for the variants out of JavaScript or template variables, the returned paths may not correspond to the original, high-resolution images. That is often the case. Instead, you get paths for already resized and compressed images. You should avoid providing those image paths to AJAX-ZOOM and double check that AJAX-ZOOM receives the high-resolution sources.

If it is, e.g., a "Smarty" template for the frontend and the correct paths to high-resolution source images are not available in template variables, you should check the documentation of your system and find a hook where you can define those variables. You may also need to find internal class methods that return the required information about source images or request it via a database query on your own. Generally, there is not just one possibility to receive the correct information. It depends on the system where you want to integrate the new viewer.

Implementing 360 product views

That is a more complicated task because, in contrast to plain images, you need to let the administrators upload the 360 spin images somehow. For normal images, systems already have it at the backend. Things get even more complicated if your client wants to have 360 views for product variations. If due to high expenditure writing a backend module that provides this functionality is not an option, this is what you can do: create a top folder for 360 product images, e.g., /360views. Now, every product within a system has an ID, SKU, UPC or a different identifier. You should carefully look at them, understand the structure thoroughly, check with the available data and finally find the logic that you can use to convert those identifiers into a path. For example /360views/123/222 can be a path for a product variant with the main ID 123 and variant id 222. In a different system, there could be no "main ID" but only variant IDs. Howsoever it turns out; the goal is to find a structure that you can communicate to the customer or the 360 product photographer so that they can create these paths, e.g., using FTP and upload the 360 product spin images in there. Once this workflow establishes, as a programmer, you only need to check with server-side code if an assumed folder exists and is not empty. Then, forward this information and data to the viewer. At least for customer presentation, testing, and proof of concept the above procedure is quick to implement. Later on, you can still provide a backend functionality for that.