Errorlog And Fn.common.php

error log size was 5 gb so i deleted. it always gives error like the one below, we dont use site as english. how can we fix it?



[05-Apr-2015 00:09:03] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/functions/fn.common.php on line 4743

[05-Apr-2015 00:09:03] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:03] PHP Notice: Use of undefined constant CART_SECONDARY_CURRENCY - assumed ‘CART_SECONDARY_CURRENCY’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:06] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/functions/fn.common.php on line 4743

[05-Apr-2015 00:09:06] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:06] PHP Notice: Use of undefined constant CART_SECONDARY_CURRENCY - assumed ‘CART_SECONDARY_CURRENCY’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:07] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/functions/fn.common.php on line 4743

[05-Apr-2015 00:09:07] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:07] PHP Notice: Use of undefined constant CART_SECONDARY_CURRENCY - assumed ‘CART_SECONDARY_CURRENCY’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:07] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/functions/fn.common.php on line 4743

[05-Apr-2015 00:09:07] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:07] PHP Notice: Use of undefined constant CART_SECONDARY_CURRENCY - assumed ‘CART_SECONDARY_CURRENCY’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:12] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/functions/fn.common.php on line 4743

[05-Apr-2015 00:09:12] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:12] PHP Notice: Use of undefined constant CART_SECONDARY_CURRENCY - assumed ‘CART_SECONDARY_CURRENCY’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:13] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/functions/fn.common.php on line 4743

[05-Apr-2015 00:09:13] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed ‘CART_LANGUAGE’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

[05-Apr-2015 00:09:13] PHP Notice: Use of undefined constant CART_SECONDARY_CURRENCY - assumed ‘CART_SECONDARY_CURRENCY’ in /home/xxx/public_html/app/Tygh/Registry.php on line 430

Please contact CS-Cart support team

[14-Nov-2016 18:44:57] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed 'CART_LANGUAGE' in /home/haciser/public_html/app/functions/fn.common.php on line 4743

[14-Nov-2016 18:44:57] PHP Notice: Use of undefined constant CART_LANGUAGE - assumed 'CART_LANGUAGE' in /home/haciser/public_html/app/Tygh/Registry.php on line 430

The problem is ongoing. Php files we been using are in the attachment

Registry.php

fn.common.php

Some 3rd party add-on is trying to use the registry during its initialization. Addons are initialized before languages and the registry will attempt to initialize on first reference.

Hi,

I am also getting this occuring when making calls during 'get_route' hook.

I have written a simple addon that will detect the presence of 'autocheckout' in URI and try to add product to cart and redirect to checkout.checkout.

It works, but I get a heap of debug messages around CART_LANGUAGE in the php logs. It seems that `fn_add_product_to_cart` is the culprit. Any suggestions?

use Tygh\Registry;

function fn_bfa_autocheckout_get_route(&$req, &$result, $area, &$is_allowed_url){

if (($area == ‘C’) && !$is_allowed_url) {

if (preg_match('!^()\/autocheckout\/(.*)\.html$!', fn_get_request_uri($_SERVER['REQUEST_URI']), $matches)){ 

  $product_id = db_get_field("SELECT object_id FROM ?:seo_names where name=?s AND company_id=?i", $matches[2], Registry::get('runtime.company_id')); 

  if ($product_id){

    fn_clear_cart(Tygh::$app['session']['cart']);
    $cart = &Tygh::$app['session']['cart'];

    $product_data = [$product_id => ['amount' => 1]];
    if (fn_add_product_to_cart($product_data, $cart, $_SESSION['auth'])){
      fn_save_cart_content($cart, $_SESSION['auth']['user_id']);
      fn_redirect('checkout.checkout');
    }else{
      fn_redirect('index.index');
    }

  }else{
    fn_redirect('index.index');
  }

}else{
  fn_redirect('index.index');
}

}

}

You might try to set $product_data to fn_get_product_data($product_id, $auth); and then set the amount before calling fn_add_product_to_cart().

If CART_LANGUAGE is not defined, then you're getting here from 'init' and not from the dispatch. Rather than use this hook, you might want to consider putthing this in a frontend/checkout.pre.php file instead.

Ok - the reason I am using the `get_route` hook is to handle some hardcoded SEO that is dependent upon some data in the database. I can't do a rewrite at the server level as that would require extra maintenance.

I have created an addon that allow management of our business to create resellers and define parameters for reseller brochure, and dedicated pages on our website. To do it at server level would require me to update server rewrites everytime they add a new reseller and SEO URL to the database.

So I went for this hook instead.

I thought this hook was useful because it provided a variable called $is_allowed_url which lets me know whether the URL has been picked up by any other core CS-CART SEO code or addons (assuming the addon was executed before mine) as a valid page. I didn't want to overwrite any pages that may have been created in the backend of CS-CART.

So I think the hook selection is ok, but yes, it is executed before languages are inited.

Any thoughts on how to approach this, only other thing I can think of is to set a flag if the preg_match is hit and then peform any 'fn_....' calls in a spot after languages have been inited...

Any thoughts on the best location to do this?

If you could provide a workflow description of what you want to do, might be able to hlep you. Generally the $is_allowed parameters are set to true before hooks. If you find something that you want the hook to fail on based on custom business logic, you would set the $is_allowed to false.

Ok - thanks.

From my experimentation, $is_allowed will already be false if it falls through all the core CS-CART detection. You then need to set it to true when you want to catch something of your own. You described the opposite to this.

To reduce maintenance of product categories, I am creating some hardcoded endpoints so that we get a friendly URL. So basically it is my own system that sits over the top of the existing product filters.

But we end up with an SEO URL attached to our manually managed category, rather than product filters appearing in the dynamic URL.

This URL is one of those:

https://www.bar-fridges-australia.com.au/commercial-glass-door-bar-fridges-and-freezers/rhino

This URL is a category in our backed:

https://www.bar-fridges-australia.com.au/commercial-glass-door-bar-fridges-and-freezers

But the additional /rhino triggers a preg_match in my get_route code and changes the dispatch to apply the appropriate brand product filter. The only way I can see to do the same thing in CS-CART is to create another sub category, give it an SEO url and manually assign products to that category.

It greatly simplifies our product management and allows us to keep a tree structure in our product categories. All relevant products are automatically added. I am using the same technique to have SEO friendly URLs for things like price ranges, dimensions and other product features.

I realise that there is similar functionality in CS-CART where you can have SEO urls for product filters, but these all go directly under the domain name.. e.g.

www.bar-fridges-australia.com.au/rhino

not:

www.bar-fridges-australia.com.au/commercial-glass-door-bar-fridges-and-freezers/rhino

And it applies to all products on the website, not just products in that sub category

Once inside a category, I still use the standard product filter features_hash in the URL, but the above keeps those URLs at bay for at least 1 more depth in our category tree.

The above example isn't one that generates any warnings - it all works fine.

I only get warnings when I call functions like fn_get_user_info() which I do when I apply the same technique to a reseller page on our wesbite. I have created a resellers addon that lets upper management maintain a list of resellers and what details the should have on their subpage on the website...

https://www.bar-fridges-australia.com.au/showrooms-stockists/vic/home-ideas-centre-melbourne

I then modify the request object and add data that be used by my custom dispatch controller files.

Here is my code that I use...

BTW - The theme check is so that other storefronts are not effected that don't use such a business specific theme.

Really hoping I haven't re-invented the wheel here!!

function fn_bfa_theme_get_route(&$req, &$result, $area, &$is_allowed_url){
//Only want this to run for storefront running bfa theme
if (!fn_bfa_theme_active()) return;

if (($area == 'C') && !$is_allowed_url) {

	$uri = fn_get_request_uri($_SERVER['REQUEST_URI']); 

	if (!empty($uri)) {

		$seo_data = NULL;
		$query_string = NULL;

		if (preg_match('!^()\/showrooms-stockists\/?$!', $uri, $matches)){ 

			if (empty(Registry::get('addons.bfa_theme.showroom_stockists'))) {
				Registry::set('addons.bfa_theme.showroom_stockists', Helpers::get_showroom_stockists_data());
			}

			$seo_data = Registry::get('addons.bfa_theme.showroom_stockists');
			$query_string = 'dispatch=showroom_stockists.all';
			$req['dispatch'] = 'showroom_stockists.all';

		} elseif (preg_match('!^()\/showrooms-stockists/(vic|nsw|qld|nt|sa|tas|act|wa)\/([^\/?]+)\/?$!', $uri, $matches)){ 

			$seo_data = Helpers::seo_lookup_showroom_stockists($matches[2], $matches[3]);
			if ($seo_data) $query_string = 'dispatch=showroom_stockists.view';
			$req['dispatch'] = 'showroom_stockists.view';

		} elseif (preg_match('!^()\/(.*)?\/([^\/?]+)\/?$!', $uri, $matches)){ 

			$seo_category_id = db_get_field("SELECT object_id FROM ?:seo_names WHERE name=?s AND path=?s AND type=?s ?p", $matches[2], '', 'c', fn_get_seo_company_condition('?:seo_names.company_id'));

			if (!empty($seo_category_id)){

				//copy original GET into request
				$req = array_merge($req, $_GET);

				$potential_seo_name = $matches[3];
				$seo_data = Helpers::seo_lookup_subcategory($seo_category_id, $potential_seo_name);

				if ($seo_data){

					//parse any existing filters
					$existing_filters = [];
					if (isset($req['features_hash'])) $existing_filters = fn_parse_filters_hash($req['features_hash']);

					//This is where the new features hash would be dynamically generated based on the request
					$new_features_hash = $seo_data['features_hash'];
					$new_filters = fn_parse_filters_hash($new_features_hash);

					//Filters are combined (preserving numeric keys)
					$combined_filters = $existing_filters + $new_filters;
					$combined_filters_string = fn_generate_filter_hash($combined_filters);

					//new query string is generated based on the filters we are applying based on SEO url
					$query_string = "dispatch=categories.view&category_id=$seo_category_id&features_hash=$combined_filters_string&exclude_filter=" . $seo_data['exclude_filter'];

					//query string is parsed and then merged into intial query, overwriting any existing keys but retains unique params specific to things like AJAX requests
					parse_str($query_string,$parsed_query_string);
					$req = array_merge($req,$parsed_query_string);

					//has to be set here and can't be checked for later as URI will be rewritten.. 
					$seo_data['dynamic_breadcrumb_uri'] = $uri;

				}
			}
		}

		if (isset($seo_data) && $query_string){
			$is_allowed_url = true;
			$req['dynamic_seo_data'] = $seo_data;
			$_SERVER['REQUEST_URI'] = fn_url('?' . $query_string);
			$_SERVER['QUERY_STRING'] = $query_string;
			$_SERVER['X-SEO-REWRITE'] = true;
		}

	}
}

}

Somewhat my error. Your original post used $is_allowed_url which as you say is generally false and you can set it to true if you want your conditions to override what cs-cart would do to validate a route.

$is_alllowed is generally set to true and in those hooks, you can set it to false if you want to disable further processing. Most commonly, these are in the payment processing hooks which are quite variable as to what responses mean.

Sorry, I can't go through and understand/diagnose your code. In any case, I would explicitly set $is_alllowed_url to false before your returns. This will account for any other addon that my also have used that hook.