X-Cart forums

[Cpt.Crashtastic]

As you may have discovered the Wki for Litecommerce is incorrect for the current version. This currently works for XCN1.1.0

First we have to create some folders. The first is the developer id and the second the module name. these are placed in the classes/Xlite/Module folder.

You should end up with classes/XLite/Module/<ADEV>/<ASKIN>

Replace <ADEV> and <ASKIN> with appropiate names for this and the following file.

The next item to create is a php file called Main.php

<?php


namespace XLite\Module\<ADEV>\<ASKIN>;

/**
 * The skin module main class
 *
 */
abstract class Main extends \XLite\Module\AModule
{
    const CUSTOMER_SKIN_DIR = '<ASKIN>'; //This is the name of the folder that will contain our skin which reside in the skins folder
    
    
    /**
     * Author name
     *
     * @return string
     */
    public static function getAuthorName()
    {
        return '<ADEV>';
    }

    /**
     * Get module major version
     *
     * @return string
     */
    public static function getMajorVersion()
    {
        return '1.1';
    }

    /**
     * Module version
     *
     * @return string
     */
    public static function getMinorVersion()
    {
        return '0';
    }

    /**
     * Module name
     *
     * @return string
     */
    public static function getModuleName()
    {
        return '<ASKIN> Skin Name';
    }

    /**
     * Module description
     *
     * @return string
     */
    public static function getDescription()
    {
        return 'A skin for your web site';
    }
    // This function registers the new skin folder
    /**
     * Module skin directory
     * @return string
     */
    public static function init() {
	parent::init();
	\XLite\Core\Layout::getInstance()->addSkin(static::CUSTOMER_SKIN_DIR, \XLite::CUSTOMER_INTERFACE);
    }
}

NOTE: DO NOT CLOSE THE PHP TAG
    

Next create the the skin folder and a language folder 'en'. This resides in the skins folder so you have
skins/<ASKIN>/en

At this point you can copy the theme.css and style.css files from the skins/default/en/css folder to a new folder 'css' under our en folder.

Next go to admin and Maintenance->Rebuild Cache (Put the kettle on)

Next go to Add Ons and the new module should be listed. Turn it on and scroll to the botton and save changes. The cache will be rebuilt (Make Tea).

If you go to Settings->General settings select the performance tag and deselect the aggragate css and js options you should see when you reload the front end that the site is now using the css from the new skin.

I will extend this with a little more functionality over the next couple of days. For example relocating widgets.

[Cpt.Crashtastic]

In the same Main.php file we can extend the init() function to add a skin for mail

First define the new folder name as a constant

const <MAIL_SKIN_DIR = 'myMailSkin';

then add this line below the line that initializes the main skin dir.

\XLite\Core\Layout::getInstance()->addSkin(static::CUSTOMER_SKIN_DIR, \XLite::CUSTOMER_INTERFACE);

//New Line

\XLite\Core\Layout::getInstance()->addSkin(static::MAIL_SKIN_DIR, \XLite::MAIL_INTERFACE);

There are other skins you can alter!

[Cpt.Crashtastic]

Adding a custom block

No point in me retyping this so follow this link

Look here for full instructions.

Note:

You do not need to create a seperate module for this. It can live happily in the skin module if you use the second method which is preferred. If you use the second method do not include the @List directive as it is already defined in /View/MyWidget.php between the namespace and the class declaration.

If you do it may appear twice.

For those that are really interested the View Lists are stored in the database in a table named xlite_view_lists.

[xplorer]

Awesome!

We are looking forward to the next series

[Cpt.Crashtastic]

Now for a really useful function.

The page layout is constructed from lists. A bit like the Russian dolls in concept. Each list consists of templates which are ordered by a weight attribute. The higher the weight the lower down the list the template will appear.



So roughly we have this structure

The main page which is ⌠layout.main■

The main page contains list contains

A header list
A Sidebar list
A content list
A footer list

The header list contains

A left list
A centre list
A right list

And so on....


Now as an example we currently have the minicart in the top right corner of the main page and we want to move it to the sidebar. It resides in the ⌠layout.header.right■ list. If you check this in under xlite_view_lists in your database you will see that it is defined in XLite\View\Minicart.php.

Hint : There is a quick way of figuring out which list you need to find in the database. Check the HTML of the generated page and for each main block of code, check the class. It should give you a good idea what you are looking for

Looking at XLite\View\Minicart.php

The DocBloc contains the directive

@ListChild (list="layout.header.right", weight="100")


How do we change this? Its not possible to override the class and re-declare this as the @ListChild directive is outside the class declaration. You would end up with two minicarts or a mess! It's all done in the Main.php that was created for the skin module earlier. Of course you could create a module to do this all on its own but thats unecessary duplication of code just for this. There is a built in function which will do this job for you. All we have to do is provide it with the correct paramaters to find the list and the parameters that needs to be changed.

  /**
 * This method runs at the end of the cache rebuilding process and relocates the lists.
 *
 * @return void
 */
public static function runBuildCacheHandler()
{

    /**
     * @return $string List
     */
    $item1 = \XLite\Core\Database::getRepo('XLite\Model\ViewList')->findOneBy(
        array(
	//The parameters to find our list
            'list' => 'layout.header.right',
            'child' => 'XLite\View\Minicart',
        )
    );

    if ($item1) {
        // Move the widget to another "view list"
        $item1->setList('sidebar.first');
    }


// At this point the list has been changed but the database has not been updated.
// The next section of code is another example where the list and the weight are changed of the main menu

    /**
     * @return $string List
     */
    $item2 = \XLite\Core\Database::getRepo('XLite\Model\ViewList')->findOneBy(
        array(
            'list' => 'layout.main',
            'child' => 'XLite\View\Menu\Customer\Top',
        )
    );
    if ($item2) {
        $item2->setList('layout.header.bar');
        // Adjust the menu weight"
        $item2->setWeight('150');
    }

//Here the data is pushed to the database

    if ($item1 || $item2) {
        // Push the changes into the database
        \XLite\Core\Database::getEM()->flush();
    }
    
    
}

Hopefully this is clear to those that read but feel free to ask questions. This piece of code really opens the door to understanding how XCN skins work under the hood. It's a massive leap in the right direction but it's a bit of a learning curve for us die hard xcart users.

This is only a simple example and it is necessary to do a little more work to make it work perfectly. When I have a moment I will atttach a complete module.


If you are familiar with TWIG, SYMPHONY, DOCBLOCK and DOCTRINE2 then you will be well on your way to understanding XCN! A bit of bed time reading

[cflsystems]

Heavy stuff

[totaltec]

It's quite a transition. I feel like a helpless newb when trying to mod XCN, even a simple change takes a lot of effort. I miss the built in tools that XC has, webmaster mode and the template editor.

I'm fumbling my way through it though, it does seem like a step forward in terms of code structure, but it is also a massive leap backward with regards to functionality.

[Cpt.Crashtastic]

Overriding a modules css

Even though we have declared another skin which overrides the default skin, it does not override the js or css files of a module created by another developer. Lets take for example the Product Options module which uses product_options.css to format the product options. This resides in

skins/default/en/modules/CDev/ProductOptions

First of all this structure needs creating for our module


skins/default/en/modules/<ADev>/<ASKIN>/ProductOptions


Then copy the product_options.css and rename it to <ADev>_product_options.css


In the skin module Main.php, the next step is to declare that the skin module is dependent on the product options module.

    public static function getDependencies() {
      return array('CDev\ProductOptions'); // Product Options Module
    }

The next step is to replicate the folder structure in our module for the View we want to override in CDev/Product Options. In this case it's Product.php

<ADEV>/<ASKIN>/ProductOptions/View/

Create a php file Product.php again to replicate the structure at this location and enter the following code.

namespace XLite\Module\<ADEV>\<ASKIN>\ProductOptions\View;

/**
 * Product widget
 *
 */
abstract class Product extends \XLite\View\Product\Details\Customer\ACustomer implements \XLite\Base\IDecorator
{

    /**
     * Register CSS files
     *
     * @return array
     */
    public function getCSSFiles()
    {
        $list = parent::getCSSFiles();
        $key = array_search('modules/CDev/ProductOptions/product_details.css', $list);
   
        if($key) {
          unset($list[$key]);
        }

        $list[] = 'modules/<ADEV>/<ASKIN>/ProductOptions/<ADEV>_product_details.css';

        return $list;
    }
}

This code extends and decorates the ACustomer class. The getCSSFiles function retrieves the list of css files for the View created by Product.php and assigns the array to $list. Now it is possible to find the product_details.css within this list and remove it.The content of each element of the array contains the full path to the file which is added to the array in CDev/ProductOptions/View/Product.php. It is important to know that another module could be doing the same thing as your module so you must check that the $list array contains the string before attempting to remove it.

The same can be done with the JS files.

There are other ways of doing this which are easier. This method ensures that your module is transportable to another site or you can even switch between themes on one without having to edit any css.