CodeCanyon Wiloke Posts Grid & Slider - WordPress Plugin

A Practical Guide to CodeCanyon Wiloke Posts Grid & Slider for Elementor

CodeCanyon Wiloke Posts Grid & Slider is not for building yet another blog page. It gives you control over where already published posts appear, such as the homepage, a services page, a category landing page, or below a detailed article, where visitors decide whether to keep reading. This guide covers installation, post selection, grid and slider settings, checking the published page, and troubleshooting safely. It does not assume that every version of the plugin has the same set of controls.

The product listing confirms the plugin's basic purpose: display blog posts on any page, select several posts by category or author, and set how many items to show. However, the listing has not been updated in a long time, and no detailed public documentation for every control was available. This guide therefore separates confirmed product features from standard Elementor workflows and checks you should run on a modern site.

Start by preparing a safe copy of the page and the data you will use to filter posts. Then build your first display from real posts, and adjust its appearance only after that. This order may seem slower, but it quickly shows whether an issue comes from the post query, the card layout, or caching. At the end, you will find a workflow for an editorial homepage, a troubleshooting table, and criteria for choosing an alternative.

What the plugin does and where its limits are

On many sites, articles live only in the blog archive. The homepage has a static block with three manually added links, the services page has no useful related content, and topic collections need updating after every new post. In this situation, CodeCanyon Wiloke Posts Grid & Slider connects WordPress content to an Elementor layout: editors create posts in the regular admin area, and the page selects a relevant group and displays it in the chosen format.

The main benefit is not the number of cards. It is the ability to reuse one selection rule in several places without copying titles and images by hand. A new post in the right category should appear in the collection after the page is refreshed and the relevant cache is cleared. If a post is unpublished or its category changes, it should no longer meet the rule. This is especially useful for editorial sites, expert blogs, case study collections, and agency websites where content helps demonstrate expertise.

In practice, this kind of block works like a small editorial agreement. It has a source, the regular WordPress posts; a clear inclusion rule, such as a category or author; and a visible output, a limited set of cards on a specific page. When the rule is written down in one sentence, another editor can follow it without additional explanation. For example, an editor knows that a suitable title alone is not enough for a post to appear on the homepage: it must be published and assigned to the "Practical Guides" category. Developers, in turn, do not have to update the page manually for every new article. That is what sets a dynamic showcase apart from a block of manually placed links and images that gradually goes out of date.

It helps to distinguish the contents of a collection from their order. A category or author answers which posts are eligible for the block, while the available sorting options determine what visitors see first. If the current version has no clear way to pin posts in a specific order, do not promise editors a sophisticated manual sorting workflow. Prepare the posts so that even the default order creates a useful above-the-fold view, and check it on the published page. For a permanent collection of case studies, a separate static section or a tool with confirmed ordering controls may be a better fit than trying to turn a simple post display into an editorial planning system.

The confirmed feature set

The marketplace listing says the plugin can display posts on the homepage or another page, select multiple posts by category or author, set the number of items to show, support different display formats, and adapt to different screen sizes. That is enough for a solid basic use case: show a relevant, regularly updated collection without building a complex recommendation system. Treat any additional controls in the interface as dependent on the specific plugin package and installed Elementor version.

Do not use the plugin as a substitute for a sound publishing structure. If a post has no category, is not published, has no useful title, or lacks a featured image, no attractive grid can fix the source data. Wiloke displays what WordPress returns. First agree with the editorial team on which categories to use for featured collections, how authors are assigned, and which fields every article must include.

Who benefits most from this approach

This plugin is a good fit when you build pages in Elementor and want a lightweight showcase of regular posts without creating a separate archive template. For example, an education site's homepage could show the latest posts in the "Practical Guides" category, a team page could feature posts by a selected author, and a services page could show articles that explain a particular service. Give each block one purpose: "latest posts in this category," "articles by this expert," or "recommended reading." Combining several selection rules in one block makes the output harder to verify.

It is less suitable if your site needs complex access rules, faceted filtering, several post types with different fields, archives based on the current URL, or a separate template for every card. For those requirements, consider Elementor's built-in Loop Grid and archive features, or a plugin with more advanced query controls. Do not expect a simple post display to handle catalog, search, and personalized recommendation features automatically.

A useful rule of thumb: First decide who will see the block, which page they should visit next, and what consistent rule determines which posts appear. Then choose a grid, slider, or masonry layout.

Prepare your site: content, compatibility, and a rollback point

Before installing the plugin, check more than just whether WordPress and Elementor are present. The Wiloke listing mentions compatibility with Elementor and Elementor Pro, but its list of supported WordPress versions stops at older releases. That does not mean it will automatically fail on a newer site. It does mean you should confirm compatibility with your current setup on a staging copy instead of assuming it is guaranteed. Always back up the site and have a rollback plan before updating WordPress core, the page builder, the theme, or add-ons.

Create a test page without touching the existing homepage. You will need at least six published posts: several in the target category, at least one in another category, and one post that should not appear in the output. If you want to test author filtering, prepare posts by two different authors. This lets you check more than a polished demo: you can also catch query problems such as an unexpected post, an empty display, or the wrong number of cards.

The minimum setup for a meaningful test

• A backup of the files and database, or a working staging copy of the site.
• Elementor activated and an account with permission to install plugins and edit the page.
• Several published posts with proper titles, permalinks, and featured images if the theme uses them.
• One clear category for the collection and one control post outside that category.
• A way to clear the page cache, optimization plugin cache, server cache, and content delivery network cache, if enabled.

Write a small expectations table in a team note before testing. Four rows are enough: an expected post in the category, a post by another author in the same category, a post by the target author outside the category, and a control post outside all conditions. For each one, mark whether it should appear in the first test. This matrix is especially useful when you are testing a widget while also updating Elementor, the theme, and caching. Instead of relying on an impression that it "seems to show posts," you get a repeatable outcome: you can open each post in the admin area and explain why it appears in the block or why it does not.

Do not use drafts, private posts, or posts with unfinished permalinks for this test unless you are deliberately checking access behavior. They may appear differently to an administrator and a regular visitor, which can lead you to the wrong conclusion about the widget. For the first pass, use simple public posts with distinct titles and images. Once the display works, test edge cases: unpublishing a post, changing its category, replacing its image, and adding a new post while caching is enabled.

Check whether the target page is a WordPress archive. A regular Elementor page and an archive are different: on a regular page, you create a separate showcase, while on an archive, WordPress already provides the main query, such as posts from a specific category. You can add a separate block to an archive, but first decide what the main archive does and what the additional collection does. Otherwise, visitors may see two similar feeds with different posts.

Questions to answer before activation

Decide whether the block should include only standard posts, whether consistent card heights matter more than a dense feed, and how often the collection should change. If it displays breaking news, aggressive caching may delay new posts from appearing. If the cards use images with different proportions, masonry may look more natural, but the rows will be less consistent. If there is little room for several cards, a slider saves space, but some posts will remain beyond the initial viewport.

Check the theme separately. Global theme styles can override headings, links, spacing, and image proportions inside a third-party widget. Do not try to fix this immediately with site-wide CSS. First open the test page without extra changes and note how the card title, image, metadata, and link look. This gives you a baseline for comparison as you adjust the layout.

Install the plugin and run a low-risk first check

Install the ZIP file using the standard WordPress workflow: in the admin area, open Plugins, then Add New Plugin, choose Upload Plugin, select the original ZIP file, and click Activate after installation. Do not extract the package on your computer unless you know which file WordPress needs. Marketplace downloads often include documentation and other materials alongside the plugin archive.

Do not edit the homepage right after activation. Open Plugins and confirm that the plugin is active, then create a draft page called "Collection Test." Open it with Edit with Elementor. In the element panel, look for Wiloke or terms related to post grids and sliders. If you find the element, drag it into an empty container and save the draft. This helps distinguish an activation problem from a configuration problem.

Check the first display

Do not adjust typography, colors, or animation on the first pass. Keep the setup simple: choose a data source, set one verified selection rule, and use a small number of posts. Then open the published test page in a private browser window. This is not about privacy; it lets you check the page without some local cache and without the administrator's logged-in state. If the editor sees cards but a guest sees an empty block, you are dealing with more than a design issue: check caching, post access, and the security layer.

If the element does not appear in Elementor's panel, refresh the editor and page, confirm that the add-on is still active, and then check for a conflict on a staging copy. Elementor's built-in Safe Mode is designed to isolate editor conflicts without changing the public site for visitors. It is more useful than disabling everything on a live site. Back up the site before troubleshooting, and do not save the page until you understand what has changed.

The first successful outcome is not a beautiful grid. It is a saved test page where a guest sees exactly the posts you expect. After that, you can move the tested configuration into a live container or build another version for a different section of the site.

Choose which posts to display: category, author, and item count

The most product-specific part of CodeCanyon Wiloke Posts Grid & Slider is not card styling, but choosing which posts visitors can see. The product listing specifically mentions adding multiple posts by category or author search terms, and setting the number of posts in a display. In practice, turn this into a short rule another editor can verify, such as "show six published posts from the Practical Guides category" or "show this expert's four latest articles on their profile page."

Start with a category because it is the easiest filter to check. In WordPress, open one post that should appear and one control post, then confirm that the first has the target category and the second does not. Return to Elementor, select the Wiloke element, and look in its panel for content, query, or source settings. The group names may differ in an older version, so follow the meaning of the fields rather than the labels in someone else's screenshot. Choose posts from the category, save the page, and check that the control post is not in the grid.

Why you should not guess the number of cards

The number of items affects more than the block's height. It also sets an expectation for visitors: four items feel like a compact recommendation, six or nine feel like a section in their own right, and a long feed can turn the homepage into a copy of the archive. For your first version, choose a number that forms clear rows in the container. With three columns, six cards make two even rows. If you are testing a slider, keep the collection small enough that the initial viewport does not suggest an endless carousel.

After setting the item count, run a negative check. On the staging copy, change the category of a visible post or temporarily switch it to draft, then refresh the page and see whether it disappears from the block. Restore its original status afterward. This confirms that the widget uses current WordPress data rather than stale markup from a cache. If you see the change only when logged in, clear every relevant cache layer and check again as a guest.

Filter by author without implying personalization

An author collection is useful on pages for experts, editors, and guest authors. But do not call it a personalized recommendation: the widget applies an editorial rule and does not analyze visitor behavior. On an author page, start by showing two or three posts by that person. Then open a card that links to a real post and make sure its date, title, and image all belong to the same article. If editors publish under authors' names, decide in advance which user account the filter should use.

Do not combine category and author filters in your first test unless you have a specific requirement. If the output is empty, you will not know which part of the rule excluded every post. Check each criterion separately first. Combine them only after both return the expected posts, and only if the installed version of the element provides that option. Otherwise, two separate blocks with clear headings are easier to understand than an opaque query.

A useful way to think about this widget's settings is as a chain: "data - rule - limit - format." The data determines whether suitable published posts exist in WordPress. The rule narrows the set by category or author. The limit does not add posts; it cuts the matching set down to a specific number of cards. The format only changes how visitors read that set on the page. Keeping these layers separate makes it easier to explain any outcome. For example, the seventh post in a category has not disappeared from WordPress; it simply falls outside the six-post limit. If an unrelated post appears, that is not a three-column layout problem. Check its category, author, and the selection rule instead.

Restore the test data to its original state after each check. If you temporarily removed a category from a visible post, restore it and confirm that the card reappears. If you changed an author for testing, note the original account before you begin. This matters beyond keeping the test clean. On a live editorial site, temporary changes can remove a post from other showcases, the RSS feed, or the team's publishing workflow. A separate test category and a few prepared posts let you learn how Wiloke behaves without changing the public meaning of already published articles.

Query check: Keep one control post outside the selection rule. It should appear only when you deliberately remove the restriction. This is more reliable than trying to remember which posts belong in the collection.

Grid, masonry, or slider: choose a format that supports browsing

The product's name combines two different display formats. A grid shows the collection at a glance, while a slider moves cards along a horizontal track. The marketplace tags also suggest that masonry may be available, but you will need to check the installed version's panel for that specific option. The format affects how visitors scan the posts, so do not choose it just because one effect looks more modern.

When a standard grid makes sense

A grid works well on a homepage, services page, or knowledge section where visitors need to compare several topics quickly. All the cards appear at once, titles are easy to scan by row, and the collection is simple to check against the editorial rule. On a wide screen, start with three columns if the titles are not too long. With long titles and large images, two columns often make for easier reading. Do not squeeze four or five columns into an ordinary text container: the cards will be too narrow, and clipped titles will hide what the posts are about.

It helps to use featured images with similar proportions across the collection. The plugin may display the posts correctly, but if one image is horizontal, another is portrait, and a third is missing, the overall layout will feel uneven. Do not switch to masonry just because it is fashionable. First decide whether posts have a consistent minimum standard: an image, a concise title, and a clear excerpt.

What masonry changes

Masonry is useful when card heights genuinely vary. Some posts may have longer titles or different image proportions, and you may not want to crop content just to align every row. Masonry makes better use of vertical space, but it is harder to compare neighboring cards at a glance. Use it for a collection visitors can explore, rather than a block where they need to choose one of three equally important paths quickly. If switching to masonry makes titles jump around or images draw more attention than the article topics, go back to a standard grid.

Check the masonry layout after all images have loaded and on a slow connection. If image heights have not loaded when the layout is first calculated, cards may jump around. If that happens, first check image optimization and the theme's lazy-loading behavior. Do not assume the plugin is at fault; theme styles or image processing may be involved.

When a slider helps, and when it hides content

A slider works well for a compact block in the middle of a long page, especially when the collection supports the page's main purpose rather than being its focus. It saves space and lets you show more posts without creating a tall block. However, visitors will not see every card at once, so the initial viewport needs to stand on its own. Do not put the only route to an important document, instructions, or service terms in a slider. Visitors should not have to guess that more content is off to the right.

For your first test, use a small collection and check it on a typical computer, tablet, and phone. On a wide screen, make sure several cards are readable. On a narrow screen, check the image and title sizes and the slider controls. If the installed widget has settings for scrolling, autoplay, or the number of visible items, change one at a time and test each manually. Do not assume autoplay helps visitors. Movement can interrupt reading if it is hard to stop or the content changes before they finish reading a title.

To compare the formats, use the same posts in each one instead of building three different collections. That makes the difference clear: the standard grid shows all six topics at once, masonry gives those same six cards an uneven vertical rhythm, and the slider moves some of them outside the initial view. Look at the page as someone unfamiliar with the site would. Find the post with the longest title, see whether you can reach the last card without scrolling, and check whether it is clear that the block continues. That matters more than how the block looks inside Elementor's editor.

Each format has an editorial cost. A grid requires consistent images and titles because visitors compare cards side by side. Masonry tolerates different card heights, but it may change the order in which visitors notice topics. A slider keeps the block compact, but needs a strong first set of cards and clear navigation controls if the installed version provides them. Do not try to compensate for a weak collection with movement, shadows, or extra effects. If visitors cannot tell why the posts belong together, clarify the selection rule and the section heading first.

Configure the Elementor block: content first, then styling

In Elementor, most elements are organized under the Content, Style, and Advanced tabs. This is a useful way to think about configuring Wiloke Posts Grid & Slider, even if its groups use different names. In Content, choose which posts to display and how many. In Style, make the images, titles, and spacing easy to read. In Advanced, check positioning, custom fields, and responsive settings. Do not move between tabs until you have confirmed that the collection contains the right posts.

A basic configuration sequence

1. Select the Wiloke element in the canvas or structure tree so you do not change the parent container's settings by mistake.
2. In the content area, set a simple source and one verified criterion, such as the category used for your test posts.
3. Set a small number of items, save the page, and check the public page in a private window.
4. If the installed element offers different formats, choose one and check that titles and images still appear correctly.
5. Only then adjust the spacing between cards, the order of content within them, and the typography. Do not change the selection rule at the same time.
6. Switch to Elementor's responsive mode and check wide, medium, and narrow layouts separately.

This is not a ritual; it is a way to isolate problems. If you change the source, column count, font, and spacing at the same time, you will not know why the block became empty or why only one card appears on a phone. Save after each important change and open the public page, because the Elementor canvas may not match what a guest sees after the theme and cache have processed it.

It also helps to keep brief notes about each test, even if they are just a line such as "Practical Guides category, six items, grid, three columns." Before making the next change, open the public page and confirm that it matches the note. Then change one layer at a time: first the number of cards, then the format, then the spacing. If images disappear or the collection changes after saving, you will know which action caused it and can revert just the latest setting. This order is especially useful with an older add-on whose available controls may differ from modern Elementor tutorials.

Check the editor and the published page separately. Elementor's canvas makes it easy to see where you placed a widget and whether you selected the right parent container, but it does not confirm that links work, images load, or guests see the same output. After saving, open the page at its regular address, refresh it while logged out, and follow a few cards. If a card title appears but its link goes to the wrong place or returns an error, check the post data, permalink, and publication status rather than the widget's color settings.

A card should answer one question

A card usually needs only the post's featured image, title, a short description, and a clear link to the article. Do not try to include everything: author, date, categories, comment count, a long excerpt, several labels, and decorative icons. The denser the block, the more important it is to decide which fields help visitors choose an article. For a practical blog, that is usually the title and image. An expert showcase may benefit from the author's name, while a news feed may need the date. Choose fields based on the block's purpose, not just because a control is available.

If titles vary in length, improve them editorially before forcing the font size down. Small text is harder to read on phones and does not fix a poorly worded title. It is usually better to shorten a title that is too long, allow enough space for the title area, or use two columns. If the installed version lets you set an excerpt length, use it only after checking the output: an automatically generated excerpt may cut off a sentence halfway through.

Check responsive layouts with real content

Cards that look good with short test titles often fall apart when you use real posts. In Elementor's responsive mode, check at least one post with a long title and a prominent image. Make sure text is not clipped, labels do not overlap the image, spacing between cards remains clear, and the clickable area is not too cramped. Elementor lets you set separate values at different widths, but not every setting needs to vary. First preserve a readable layout, then make local adjustments.

A good responsive layout does not have to be a smaller copy of the desktop grid. On a phone, preserving the reading order, font size, and room for comfortable tapping is usually more important than keeping the same number of columns. If two cards side by side make titles too small, use one column. If a slider shows part of the next card and it looks like a mistake, check the available settings for the number of visible items, then review the container width and theme spacing.

Practical example: feature a collection on an editorial site's homepage

Imagine a consulting team's website. The homepage already describes its services and has a contact form, but visitors cannot see evidence of the team's experience because useful articles are buried in the main blog. The goal is to show six current posts from the "Practical Guides" category below the services section, so visitors can explore an article without leaving the homepage to search the archive. Here, Wiloke acts as an editorial showcase, not a replacement for the blog.

Set the goal and prepare the content

The goal is to create a separate "Field Notes" block with six published posts from one category. Before building it, confirm that all six posts have a title and featured image, and that the category is assigned in the WordPress admin area. Add a seventh post from another category. It will be your control post: if the widget is configured correctly, it should not appear. If the existing posts are too old or cover unrelated topics, prepare a suitable editorial collection first. Otherwise, the technical test will not tell you whether the showcase is useful.

Back up the homepage or its template, then add a new container immediately after the services section. Give the container a clear name in Elementor's structure tree, such as "Practical Guides - collection." This does not affect visitors, but helps you keep containers straight on a long page. Add a regular heading and a short description inside the container, then place the Wiloke element below them. The heading should explain what the collection includes, not repeat the plugin's name.

Build the block and run the first test

1. Open the homepage with Edit with Elementor and add an empty container below the relevant section.
2. Add the heading "Field Notes" and one sentence explaining that the block features posts from the selected category.
3. Drag Wiloke Posts Grid & Slider below the heading and look for the source or post selection settings.
4. Select the "Practical Guides" category and set the item count to six. If the widget does not show that category, return to WordPress and confirm that it is assigned to the test post.
5. Start with a standard grid. In a wide container, test three columns to create two readable rows.
6. Save the changes, open the page in a private window, and compare all six cards with the source posts.

Do not add posts from every category just to fill the block. If the "Practical Guides" category has only three strong articles so far, show those three and prepare an editorial plan rather than filling the showcase with unrelated posts. In that case, adjust the layout to fit: put the three cards in one row on a wide screen and stack them on a narrow screen. The widget can display prepared content, but it cannot turn a random group of posts into a useful collection.

Check that the collection will update

Publish or update one test post in the target category on a staging copy. First open the post and confirm that its status is Published. Then clear only the cache serving the page and check the homepage as a guest. The new post should appear if the sorting rule places it within the limit and the widget fetches the updated collection. If it does not appear, do not rearrange the cards manually. Check the category, status, selection rule, and cache first.

Now change the test post's category to the control category. After clearing the cache again, it should disappear from the showcase. Restore its original category. These two actions test the key behavior of a dynamic display: the block reflects WordPress data instead of becoming a static decorative section. Once everything works, move the configuration to the live page or create a similar block for another editorial category.

For final acceptance, walk through the process as the next editor would. Open the homepage as a guest, select a card, and confirm that its title, image, and topic match the article page. Return to the homepage, compare the six visible posts with the "Practical Guides" category in WordPress, and confirm that the seventh control post is absent. Then change just one test post by adding it to or removing it from the category, clear the cache for the relevant page, and confirm that the showcase responds as expected. Note which cache layer needed to be cleared. This turns a one-off configuration into a clear procedure for the editorial team.

If you need to move the result from the test page to the homepage, do not copy it blindly along with its surroundings. First create an empty container on the homepage with the same width and section heading, then add the element and repeat only the verified rule: target category, six posts, selected format. After publishing, compare the card widths with the test page. The homepage container may have different inner spacing, a different background, or different theme styles, so even a working configuration may look different. Check the block in its final location, and keep the test page as a safe reference until acceptance is complete.

Do not confuse an automatically updated collection with a guarantee that every new post will appear immediately. If the limit is six, a seventh eligible post may remain outside the display depending on the current sort order. If a post appears only after you clear the cache, the data and rule are working, but the publishing workflow needs to include clearing the cache for that page. If the new post appears but looks weaker than its neighbors, that is an editorial signal: the rule checks category membership, not cover image quality or title clarity. Add a check for the featured image and a clear, concise title to the editorial checklist before publication.

A detail to watch: If a new post appears in the admin area but not for guests, do not change the design. First check its publication status, category, and every cache layer.

Check the published page: what editors and guests should see

The setup is complete only when three views match: the data in WordPress, the Elementor canvas, and the published page as seen by a logged-out visitor. An editor may see a preview that includes available drafts and uses their own cached version, while a guest sees something different. Check the page in both roles: first as the editor, then as a regular visitor in a private window or another browser.

Published block checklist

• The cards match the documented selection rule, and the control post outside that rule is absent.
• Each title links to the expected published post and does not duplicate another card's topic.
• Images do not crop the subject or create random differences in card heights when using a standard grid.
• At narrow widths, titles are readable, elements do not overlap, and the link is easy to identify.
• After changing a test post's category or status, the block updates once the relevant cache is cleared.
• The container does not duplicate the main archive feed on the same page without an editorial reason.

Check the editorial flow as well as the appearance. Open the card links in a new tab and confirm that each post matches the promise made by the block. If a title promises a tutorial but the post is actually a news update, that is not a widget issue, but it still undermines the showcase. Dynamic displays make weak titles, missing images, and inconsistent categories easy to spot.

For responsive checks, first use a real phone width or the browser's device mode, then do a short manual check on an actual device. Do not focus only on the number of columns. Visitors need to recognize where each card begins and ends, read its title without zooming, and open the article without accidentally tapping the next card. When choosing between a denser layout and readability, choose readability.

Check the boundary between a card's content and its link behavior as well. On the published test page, open several cards, including one with a long title and one with a different image proportion. Confirm that each link opens the expected public post, not an edit page, a draft, or a neighboring article. Then return to the page and check whether the block shifted as images loaded. For a slider, test more than the first visible card: if the installed version has a control for moving through the collection, use it and check that titles and links remain clear.

Record acceptance criteria instead of an abstract note that "everything looks good": the page displays the agreed number of posts, every post matches the rule, the control post is absent, links open the right articles, and no title becomes too small or inaccessible on a phone. If a check fails, trace it to the right source. Fix the collection in the WordPress data and selection rule, the card count in the limit, density in the format and container, and update delays by checking the cache. This keeps a design tweak from masking a selection error and makes the block easier for the next editor to manage.

Speed, caching, and accessibility: what the plugin cannot handle on its own

CodeCanyon Wiloke Posts Grid & Slider retrieves and displays posts, but it does not remove the site's other responsibilities. Large images, a heavy theme, script bundling, server caching, and a content delivery network all affect when visitors see the page. Do not promise that switching from a grid to a slider will speed up the page by itself. Start by checking the actual image sizes, then consider optimization.

Use appropriately sized featured images for a collection above the fold. Do not make the browser load very large originals for small cards. If the theme or Elementor generates optimized image sizes automatically, check the final page, not just the media library. The image should remain sharp without being heavier than its display size requires. With a slider, check especially whether it loads too many hidden cards at once on a slow connection.

Caching is useful as long as it does not disrupt the editorial workflow. Set a simple process: publish an article, check its category, clear the cache for the target page, and confirm the update as a guest. Do not clear the entire site at random after every small change if the cache panel lets you purge a specific page. At the same time, do not conclude that the widget is broken after seeing an old version in an authenticated browser. Elementor and third-party optimization plugins may serve different versions to the editor and a guest.

Accessibility starts with the content itself. A post's featured image should have meaningful alternative text in the media library, and its card title should make sense without the image. Do not rely on hover effects alone to reveal the title or link. If your version of the plugin has slider controls, test them with a keyboard and make sure focus does not disappear into a hidden part of the block. If you cannot verify that, use a standard grid for important content.

To check whether updates appear, do not publish a random post on a live site just for testing. On a staging copy, use an existing post in the target category and temporarily change one recognizable detail, such as the beginning of the title or the featured image. Save the change, clear the cache serving the Wiloke page, and compare the card in the editor and in a private window. Then restore the original detail and repeat the check. This lets you verify the whole path from a WordPress post to the page visitors receive, not just whether the data changed.

Do not run this test on the only live page: it should be repeatable and reversible. If testing requires changing categories or publishing posts, do it only on a copy or with prepared control posts, then restore their original status and data afterward. This protects the site's regular showcases from unintended changes.

If the title has changed on the post itself but not on its card, do not jump straight to reinstalling the plugin. First determine whether the entire page is stale for guests or only this block, then check one layer at a time: the builder cache, optimization, the server copy, and the content delivery network. If clearing one specific layer updates the card, document that in the editorial workflow. The next time a post is published, the team will have a repeatable step instead of having to troubleshoot from scratch.

This check is especially important for a plugin whose public listing has not been updated in a long time. It does not prove compatibility with every future version of WordPress or Elementor, but it does confirm a specific workflow on your current test setup. After updating WordPress core, the theme, Elementor, or any plugins, repeat a short test with the control post rather than checking only that the editor opens. Keep the selection rule and card count with the test page so you can reproduce the same case after a future update and distinguish a regression from a cache delay.

Make safe adjustments without editing plugin files

No publicly confirmed list of templates, PHP hooks, or CSS classes was available for this product, so this guide does not include an unverified code example. Do not edit Wiloke's files directly. An update or reinstall will erase those changes, and an error in a template may break the entire page. Start with the element's own settings, the Elementor container styles, and editorial changes to the source posts.

A safe order for visual refinements

Give the element or its parent container a meaningful name in Elementor's structure tree. Then adjust the parent container's spacing instead of changing the margins of individual cards at random. To distinguish the showcase from the archive feed, give it its own background, section heading, and comfortable spacing from neighboring blocks. These changes stay in the Elementor page and are easy to undo through the editor history or a template backup.

If a problem really requires CSS, first find a stable class in the browser on a test site. Add the rule only in the theme's custom CSS area or in a child theme. Keep it narrowly scoped: attach it to an additional class on the outer container instead of a general site-wide image or link selector. After the change, check both wide and narrow layouts. To undo it, remove only the rule you added. Do not copy classes from other plugins or assume Wiloke's internal markup will stay the same across releases.

If cards look inconsistent because of their content, the best "fix" is often editorial rather than technical. Consistent image proportions, shorter titles, complete excerpts, and consistent categories produce more reliable results than complicated fixed heights. Make changes in small steps: change one setting, save, check the public page, and then move on to the next.

Troubleshoot an empty grid, unexpected posts, and broken layouts

It is easier to troubleshoot a dynamic showcase by looking at where the problem appears. An empty block means you should check the source, selection rule, or whether the element is active. Unexpected posts point to the WordPress data or selection rule. Differences between the editor and public page usually call for a check of caching, optimization, or access permissions. Do not start by reinstalling the plugin: that takes time and rarely explains the cause.

The element appears in Elementor, but the page has no cards

Symptom: You can see the container or its settings in the canvas, but the public page shows an empty space. Likely cause: The rule finds no published posts, the wrong source is selected, or the test page has an unsaved configuration. What to check: Open an expected post and check its status and category, then temporarily simplify the selection to one criterion. Confirm that the page saves without errors.

Fix: Restore the widget's simplest working source, choose a category with known published posts, and set a small item count. Once that works, add any other conditions one at a time. If the block is still empty on a clean test page, check that the plugin is active and the element is in a published container. To roll back, return to the saved simple configuration instead of deleting working posts.

The collection includes the wrong posts

Symptom: A card appears, but it belongs to a different topic, author, or category. Likely cause: An unrelated post has the editorial category, the post has multiple categories, or the widget's rule does not match the intended criteria. What to check: Compare every visible card with the post's fields, especially its status, author, and categories. Use a control post prepared outside the selection rule.

Fix: Correct the WordPress data or simplify the selection rule first. Do not hide an unwanted card with styles; the issue will recur with the next post. If the installed version cannot combine the required category and author filters, split the content into two clear blocks or consider a tool with more advanced query controls. To roll back, restore the original single-condition rule that passed the control test.

The editor sees a new post, but guests see the old collection

Symptom: After publishing a post or changing its category, Elementor looks correct, but a private window shows the previous cards. Likely cause: The page, server, or content delivery network is serving a cached version. What to check: Open the page in a private window, confirm the post is published, and clear the cache serving that specific page one layer at a time. Also check whether the optimization plugin creates a separate mobile version.

Fix: Add cache clearing after significant posts to the editorial workflow, and note which layer needs to be purged. Do not disable caching permanently on a live site just for testing. If the output still differs after clearing the cache, check security and optimization plugins on a staging copy. To undo a disputed change, restore the previous cache rule after identifying the specific conflict.

Cards break on phones or after optimization

Symptom: Text overlaps an image on a narrow screen, the slider shows one clipped card, or spacing breaks. Likely cause: An inherited Elementor setting, a container that is too narrow, theme styles, or aggressive CSS and JavaScript bundling. What to check: Switch to responsive mode and check the container, the element, and the length of real post titles one at a time. Then compare the page before and after clearing the cache.

Fix: Simplify the layout first: use one column on phones, clear spacing, and fewer fields on each card. If the problem appears only after optimization, disable the relevant bundling or deferred processing on a staging copy, one setting at a time, and note which setting caused it. For a theme or plugin conflict, use Elementor Safe Mode or WordPress troubleshooting mode, which runs the check for the current user without changing the public site. To roll back, restore the last saved working version of the element and re-enable improvements one at a time.

Safe troubleshooting: Test conflicts on a staging copy or in an isolated mode. Back up the site before disabling multiple add-ons, and do not save the page while elements it depends on are temporarily disabled.

When this plugin is a good fit

CodeCanyon Wiloke Posts Grid & Slider is a good choice when you need a straightforward Elementor block to display published posts on a regular page, and your editorial rules can be expressed through categories, authors, and a sensible item count. Its strength is making content visible in the right place without rebuilding each block by hand after every new post. A strong outcome depends on well-prepared posts, one clear selection rule, a readable layout, and a guest check after clearing the cache.

If the test page shows the right posts, stays readable at different screen sizes, and updates when the source data changes, you can download CodeCanyon Wiloke Posts Grid & Slider and move the tested setup to your live sections. If your needs include complex sources, archive behavior, or guaranteed compatibility with current releases without testing, first consider Elementor's built-in features and more actively maintained alternatives.