I think 1.2.16 and 1.3.0 can run on PHP 7.1 why did you choose 1.2.11?

• Because for AbanteCart 1.2.16 the minimal PHP version was not mentioned. We know there is PHP 7.4 support, but there is no mention about compatibility with previous PHP versions.
• Because of similar issue with AbanteCart 1.3.0, for which PHP 8 support was mentioned, but not PHP 7. So, I believed it was incompatible with PHP 7.
• Because I knew from another post read on the forum that the 1.2.11 version was compatible with PHP 7.1. Hence, it was for me a hassle-free choice.

So, in short, the lack of information about PHP compatibility is why I chose AbanteCart 1.2.11 rather than a newer version.

One big strength of Prestashop is that their documentation is very clear about system requirements, with a very clear "PHP compatibility chart" where you instantly see which version of their shopping cart system is compatible with which (lowest - uppest) version of PHP.
See https://devdocs.prestashop-project.org/1.7/basics/installation/system-requirements/

I believe that a similar PHP compatibility chart would be very useful fo AbanteCart.
I understand that testing a large codebase with all versions is lot of work, but even if not all cells of the compatibility matrix are colored in green or red, they could be left in grey color, until someone in the forum confirms wether a combination is working or not.

Hello,

I am using AbanteCart 1.2.11 for a few weeks and just imported around 140 products from a previous tentative with PrestaShop.

I am the kind of person who likes to get my hands dirty, formatting SQL INSERT queries though a spreadsheet and a code editor.
There were no exceptions this time, and I imported my products through phpMyAdmin.
To create categories, I used AbanteCart's admin.

Here are few ideas coming from my experience with AbanteCart.

---

1) Please, show SKU everywhere!

SKU numbers are my personal product references in my catalog.
These are my product IDs, way more that the product ID that AbanteCart's gives to products.

I mostly sell spare parts, and most of them have a model.
But the SKU remains the reference that uniquely identifies a product in my inventory (Excel file, a.s.o.). Even the picture names of my products contains the SKU.
I assume that also for those of you selling new items in quantities, the SKU is of vital importance.
Currently, that my products (identified by their SKU) and their prices were imported, I still need to write their name in three languages, and to upload their images.

I applied this quick-fix temporary solution of duplicating the SKU in the "model" field using this SQL query:
UPDATE `ac_products` SET model=sku WHERE (model='' AND sku!='');

It is the only way for me to know who is who.

To my opinion, the SKU should be displayed at the following locations:

• as a column in the products list

, preferably between the product thumbnail and the "name" field.

• at top of the General tab, right to the cloning button
• at top of the Media tab, and of all other products tabs, at a similar location (top left).

The SKU being the "instant identifier" of a product, I suggest these locations in the tabs rather than in the product information header, so that the SKU is more highlighted.

---

2) Attach a product to a category directly from the product list.
After importing my products, I had to attach them manually to the categories for my AbanteCart shop (which were different from those that I had in Prestashop).
I had to open two tabs in phpMyAdmin, first one with the view described in my answer to Old-Paul about bulk moving products to a different category, and second one showing the records of the 'category_description' table.
By comparing, I could manually edit the category IDs in the first tab, but it was painful.
I would suggest a one character wide droplist in the product list, that upon click would expand itself like a popup, Ajax-load categories, and let pick one. The categories could be listed in a classical drop list, or expandable tree.
A good location for the one-char-wide droplist could be beween the checkbox and the product thumbnail.

---

3) Add an EAN13 column in the backend, and structured data in the frontend.

Nowadays, EAN numbers as well as structured data (JSON-LD) are essentials to e-commerce.
I would really suggest adding a column for an optional EAN13 number in the main product table as a core feature.

Maybe I missed something, but I could not see JSON-LD data as native in AbanteCart.
There is in the market place a "SEO Rich Snippet Microdata for Products" extension that I didn't test.
Prestashop offers natively a field for EAN (as well as a few ones like ISBN which is limited to books).
I'm not in favor of increasing the number of fields excessively, but EAN sounds to me like a "must have".

---

4) Save and directly jump to next translation.
When saving a new product, if the shop is multilingual, I would appreciate two buttons: "Save" and "Save and jump to next tranlation".
So, after saving, one could directly be directed to the fields in which to edit the next language without having to select the language in the drop list and wait again that everythings loads.

---

5) If there are few languages: bar of toggle butttons instead of drop list.
I am aware this would increase code complexity, and reduce the core principle of AbanteCart's scalabily unless the drop list remains, but most shops are likely in just a few languages. In the admin, a bar of toggle buttons rather than a drop list would bring some gain of performance when editing products, categories, a.s.o.

---

6) Don't resize and don't rename the main product images
All my images are pre-processed and optimized (size, compression, ...) depending on the level of detail needed.
The automatic resizing of pictures to a size of 500 pixels is very painful and makes the zoom-scroll feature almost useless.
Make the resize optional with a toggle button in "System > Settings > Appearance" (set on "Off" by default) near to the suggested image size.
For users that upload unoptimized images, a dialog box could be fired, suggesting a resize and asking them if they accept it.
I will detail this idea more in detail below.

---

7) Older dashboard pictures were better
It is a personal opinion, but I find the dashboard pictures from version 1.2.11 better than those of version 1.3.4.
Although a bit old-fashioned, they were clearer than those of version 1.3.4.
They were more intuitive, without the need for some further cerebral decyphering.

---

As complement to the detailed answer posted by georgeplunkit, here's what I would try first:

• Optimize image sizes. Use the webp format for pictures, with lossy compression. The quality can often be set to as low as 40% to 70%. Save a few picture in different qualities: 40%, 50%, 60%, 70%, 80%. Compare how much the size varies, and save your picture with the lowest quality that you consider being acceptable for your visitors.
  Batch converting images to webp is possible with Irfanview as well as other softwares.
  If you cannot use webp, use JPEG. In the rare case you would need a lossless compression (in webp or png) to keep some edges sharp, decreasing the color depth to 256 colors will reduce the image size. However, this is not as much as efficient as a lossy compression.

  ---

• Host your website on a quality hosting. Shared hosting is enough if you take a good one. Price is typicaly around 5$-7$ a month. Don't take a too cheap hosting as they will have to excessively share available hardware ressources.

  ---

• Avoid special fonts as much as possible, as they have to be downloaded when visitors reach your web site. If you are using some custom theme, make sure it is not calling too much ressources like special fonts.

  ---

• Use minimized (=compressed) versions of Javascript libraries and scripts. Compress them if this was not already done.

  ---

• When visiting the site from your browser, hit the F12 key, go to the Network tab and see which ressources take time to load.

Hello!

From what I see, this feature doesn't seem implemented yet, but it is easy to do such batch edition by creating a View.
In phpMyAdmin (which is almost for sure available on your localhost or web hosting), just paste the following MySQL query in the SQL tab:

---

CREATE VIEW batchEditProductCategories AS (SELECT `t`.`product_id` AS `product_id`,`t`.`category_id` AS `category_id`,`p`.`model`,`p`.`sku` FROM (`abantecart1211`.`abc_products_to_categories` `t` JOIN `abantecart1211`.`abc_products` `p` ON (`t`.`product_id`=`p`.`product_id`)));

---

In above code, 'abantecart1211' is the name of my database and 'abc_' is the name of the table prefix. Adapt it to the specifics of your installation.
Specifying the name of the database is optional.

Once the view created, you can perform operations on it exactly like if it was a table.
This means that in phpMyAdmin, you can simply double-click table cells to edit their values, and that you can as well apply SQL queries.

Listing only those products with an empty category:

---

SELECT * FROM batchEditProductCategories WHERE category_id='';
Note that the WHERE condition on empty categories could also habe been applied to the query that created the view.

---

Batch updating records with an SQL query
To give you and idea about how powerful SQL can be, this unlikely example sets to 82 the category_id of those products where the sku starts with "P", ends with "56", and only if the current category_id is 23 or 34:

---

UPDATE batchEditProductCategories SET `category_id`=82 WHERE ((`category_id`=23 OR `category_id`=34) AND `sku` LIKE 'P%56');

---

Such edit will reflect is the tables to which the view is pointing to.

To enrich the view created above, you can get the category names from the `category_descriptions` table.
The product names can also be obtained from the `products_description`table, either as alternative or as complement to the sku and model fields from the `products` table. This is of course performed by joining tables using "JOIN ... ON" in your query.
If your

If your site is multilingual, and your view is getting names from the`category_names` and `product_names` tables, you will need to add "... WHERE language_id=1" (or alike) in your query, to avoid duplicates coming from the multilingual categories and product names.

A very good way for you to learn SQL by doing.

Hope this helps. 

Just for your info, South Sudan is not the South of the Sudan, but an independant country that is missing in the database  of Abantecart 1.3.4.

I found this when setting delivery locations.

Hello,

As AbanteCart likes standardization, I would suggest numbering languages according alphabetical list for the ISO 639-1 codes from the International Organization for Standardization.

This would mean that "language_id" would be set to:

• 41 for English (instead of default 1)
• 149 for Spanish
• 29 for Chinese
• 55 for German
• 48 for French

a.s.o.
instead of being attributed by the auto increment.

If developers of language extensions would follow this simple rule, it would be much easier to create datasets that can be easily be imported by every user of AbanteCart.

Consider for instance how zone descriptions can be imported by SQL queries:

INSERT INTO `ac_zone_descriptions` (`zone_id`, `language_id`,`name`) VALUES (...,...,'')

Of course, some languages will probably never be imported, like dead ones (e.g. 93,'Latin','la), but it would just suffice to check the list to know which id should be used for each language.

I have prepared the full CSV list of 183 languages, alphabetically ordered, as well as the SQL query equivalent for AbanteCart's list languages list.

I hope there will be some traction for this practice. Writing a few updaters for existing shops should not be a big issue.
Awaiting for your feedback.

Step 1: adding new fields to store the location of each of your products
It it easy to edit the structure of the "products" table using phpMyAdmin.
There is already a "location" column in it, but you could add more columns.

Step 2: consulting and editing field values

2.1 Basic method is editing/consulting the value for the new fields directly in phpMyAdmin.

Writing a basic SQL query to search for a product is really easy:
SELECT product_id,model,sku,location,shelf,bay FROM `abc_products` WHERE sku='T1234';

This example query would display a few fields for the product with the reference "T1234" (sku = Stock Keeping Unit).
I added the "shelf" and "bay" columns in the query.

If you don't feel comfortable with SQL queries, phpMyAdmin also has a "Search" tab and will build the queries for you.
However, you will quickly be more efficient learning how to write SQL queries.

2.2 Improved solution: integrating the new columns from your database in AbanteCart admin.

• use a tool like grepwin to locate all files with occurences of a column name that already existed is typical of the product table (e.g. "ship_individually"). This will easily let you locate which source files should possibly be edited. By double-clicking each of the found files, you can then edit it in your favourite code editor (e.g. PSPad).
• Adapt the SQL queries that should be (INSERT, UPDATE, SELECT) by adding the names of your additional columns, and edit the templates that should display the additional fields.

2.3 Expert solution
You could also write an extension, which basically makes what I described at 2.2 more reusable, but would require you to learn about how to write AbanteCart extensions. This is much more complex that the simple method I described.

Hope this helps.

Hello,

I am new to AbanteCart and would like to tell that I am falling in love with it!

I am still building my ecommerce on localhost (xampp/PHP 7.1.33) and using the 1.2.11 version of AbanteCart.

Among things that I especially appreciate is that AbanteCart is lightweight and responsive.
Having the main fields of products being directly editable in batch mode in the backend, without having to access each product individually is how every ecommerce system should be.
The fun things is that I had partly redesigned the backend of another system, and when looking at the product edition in AbanteCart, is is close to what I had designed and coded, with ajaxified fields. So, I really feel comfortable using AbanteCart's backend, almost like if I had written it.
We obviously share the same philosophy.

The backend of an ecommerce system is of uppermost importance, and AbanteCart excels in this regard.
I like the fact that AbanteCart is designed with efficiency of catalogue/product edition/etc. in mind, with a compact laptop-friendly GUI, as opposite to alla moda designs of some other systems that prove being totally unefficient for managing products.
I didn't test the in development version 2.0 yet, but hope that the spirit of Abantecart 1.x remains.

Congratulations and keep on with the good work.