Hello Basara and thank you.

I had a look at "system/logs/error.txt" and all errors were coming from missing language translations.

I after disabling my custom French translation, the problem disappeared.

My translation is still incomplete, and may contain errors or missing files or strings.
I assume the default template was more robust as possibly not using those strings.

2024-02-27 12:11:50 - App Error:  AbanteCart core v.1.3.4 Missing default English definition XML file for custom_french/custom_french !
Trace:
#0 C:\xampp8\htdocs\abantecart134\core\engine\language.php on line 920
#1 C:\xampp8\htdocs\abantecart134\core\engine\language.php on line 656
#2 C:\xampp8\htdocs\abantecart134\core\engine\extensions.php on line 1156
#3 C:\xampp8\htdocs\abantecart134\core\engine\extensions.php on line 383
#4 C:\xampp8\htdocs\abantecart134\core\engine\language.php on line 234

2024-02-27 12:11:50 - App Error:  AbanteCart core v.1.3.4 Could not load language custom_french/custom_french from file "C:/xampp8/htdocs/abantecart134/admin/language/english/custom_french/custom_french.xml"!
Trace:
#0 C:\xampp8\htdocs\abantecart134\core\engine\language.php on line 928
#1 C:\xampp8\htdocs\abantecart134\core\engine\language.php on line 656
#2 C:\xampp8\htdocs\abantecart134\core\engine\extensions.php on line 1156
#3 C:\xampp8\htdocs\abantecart134\core\engine\extensions.php on line 383
#4 C:\xampp8\htdocs\abantecart134\core\engine\language.php on line 234
One idea in such a case would be having a failover mechanism that takes the original English string.
I didn't study if it would be easy or difficult to implement.

Hello,

As a user of AbanteCart 1.2.11, I am currently testing Abantecart 1.3.4 on localhost with PHP 8.2.12.

The storefront had a totally blank page, apart from the welcome message.
(No change if adding a category, a product, and clearing the cache.)

I the template in use was "bootstrap5" instead of "default" one.

I switched the template from "bootstrap5" to the default one, and the storefront displays OK.

Likely are some additional requirements for the bootstrap5 template to display, but this is very confusing for beginners.

I would suggest keeping only the default template in the initial installation, and let people download alternative templates if they want.

Cheers.

Thank you Nuno.

So here's my quick implementation of a price beautifier.

A) Removing decimals in prices on PRODUCT PAGES
In 'storefront/view/default/template/pages/product/product.tpl', after line 94 (i.e. after the "if ($display_price){}" sandwich), add:
// Remove decimals for prices ending with ".00", for both special and normal prices.
           if (strpos($special,'CHF')) {
                $special=  str_replace('.00','.–',$special);
              } else {
                $special = str_replace('.00','',$special);
              }
          if (strpos($price,'CHF')) {
                $price=  str_replace('.00','.–',$price);
              } else {
                $price = str_replace('.00','',$price);
              }
How does it work
If the product price contains "CHF" (Swiss Franc), it will replace ".00" by ".–".
For all other currencies, it will replace ".00" by nothing.
This assumes you are only using the dot as separator for the trailing decimals".

---

Added 2024/02/27
B) Removing decimals in prices for FEATURED PRODUCTS
In 'storefront/view/default/template/blocks/product_list.tpl', after line 70:
1. Add
$special = $product['special'];
$price = $product['price'];2. Copy and paste the aforementioned code that removes the decimals.
3. In the <div class="price"> ... </div> sandwich right after, replace echoed instances of $product['special'] by $special, and $product['price'] by $price.

---

---

Added 2024/02/27
C) Removing decimals in prices of products on CATEGORY PAGES
In 'storefront/view/default/template/pages/product/product_listing.tpl', after line 63, do the same as above for featured products.

---

---

Added 2024/02/27
Requirements
For the code above to work you need the decimal delimitor being the dot and not the comma.
Else, you would need to adapt the code.
To set the decimal delimitor:

• Go to "System -> Localization -> Language Definitions"
• In the "Key" field, write "decimal_point" and filter.
• Set the "decimal_point" as "." and save it.

---

Suggestion for a better implementation
A better implementation would be creating an method, or modifying existing method, so that the same code can be re-used for all price formatting.
Another improvement would be adapting the code to deal with the effective decimal delimitor.

---

@llegrand: Sorry, but my question was about if the ".–" was international or used only in some countries like Switzerland.
Furthermore, setting the decimals to 0 is not what I wanted to do : 99.95 CHF must remain unchanged. Only 99.00 CHF should be displayed as 99.– CHF.

Hi,

I am using the default theme and template.

In the list of layouts, I had a custom layout for one product "Product: My product title".
This was likely of an accidental duplicate of "Default product page" when I was experimenting with layouts.
In "Design > Layouts", I could delete the custom layout, and it seems that the product reverted back to using the default product layout.

However, I still have this question: how do I see which layout a product is using?
Apart the product name being listed in the layouts drop list (in "Design > Layout") I cannot see the information about the layout being used in the product page (Layout tab).

Thank you.

Hi,

Here is how you can set the blurb as content for <meta name="description" > on your product pages when there is no meta_description set.
Tested as working with AbanteCart 1.2.11.

1) Edit head.tpl and add the "elseif" clause as follows.
<?php if ($description) { ?>
<meta name="description" content="<?php echo $description; ?>" />
<?php } elseif ($blurb) { ?>
<meta name="description" content="<?php echo $blurb; ?>" />
<?php } ?>
2) Add a call to getBlurb() method at line 38 of head.php:
$this->view->assign('description', $this->document->getDescription());
$this->view->assign('blurb', $this->document->getBlurb());
3) Create a private variable $blurb, as well as setBlurb() and getBlurb() functions (i.e. methods) in document.php:
private $blurb; public function setBlurb($blurb){
$this->blurb = $blurb;
}
public function getBlurb(){
return $this->blurb;
}
4) At line 157 of 'storefront/controller/pages/product/product.tpl', call setBlurb() right after the call that sets the meta_description.
      $this->document->setDescription($product_info['meta_description']);
      $this->document->setBlurb($product_info['blurb']);

In my country, it is common not showing cents for round prices, and replacing them with a dot and a dash, like 59.– instead of 59.00 .

Is this way of displaying prices is commonly understood worldwide or only in my country?

If known at international level, I will implement it in the templates used by my shop with code like:
<?php echo str_replace('.00','.&ndash;',$price); ?>

Hello,

My shop is using the default French machine translation imported from GitHub.

Although most translations are understandable, there are some weird things, so that I want to make the translations myself.

Instead of editing the translations in "System->Localizations->Language Definitions", I prefer editing them in the XML files, making them reusable.

But then, how would I reimport the improved translations for backend and frontend without deleting the translations of products, categories (a.s.o.), and keeping the same language ID.
I there a way to update translations from the XML files instead of inserting new records?

My eCommerce mostly contains small and lightweight objects, so that I wanted the gram (instead of the kilogram) as main weight unit.

According to the documentation about weight:
 "The class set to 1.00000 is your base weight class. Any other weights in there need to be a factor of your base class."

So, instead of:

Weight Title	Weight Unit	Value
Gram	g	1000
Kilogram	kg	1

I wanted to have:

Weight Title	Weight Unit	Value
Gram	g	1
Kilogram	kg	0.001

But when editing, the "Value" field was read-only.

I could still make the edits by hitting the F12 key in the browser, and using the development tools to remove the "readonly" occurences in the source code for the concerned Value field, and save my edits.

However, I wonder why the lenght and weight value fields were read-only?
As a preventive measure because some extensions would possibly not be properly implemented to handle different main units properly?

Can someone check if also observing this, or if this limitation was only in my shop?

Thank you.