Use case: WC Archive page with CSS Grid + Rows & Columns

Hi!

Please allow me to describe this scenario. I believe solving it could open up a lot of creative potential with Pro.

imagine a more complex layout on the WC archive page:

It starts with a CSS Grid that displays first 7 products. Basically we have 7 cells, and each has a consumer set to one. Also, if there are less than 7 products at display, Each cell has a condition {{dc:looper:count}} >= with the incrementally larger value. So if there is no product, the cell is invisible.

Now, the WC archive will most probably need to show more than 7 products, so the rest is spilling over to a Section with Looping columns that are showing the remaining products. Unfortunately, the only way to set the offset here is to turn the Looper provider on, to be able to show products from 7 onwards. This is a Provider within a WC archive provider, which is not efficient.

Also, this provider will show the default 10 products, and cannot have a pagination, because of the nesting of the providers. We could set it to consume some high number so it shows everything, but this is where serious performance issues are starting.

It would be fantastic if we could somehow ā€œspillā€ the product count outside the ones that are consuming ā€œoneā€, even if we are talking about different elements. Like Starting with CSS Grid and continuing with standard layout, inside the WC archive page.

Maybe an Offset option on the Consumer?

Thanks!

2 Likes

I’ve wondered if we might need to add some settings to the Layout itself to adjust the main query but I’ve been hesitant because of how it opens a whole new can or worms related to pagination.

For your use case above, the hidden rewind option might be what you need. We haven’t figured out the best place to put it in the UI yet, but it’s possible to rewind a Looper Provider.

Try inspecting your Column and opening the dev console. Look for looper_consumer_rewind and toggle it on. Now the Column will start consuming from the first item again. Under the hood this uses the WordPress rewind_posts function so it doesn’t run a new DB query which is great for performance.

This should also reset the looper index, so you could add a condition on the Column like {{dc:looper:index}} > 7 to skip the first 7 posts. To make sure there’s not an empty Row you could add a condition base on {{dc:looper:count}} to the Row to hide it when there are no posts to show beyond 7.

1 Like

Ah yes! You have mentioned the rewind option back in the ACF Repeater thread. :slight_smile:

Sounds great. Will test it soon.

Thank you Alexander!

EDIT: Got it working beautifully! :slight_smile:

My new issue is with pagination now. :confused:

First 7 product are in the CSS Grid, and the rest is in the Row/Columns consumer/provider setup that is rewinded. 20 products in total on the first page. There are two more pages to go.

I have placed the pagination to the end of the page expecting that /page/2/ will start from the first product in the Grid, and end in the last product of the second page in the Row.

However, both Grid items and Row items are paginating separately.

The Grid portion of product are not continuing from product #21, but from Product #13, and the Row portion is not paginating at all.

I have set the total number of posts to 20 in settings, so that is why the total is 20.
If I switch the Row product count from default to 20, the same is happening.

I am not sure if this is my error or an opportunity to improve Pro. I have added the login details to the site if it means anything to you. :slight_smile:

So I’m not seeing which one is being rewound now. Sorry for the delay here, maybe you’ve changed something in the past few days.

It looks like you have a Looper Provider instead. The only time pagination works is if you’re using the native WordPress (or WooCommerce) root queries. Anytime you use your own Looper Provider, it disconnects from Pagination because the offset is zero again.

Element Conditions don’t actually filter anything, instead they don’t visually display something. As far as WordPress is concerned, you actually output all the items that came from the provider. Rewinding the looper helps if you want to break up which posts are displayed and where, but you need to make sure all the posts do get output somewhere or it will throw off pagination. If you want to omit certain categories from the Shop index you might want to look into customizing how WooCommerce actually creates that list of products to display.

1 Like

Sorry about that. Yes, I have ended up leaving the provider on, on the second section. Probably in the attempt to filter-out (or hide) certain product like Gifts and Accessories. I wanted to display those in a separate section at the bottom.

So it seems that there is no effective way of separating product categories on the WC Layout, with keeping the pagination in at least one of the groups.

This is the layout:
(Not sure how to indent lists here).

[+] Section 1 (Hero)
[+] Section 2
[+] [+] Grid
[+] [+] Cells (Consumer)
[+] Section 3
[+] [+] Row
[+] [+] Columns (Consumer, Rewound)

Pagination is working now.

A kind of an issue is the fact that there is no way to control the total number of items at one page, other than influencing the general total number of posts. I believe this should be a layout setting under ā€œGeneralā€. Would that be possible?

And one more thing: I don’t know if you have thought about CSS Grid patterns for the dynamic content. This means having CSS grid repeating itself and accommodating as many posts as needed, but following a visually irregular pattern that is pre set. :slight_smile:

Thanks!

1 Like

I don’t think you can unless you use hook into pre_get_posts or some WooCommerce filter. Then you can do actual filtering of the items before the query is run which will make sure pagination always lines up and the items you want to exclude are taken out. This would be similar to creating a Looper Provider that is filtered.

I’d like if we could add some top level settings on the Layout Builder to help change the query. The problem is order of execution. We detect which Header, Footer, and Layout to use on the WordPress template_redirect action. This is where WordPress determines which theme templates to use. By the time it runs, the WordPress query has already run and all the posts have been queried from the database. This is a problem because our assignment rules allow granularity based on the data available after the posts are fetched. I’m not sure at the moment how we could untangle that without losing accuracy of assignment rules.

One of our bigger goals for the responsive styling update is allowing dynamic content to pass through into the styles somehow. It’s challenging because most often the styles have already been generated by the time loopers are run. So the code will probably look like this:

.el-123.x-cell {
  grid-column-start: var(--column_start);
}
<div class="x-cell el-123" style="--column_start: 1;"></div>
<div class="x-cell el-123" style="--column_start: 4;"></div>

This will allow access to Dynamic Content in the CSS so in theory you’ll be able to position grid cells based on the index of their loop position or in other creative ways. This is all still pretty WIP though so I’m not sure what the final implementation will be.

1 Like