Loop Grid + Loop Item: The Two-File Import Nobody Explains

Loop grids generated more debugging hours for me than any other template type in this library, so let me save you the pain: a loop grid is two files. The loop item is the card design that repeats. The loop grid is the section that queries your content and stamps the item across it. Import them in that order and connect them, and everything works. Skip a step and you get the famous empty grid.

Why two files at all

Elementor stores the card design as its own template with type loop-item, because the same card can serve many grids. The grid widget then references that template by id. This is elegant and completely undocumented in the places beginners look, which is why our loop grids download as a bundle: grid, matching item, and an instructions file listing the preset query.

The grid does not contain the card. It points at the card. Every empty-grid mystery I have debugged traces back to that pointer.

Import order that works

• Import the loop item first, from Templates, Saved Templates. Its type field files it as a loop item automatically.
• Publish the item. A draft loop item will not render inside a grid; I verified this one the hard way.
• Import the grid section onto your page.
• Select the grid widget, open its Layout settings, and pick your imported item under the template selector.

That last step matters because template ids are site specific. My grid pointed at item 4218 on my build machine; on your site that id belongs to something else or nothing. During our own testing I found that some import paths silently drop the reference entirely, so I treat reconnecting the item as a required step, never an optional one.

The query settings that actually matter

The grid's query decides what content fills it. Three settings do most of the work: the source post type, the number of items, and the ordering. Our bundles preset these and the instructions file spells them out, but you will want to point the post type at your own content. A grid queried at posts renders nothing on a site whose content lives in products, and it fails silently rather than loudly.

Products deserve their own paragraph. A product loop grid needs WooCommerce active, and the item widgets that pull price and title need real products to read. Empty store, empty grid, no error message. Test with a handful of published products before concluding anything is broken. Our loop grid library pairs product grids with product-shaped items so the two halves match from the start, and the loop items are browsable on their own if you want to mix.

My debugging order for empty grids

First: is the loop item published, not draft? Second: is the grid's template selector actually pointing at it? Third: does the query's post type match content that exists and is published? In hundreds of test imports, those three checks caught every silent failure I hit. The loop grid import guide has the full sequence with screenshots.

Designing loop items that survive real content

The card you design gets stamped across whatever your query returns, and real content is messier than demo content. Titles wrap to three lines. Featured images arrive in five aspect ratios. Excerpts run long or do not exist. When I reviewed my early item designs against a fixture site with deliberately awkward posts, the failures were predictable: fixed heights clipping long titles and image boxes distorting portraits into squares.

Three habits fixed nearly all of it. Give the image a fixed aspect ratio with cover cropping, so every card holds the same silhouette regardless of the source photo. Let text areas grow, and align card bottoms with the meta row pinned low, so ragged content still reads as a tidy grid. And test your item against your worst post, not your best one; the promotional screenshot takes care of itself, the awkward archive page is what your visitors actually see.

Dynamic tags do the talking

Inside a loop item, widgets read the current post through dynamic tags: post title, featured image, excerpt, date, terms. The binding is what makes one design serve a thousand posts. It also means a loop item previewed outside a grid can look strangely empty, because there is no post context feeding the tags. Do not judge an item on its lonely preview; drop it into the grid and let the query give it something to say. When I generate items for the library, every text and image widget carries its dynamic binding explicitly, because a tag left unbound renders a static placeholder that will never change with your content, and that defect hides until the moment a real query runs.

FAQ

Can one loop item serve several grids?

Yes, that is the point of the split. Design the card once and reference it from a blog grid, a related-posts grid, and an archive grid simultaneously.

Do loop grids need Elementor Pro?

Yes. The Loop Builder is a Pro feature, both the grid widget and the loop item template type.

Why does my grid show the same card design but wrong content?

The item's dynamic tags read whatever post the query hands them. Wrong content means the query targets the wrong post type or ordering; the card is doing its job.

Grid renders in the editor but not on the live page. What now?

Usually caching. Clear your page cache and Elementor's CSS cache under Tools, Regenerate CSS, then reload. If it persists, re-check that the item is published.

How do pagination and load more behave with imported grids?

The grid widget's pagination settings import along with everything else, and they work against your query, not the demo's. Numbered pagination reloads with page parameters and plays nicely with caching. Load more fetches the next batch in place, which feels smoother but interacts with some cache and optimization plugins badly; if the button spins forever on your live site while working locally, an optimization plugin deferring the wrong script is my first suspect, and excluding Elementor's front-end scripts from deferral is the usual fix. Infinite scroll I use sparingly, because it fights footers and makes reaching anything below the grid a chase. One sizing note worth knowing: the per-page count in the query multiplies against your item complexity, so a heavy card design times twenty-four items is a heavy first paint regardless of pagination mode. When one of my grids feels slow, I cut the initial page size before I touch anything else, and it is usually the entire cure. Set the count to what a visitor genuinely scans, somewhere between six and twelve for most layouts, and let pagination carry the rest.