X-Cart v4.4.2 released

cflsystems · #**181** 02-20-2011, 03:19 PM

I cal this one a bug as well

http://forum.x-cart.com/showpost.php?p=310936&postcount=2

weckie · #**182** 02-21-2011, 09:26 AM

How do i install this on LOCALHOST without the annoying message.

Do i really have to open ports and firewall etc.

Yes i know its been a long time. I am still working with a very old x-cart version. LOL

A lot has changed meanwhile i see.

cflsystems · #**183** 02-22-2011, 11:19 AM

Another serious bug in 4.4.2, which I assume is also present in all 4.4.x and 4.3.x. Using Flyout menus with cache the url for images for categories will save in the cache image path as regulat http url which will result in security warning under https (if you choose to show the thumbs). If you are using cache for Flyout menus the html code is like this if thumbs are shown

HTML Code:

<a href="home.php?cat=xxx" class="icon-link sub-link"><img src="http://www.domain.com/images/C/c-xxx.jpg" alt="" width="16" height="16" />Category</a>

Turn off the Flyout cache and the image url changes when protocol changes.

Now the question here is: Why these images have absolute url in the first place? Is there a reason for the images not to use relative url?

How to fix it? There are few places where image url is constructed as

Code:

return $current_location . str_replace(XC_DS, '/', substr($image_path, strlen(preg_replace('/' . preg_quote(XC_DS, '/') . '$/S', '', $xcart_dir))));

The $current_location has to go. There is no need for it. This is in func.files.php, func.image.php, in a few function. I am not sure why this was done like this, so QT please provide a fix asap, as I am not sure if I take out $current_location it won't break something else. I don't see the reason anything at all to be referenced with absolute url.

cflsystems · #**184** 02-27-2011, 03:21 PM

Another bug in 4.4.2 OPC - see this
https://bugtracker.qtmsoft.com/view.php?id=39242

Man, that was supposed to be bug free version a year ago...

tom437 · #**185** 02-27-2011, 06:17 PM

Quote:

Originally Posted by yehudah

This is so frustrating I have 2 clients waiting for their stores to go live and there is no stable release of 4.4x yet

When will the fixes be done

I have a suggestion for the next version set up a few beta testers in the x cart community and try to fix ALL the bugs be fore you release the final version. Come on qt you are big enough to do things proper

Hello Yehudah,

Who are you hosting your website with (www.party-wholesale.com)?

Thanks

cflsystems · #**186** 03-02-2011, 06:57 AM

Ok this is not exactly a bug but it has to be fix and fast. Why on Earth 4.4.x was designed to load every single css file available no matter if the module is in use or not, for active modules? What is the login behind loading OPC css file(s) on site front page or products list page? What is the login behind loading Upsell products css file(s) on checkout pages? QT - PLEASE, an answer.

service_css.tpl loads on every single page and has the following code in it

Code:

{foreach from=$css_files item=files key=mname}
  {foreach from=$files item=f}
    {if ($f.browser eq $config.UA.browser and $f.version eq $config.UA.version) or ($f.browser eq $config.UA.browser and not $f.version) or (not $f.browser and not $f.version) or (not $f.browser)}
      {if $f.suffix}
        {load_defer file="modules/$mname/`$f.subpath``$smarty.config.CSSFilePrefix`.`$f.suffix`.css" type="css" css_inc_mode=$ie_ver}
      {else}
        {load_defer file="modules/$mname/`$f.subpath``$smarty.config.CSSFilePrefix`.css" type="css" css_inc_mode=$ie_ver}
      {/if}
    {/if}
  {/foreach}
{/foreach}

This loads every css file in $css_files array regardless if it's needed or not. And $css_files array is populated by this code in init.php

Code:

if ($active_modules) {
    foreach ($active_modules as $active_module => $tmp) {
        $_module_dir  = $xcart_dir . XC_DS . 'modules' . XC_DS . $active_module;
        $_config_file = $_module_dir . XC_DS . 'config.php';
        $_func_file   = $_module_dir . XC_DS . 'func.php';
        if (
            file_exists($_config_file)
            && is_readable($_config_file)
        ) {
            include $_config_file;
        }
        if (
            file_exists($_func_file)
            && is_readable($_func_file)
        ) {
            include $_func_file;
        }
    }
}

which calls config.php for every active module. config.php assigns all css files for its respective module to $css_files array.

Who was the bright mind behind all this? Did we really needed more bloated css? 4.4x. was suppose to be clean, css driven, up to the standards cart. Do you think Google likes to see 15+ different css files loading without even a single line from them being used? WOW. I have to revise the first line - this is a BUG, a huge one.

And by the way almost same applies to the js files loading with every page load. Lots of them and at least half of them are needed on specific pages only.

To somehow reduce that load make sure you turn off every module you don't need/use.

ADDISON · #**187** 03-02-2011, 07:01 AM

Steve you need a medal. Please report it in bugracker.

Quote:

Originally Posted by cflsystems

Ok this is not exactly a bug but it has to be fix and fast. Why on Earth 4.4.x was designed to load every single css file available no matter if the module is in use or not, for active modules? What is the login behind loading OPC css file(s) on site front page or products list page? What is the login behind loading Upsell products css file(s) on checkout pages? QT - PLEASE, an answer.

service_css.tpl loads on every single page and has the following code in it

Code:

{foreach from=$css_files item=files key=mname}
  {foreach from=$files item=f}
    {if ($f.browser eq $config.UA.browser and $f.version eq $config.UA.version) or ($f.browser eq $config.UA.browser and not $f.version) or (not $f.browser and not $f.version) or (not $f.browser)}
      {if $f.suffix}
        {load_defer file="modules/$mname/`$f.subpath``$smarty.config.CSSFilePrefix`.`$f.suffix`.css" type="css" css_inc_mode=$ie_ver}
      {else}
        {load_defer file="modules/$mname/`$f.subpath``$smarty.config.CSSFilePrefix`.css" type="css" css_inc_mode=$ie_ver}
      {/if}
    {/if}
  {/foreach}
{/foreach}

This loads every css file in $css_files array regardless if it's needed or not. And $css_files array is populated by this code in init.php

Code:

if ($active_modules) {
    foreach ($active_modules as $active_module => $tmp) {
        $_module_dir  = $xcart_dir . XC_DS . 'modules' . XC_DS . $active_module;
        $_config_file = $_module_dir . XC_DS . 'config.php';
        $_func_file   = $_module_dir . XC_DS . 'func.php';
        if (
            file_exists($_config_file)
            && is_readable($_config_file)
        ) {
            include $_config_file;
        }
        if (
            file_exists($_func_file)
            && is_readable($_func_file)
        ) {
            include $_func_file;
        }
    }
}

which calls config.php for every active module. config.php assigns all css files for its respective module to $css_files array.

Who was the bright mind behind all this? Did we really needed more bloated css? 4.4x. was suppose to be clean, css driven, up to the standards cart. Do you think Google likes to see 15+ different css files loading without even a single line from them being used? WOW. I have to revise the first line - this is a BUG, a huge one.

And by the way almost same applies to the js files loading with every page load. Lots of them and at least half of them are needed on specific pages only.

To somehow reduce that load make sure you turn off every module you don't need/use.

cflsystems · #**188** 03-02-2011, 07:05 AM

Reported it already. I can't believe what they have done sometimes

gb2world · #**189** 03-02-2011, 06:38 PM

Probably, their intended method is to amalgamate all the css and javascipt with the intent being that on a production site, the css and javascript speed-up tools will be used. The problem is, after all the initial reported bugs associated with the speed-up tools, it is unclear if they are dependable for production yet. For example - the method in drupal has individual css files being loaded for many addons and themes used, so you can end up with many small, focused css files depending on what you have enabled in your configuration. But, when you are ready to go to production, there are effective tools to aggregate and compress the css. QT appears to want to use a similar method for performance enhancement, but they are starting with css from previous versions that is not designed modularly, and the speed up tool appears to not be trusted by many users yet - so the css architecture is actually worse than on previous versions.

---

cflsystems · #**190** 03-02-2011, 08:06 PM

Even if speedup tool works ok why load all unused css files and js scripts. Just makes the load bigger for no reason.