The current pagination may cause a conflict

[hazael]

I noticed that

• if in Virtuemart configuration I set the default paging (for example) limit=60
• Then I will choose custom for some selected categories limit=200
• The other categories will have default settings

Result
When on the front page I select a category that has a set limit=200, then all other categories (with default settings) also display the limit=200
This problem can cause bad page paging. The biggest problem arises if the website uses the memory cache.

J4/ VM 4.0.7


PS.
In the Virtuemart configuration there are pagination sequence for the List Box. sequence for 1, for 2, 3, 4. This is for a tabular layout.
The tabular layout was used 20 years ago. It is an old archaic solution. Who is using it now?  All modern websites now use a responsive flex layout.
https://css-tricks.com/snippets/css/a-guide-to-flexbox/
Bootsrap (with flex-wrap): https://getbootstrap.com/docs/5.0/utilities/flex/
Uikit handles it too: https://getuikit.com/docs/grid

[Milbo]

There are a lot shops using it. Also the flexible templates use it as base setting for the desktop. The custom appears anywhere?

[hazael]

They use the tables out of a lack of knowledge. The list of products in the table is generated by the browser much longer than in the div.
The browser must load the entire table to the end - with a large number of products it is clearly noticeable.
If you are using the flex-wrap layout, this effect is absent - only what you see on the screen loads. In addition, the products in the line are displayed flexibly in the amount depending on the width of the screen, the rest of the items are carried over to the next row.
Such a template is very easy to make in CSS - php is not needed for this at all.

[pinochico]

The browser must load the entire table to the end

We added pagination as first before products too

[hazael]

The browser must load the entire table to the end

We added pagination as first before products too

Yes, limit and limitstart should be in menu, sort, and pagination links. This is a way that guarantees the accuracy of operation.

[Milbo]

You are mixing things, or do not express it correctly.

"In the Virtuemart configuration there are pagination sequence for the List Box. sequence for 1, for 2, 3, 4. This is for a tabular layout."

What do you mean with "tabular layout"? You can create a "tabular layout" with a pen, or with div tags, or with the html table, tr, td tags. All of this creates a "table layout".

Also mobile, flexible superduppa mega lightyears engaged templates display products in "rows", because we human like it that way. Rows with vertical sections are tables. Regardless if on a book, print, paper, screen and so on. The configuration is for the function, not the tool.

Do not mix the functions with the used tools. So vmbeez may use <table>, horme3 should use divs. We wont work on an old template, if we have a new one for that reasons

[Milbo]

They use the tables out of a lack of knowledge. The list of products in the table is generated by the browser much longer than in the div.
The browser must load the entire table to the end - with a large number of products it is clearly noticeable.
If you are using the flex-wrap layout, this effect is absent - only what you see on the screen loads. In addition, the products in the line are displayed flexibly in the amount depending on the width of the screen, the rest of the items are carried over to the next row.
Such a template is very easy to make in CSS - php is not needed for this at all.

Great that it is so easy to make, but why do you bother me with this? Make such a nice template and donate it to the core. You can always make it better and donate it. We call that "Opensource Project". This is not the "Opensource Request".

The browser must load the entire table to the end

We added pagination as first before products too

That has nothing todo with it. What he means is, that if you use the old table, tr, td stuff, then the browser must load the whole table, and that divs are a lot better.

Yes, limit and limitstart should be in menu, sort, and pagination links. This is a way that guarantees the accuracy of operation.

lol, I am sorry, but all of that makes not really sense. About which template are you talking? I think you did not examine the links created by pagination

[hazael]

You don't have to have this complicated feature to display such a trivial layout.
From the template, I removed those math operations that count the number of products in a row. Incidentally, the server will do less unnecessary work.
The number of products in a row will generate itself based on the ratio of the width of one element to the entire row.
This will work with horne3 vmbeez and any other template.

A solution where you rigidly set 4 products in a row is not good because it is not responsive.
A bad example for 4 products in a row for a DIV In tabular format on big screen looks like this:

[img1][img2][img3][img4]
------------------------------hr
[img1][img2][img3][img4]
------------------------------hr
[img1][img2][img3]

on a narrow screen it looks like this:

[img1][img2][img3]
[img4]
-----------------------hr
[img1][img2][img3]
[img4]
-----------------------hr
[img1][img2][img3]




In a flex-row without this pointless line break:

[img1][img2][img3][img4][img1][img2]
[img3][img4][img1][img2][img3]

on a narrow screen

[img1][img2][img3]
[img4][img1][img2]
[img3][img4][img1]
[img2][img3]

Which solution is better? Flex or table?

HTML tables were created to fulfill one specific purpose: to show tabular data. Unfortunately, page developers have discovered that with border="0" they can use tables as a grid around which to arrange page elements.
It is still the most popular way to build websites, hindering making the Web better - more accessible, flexible and useful. 

[hazael]

lol, I am sorry, but all of that makes not really sense. About which template are you talking? I think you did not examine the links created by pagination

the pagination issue still occurs if the product listing is the home page for the domain. Nobody reports it, because nobody has a category on the home page.
Unfortunately, I am unconventional and my product list is on the main page ;-)
I note that this is Virtuemart in your latest version for Joomla 3

My only sensible solution to this problem is to add the full address to the main menu:
index.php?option=com_virtuemart&view=category&virtuemart_category_id=1&virtuemart_manufacturer_id=0&limit=90&limitstart=0


Why should the limit value be included in the menu address? What happens when it's missing? If the user on the site changes the sorting of products from 90 to 180, there is a risk that it will be saved to the Joomla cache.
Another person may not see the list of products in the default configuration. Of course, this problem only affects SEF links. the SEF link on the home page is always truncated to a slash. You won't see domain.com/results,0-90 on the home page. You'll see just domain with slash.

[pinochico]

I don't know
we don't use any joomla cache, just for many reasons of historical problems with pagination, cart...
everything is handled by the server.

And as for the categories on the main page:

This was done 7-6 years ago. It corresponds to VM1.19 and J1.5
Today the main page is supposed to be fast and show only a few products.
So no pagination on the Main Page is not desirable.

[hazael]

I need a super fast side. If my site was served directly by a PHP/Mysql server, it would be slow. The faster the site, the better your chances of selling better. Fast websites rank better in Google search engines. Many people do not know about it, but unfortunately - speed is the most important now.. I even store photos on CDN (on external servers) to speed up the site.

By default, mod_virtuemart_cart is saved in the memory cache, which causes problems. If a user adds something to the cart, there is a risk that others will see it too. Or, if the user adds something to the cart, he will see an empty cart on another page.
But there is a workaround for this by modifying the update_cart.js file. My virtuemart works 100% with Joomla cache and web browser cache.

Just add this code in the right place:

Code Select Expand

$(window).on( "load", Virtuemart.customUpdateVirtueMartCartModule );

You also need to reference your template in the module so that javascript automatically changes the data of the cart that is in the memory cache:

Code Select Expand

$(module).find(".total").html(datas.billTotal); and so on.
See how it works on my website https://piekielko.com ( 100% cache)

So no pagination on the Main Page is not desirable.

For me, it is desirable because each category on one of my pages is a different domain

[pinochico]

yep.

We also need a fast eshop and we have it.
Without Joomla cache and without VM Cart cache.
We have a special plugin that disables Joomla Cache.

Eshop loads in 1,5 seconds and has > 94% on mobile.

We debugged everything in cooperation with Rupostel.

> If my site was served directly by a PHP/Mysql server, it would be slow.

Not exactly true

> The faster the site, the better the chances of better sales. Fast sites rank better in Google search engines. Many people don't know this, but unfortunately - speed is the most important thing now. I even store my photos on a CDN (on external servers) to make the site faster.

We've known all this for 3 years and that's why we developed a system to load web content quickly.

Now if I compare the speed and corevitals of our eshop www.zelenazeme.cz and your eshop https://piekielko.com, your eshop is terribly slow.

It is important to note that Google rates the speed without buffering on a G4 mobile - WITHOUT BUFFERING MEMORY
You need to remember that your Joomla Cache will show up on the second load for customers.
Google's robot does not run twice in a row.

If I do a test on your eshop, it loads in 1.8 minutes!!! and transfers 6.1MB.
Yet the URL for the cart does not load at all.
Bad Slider on Home Page - loads large product photos and not thumbnails.

You have a lot of developer bugs there, pagination won't save you...

Finally, Google is not able to evaluate your eshop (maybe just using cache?) and if you look carefully, it is not suitable for it.

And I haven't checked Google Search Console and Rich Snippets, Canonical Links and Sitemaps

[hazael]

Currently, I have disabled thumbnail generation - my site sells, but it is not finished yet. I only launched it 2 weeks ago.
It is possible that you checked my website while I was working on it - then I have the Joomla cache disabled.

You test your website on a server in your own country. Therefore, your site has better results than my
My website's server is closer to me and I have much better performance results for me than for your country. Such testing does not make sense
These speed tests are generally not entirely true - the results depend on the data center. try to test the speed of a page that is on a server in the USA or Australia ;-)

PS. Your server has unsecured data
185.178.172.22: "PowerDNS Authoritative Server 4.4.1 (built Feb 6 2021 23:18:03 by root@2d8126b1196e)"
89.185.230.230: "PowerDNS Authoritative Server 4.4.1 (built Feb 6 2021 23:18:03 by root@2d8126b1196e)"
Exposing name server's versions may be risky, when a new vulnerability is found your name servers may be automatically exploited by script kiddies until you patch the system

[pinochico]

You are confusing the speed of a website with the ranking of Google, which only recommends a website to be crawled or not according to its ranking.

In our country, this is called confusing apples with pears.

> the results depend on the data center.

Site speed (e.g. GTMetrix, access from different countries and servers etc.) was used as a ranking 4 years ago - now it is an outdated method and tells nothing about your site.

Focus on PageSpeed Insights rankings, that's important. And it needs to be tested properly:
3G network and G4 mobile.

I have tested continuously and there is no change on your site for the better.

[pinochico]

Exposing name server's versions may be risky, when a new vulnerability is found your name servers may be automatically exploited by script kiddies until you patch the system

Yes, when name has number of Apache. I don't see this number.
But you are right, better change name, mabye to VirtueMart

I send info to our hosting company.