VirtueMart Forum

VirtueMart 2 + 3 + 4 => Virtuemart Development and bug reports => Topic started by: hazael on November 08, 2022, 10:26:59 AM

Title: The current pagination may cause a conflict
Post by: hazael on November 08, 2022, 10:26:59 AM
I noticed that
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
Title: Re: The current pagination may cause a conflict
Post by: Milbo on November 08, 2022, 21:38:58 PM
There are a lot shops using it. Also the flexible templates use it as base setting for the desktop. The custom appears anywhere?
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 09, 2022, 00:27:21 AM
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.
Title: Re: The current pagination may cause a conflict
Post by: pinochico on November 09, 2022, 08:30:32 AM
QuoteThe browser must load the entire table to the end

We added pagination as first before products too :)
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 09, 2022, 10:45:32 AM
Quote from: pinochico on November 09, 2022, 08:30:32 AM
QuoteThe 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.
Title: Re: The current pagination may cause a conflict
Post by: Milbo on November 09, 2022, 11:01:36 AM
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
Title: Re: The current pagination may cause a conflict
Post by: Milbo on November 09, 2022, 11:10:09 AM
Quote from: hazael on November 09, 2022, 00:27:21 AM
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".

Quote from: pinochico on November 09, 2022, 08:30:32 AM
QuoteThe 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.

Quote from: hazael on November 09, 2022, 10:45:32 AM
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
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 09, 2022, 16:48:27 PM
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.  ;)
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 09, 2022, 17:05:10 PM
Quote from: Milbo on November 09, 2022, 11:10:09 AM
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.
Title: Re: The current pagination may cause a conflict
Post by: pinochico on November 10, 2022, 20:28:25 PM
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.
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 10, 2022, 21:20:37 PM
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:
$(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:
$(module).find(".total").html(datas.billTotal); and so on. :)
See how it works on my website https://piekielko.com ( 100% cache)

Quote from: pinochico on November 10, 2022, 20:28:25 PM
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
Title: Re: The current pagination may cause a conflict
Post by: pinochico on November 11, 2022, 10:12:30 AM
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
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 11, 2022, 15:56:39 PM
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
Title: Re: The current pagination may cause a conflict
Post by: pinochico on November 11, 2022, 17:48:24 PM
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.
Title: Re: The current pagination may cause a conflict
Post by: pinochico on November 11, 2022, 21:21:51 PM
QuoteExposing 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 :D

I send info to our hosting company.
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 12, 2022, 13:28:21 PM
Of course, every tip is valuable. In my free time, I will correct these mistakes. The worst thing is that I have to do everything myself. Constantly something new comes up or something that was so great now is useless.
A perfect example is AMP. The AMP technology is on its way out and most users are progressively phasing it out, while Google itself no longer requires it for SERP ;-)
I have the impression that these testing tools do not always tell the truth. Out of 10 tests of the same source, I had a result that was different each time in the range of 80-95 on a scale from zero to 100.
Speed testing based on the old 3G network also seems pointless. Why don't they test 2G? Fast LTE is even in the forest. 5G is already working in the city..

I have the impression that we create websites more for tools than for people  ;)
Title: Re: The current pagination may cause a conflict
Post by: pinochico on November 13, 2022, 03:38:05 AM
QuoteSpeed testing based on the old 3G network also seems pointless.

You can ask google self

QuoteI have the impression that we create websites more for tools than for people

Yes, since google has been ranking search results according to its tools, websites are adapting to the tools and not the people
Title: Re: The current pagination may cause a conflict
Post by: hazael on November 14, 2022, 17:43:24 PM
Quote from: pinochico on November 13, 2022, 03:38:05 AM
Yes, since google has been ranking search results according to its tools, websites are adapting to the tools and not the people
These tools only improve the quality of the website. Even if you have a website performance of 100%, it does not mean that you will be number 1 in Google rankings.
The funniest thing is that if I remove javascript from google analytics, I have 99% efficiency. If I add this script at the very bottom of the body section with the "defer" or "async" attribute, it doesn't change anything - the performance drops by 10%. ;-)

For me, the most important indicators are: PR, DA, TF, CF, AlexaRank and a lot of unique and valuable content on the site. Everything else has a marginal impact on your position in Google