tbirnseth

The "best practices" way of doing it would be to have your controller do the query and then have it put the results in a smarty variable and use it within the templates.

I.e.:

app/addons/my_changes/controllers/frontend/get_info.php containing:

<?php
if( !defined('BOOTSTRAP') ) die('Access denied');
use Tygh\Registry;
switch($mode) {
  case 'verify_user':
    $data = my_function_get_remote_data();
    Tygh::$app['view']->assign('u_data', $data);
    return array(CONTROLLER_STATUS_OK);
}
die( "Unknown mode '$mode'");

{$data.my_field}

Can you "ping" the www domain?

If not then you have a DNS issue.  If so, you can always use the non-www domain in cs-cart (assuming you cleared the cache after changing in config.local.php) and provide a redirect in your .htaccess file.  But you should be able to run your site as either www subdomain or not.

So you don't know what they did?  Would be most helpful to the rest of the community if you could find out and post the info.

All services that use Google API's now respond with HTTP/2 headers (Paypal, Recaptcha, etc.).  They will fail in cs-cart (though responses to your browser will succeed - I.e. Javascript).  For instance Recaptcha will return a green checkmark, but then you'll get a message that the code is invalid when you try to proceed.

Since cs-cart is not willing to generate an addon to patch this issue on their product, I built an addon that will address the problem and apply the patch.  It will patch any site that has app/Tygh/Http.php where the HTTP/2 header fix is not applied.

You can download the addon at: https://ez-ms.com/pr...p2_fix_v1.0.zip

The issue is that Paypal uses Google API's which now use HTTP/2 headers.  In addition to PayPal, Google Recaptcha is also broken on cs-cart.

Cs-cart is making the fix available in the next release of cs-cart but has refused to generate a service pack for the current release or an addon that will apply the fix to older versions of V4 cs-cart.  You can dig out the patch in bugtracker if you know where to look!

You can install this free addon that will apply the patch on all sites where the app/Tygh/Http.php file exists.  It is a free addon and after you install it once, you should uninstall it and throw it away.

You can install it from the URL or download it to your PC and install it as 'local'.  The addon should patch all V4 sites that utilize the Http.php module.  It will detect if the fix has already been applied or not ans act accordingly.

The URL is: https://ez-ms.com/pr...p2_fix_v1.0.zip

I find it extremely annoying that cs-cart did not address this issue for all V4 sites by issuing a security patch type of addon release or to notify customers that this issue exists.  It impacts Google Recaptcha as well as PayPal.  Hence if you use Recaptcha on checkout, your users won't be able to even get to paypal.

Suggest you install the addon to fix the issue and send cs-cart a nasty-gram for not stepping up to the issue.

I simply want the Vendor to be able to add/delete/variants to the Global Option that is associated with their product that does NOT have "apply as link" set.  As it stands, they cannot modify the Global Option.

In the NON-MVE environment, if a Global Option is added to a product without being "apply as link", then a private copy of that option and it's variants is simply assigned to that product.  I.e. it serves as a template.  We simply want the same behavior in MVE without having to go in and modify code.

Is that possible?

You would have to edit the smarty_plugins/modifier.date_format.php file to make the changes you want.  It uses fn_date_format().  You can always request a hook be added to fn_date_format().  But cs-cart hasn't responded to the "request a hook" thread in the developer forum for over a year.

Note there are several FIXME lines in fn_date_format() so some changes may be coming in a future release.

I send a ticket, they quote me 150USD for fixing the issue. Any better price? 

It's their addon.  Most other developers will not touch another's code unless the developer is out of business and/or the merchant wants extensions that the vendor is not able/willing to provide.  Note also that SimTech has started to release their addons in encoded form so that it is quite difficult to modify or review them by others.  I.e. they are no longer open source.

What is it you are trying to accomplish that you can't achieve with date/time formats?  You can always adjust the db to be whatever (or empty) date/time notation you want if you don't want to use the setting provided in the admin area settings.

It already is: https://forum.cs-car...e-commissioned/

Unless you are running a site where a single vendor's product is probably the only one (or multiples) in your cart (like a vacation rental site, etc.), why would you ever want to force a customer to go through a separate checkout process for every vendor who has items in their cart?  And if you are running a vacation rental (or similar) site then your customers would rarely ever see multiple checkouts anyway.  None of the major marketplace players implement like this (Amazon, etc) and from a customer perspective, I'd leave after seeing my first checkout didn't include all that I ordered (having a separate shipping section is fine - separate payment methods should be optional). 

If you have a different perspective on this, I'd really like to hear the advantage of having a customer do multiple checkouts for products they've added to their cart.

What's needed (from my customer feedback and development requests) is:

1) Category commissions (if you want this in standard MVE, you can use our EZ Vendor Plans Plus addon).

2) Vendor promotions on their products (catalog promotions including free shipping).

3) Configurable signup data including legal documents like TOS, licensing, tax and other business legal agreements, etc.

4) Implement the "suppliers" addon (multiple warehouses) within the context of a vendor.

5) Ability to assign tax to vendor or merchant for payment (right now, it's part of the commissioned amount which is just wrong).

It is about the release contents.  Arguably, this should probably have been in a 4.7.x thread but since the defect wasn't addressed (and they couldn't even find it afterward) it seems fine to bring it up as a topic in this thread.  The goal is to have cs-cart recognize the need to stay on top of reported defects and to confirm/address them in a timely manner. New features are great.  But if they come at the expense of an unstable and buggy platform, then their value is dramatically diminished.

I see your point. But the bug fixing policy explains why the countdown works as it does. It is exactly for the reason that making the bug occur again (which is a vital part of fixing it) can take an undetermined amount of time and may depend on an untold number of circumstances. But once the bug is confirmed, we know how soon we can fix it. 

But that would assume that it's actively being looked at.  There is no communication of any test results or replication problems.  It only sits there with no response.

Suggest you take the customer/developer perspective and ensure that all reported bugs are assessed in a timely manner (less than a week) and if there are issues reproducing it, tot communicate with the submitter so they can clarify if need be.

Leaving them in "under investigation" for months on end only goes to add to your backlog and to frustrate your customers.

The countdown should begin when the bug is reported.  Sometimes a bug sits in "under investigation" for months before it's looked at and confirmed.

Check php error_log for php errors (like memory allocation) and your Apache logs for any timeouts that may have occurred.