CodeCanyon Advance Post Grid - WordPress Plugin

How to Set Up Filterable Grids in CodeCanyon Advance Post Grid

This guide to CodeCanyon Advance Post Grid will help you prepare posts and taxonomies, build a filterable grid or list in Visual Composer, verify the query on the public-facing site, and safely identify the cause of empty or incorrectly sorted output. We will follow a practical path from structuring WordPress content to publishing a finished page with cards, filters, and predictable navigation, without confusing those tasks with arbitrary design settings.

This add-on has one important characteristic: it does not create a separate card database. Instead, it provides a visual way to select existing posts, pages, custom post types, and their related categories, tags, or custom taxonomies. That is why a good outcome starts not with choosing a hover effect, but with answering three questions: which content type should appear in the block, what attribute should visitors use to narrow it down, and what information should remain visible on each card after someone scans the page quickly.

In this guide, we will refer to the product as Advance Post Grid for brevity, but the product in question is Advance Post Grid/List with custom filtering for Visual Composer by proword. It is designed for sites where Visual Composer is already part of the editorial workflow. The original product description lists grid and list views, multiple layout types, a query builder, filtering by categories, tags, and custom taxonomies, grid/list switching, and several pagination options. That is a broad feature set, so the administrator's job is not to enable everything at once, but to align the content, query, and visible output.

When a Filterable Grid Is Actually the Right Solution

Advance Post Grid is useful not because it turns every page into a mosaic. Its strength appears when a site already has repeatable content and visitors need to choose a subset without opening a dozen separate archives. A typical example is a studio portfolio: each project is stored as a custom post, while project categories are assigned through a taxonomy. Another example is a magazine or knowledge base where visitors want to see only articles on a particular subject. A third is a resource catalog that does not need a full online store, but does need a clear list of publications with an image, a short summary, and a link to the full page.

It is important to separate responsibilities on pages like these. WordPress stores content, post statuses, images, and terms. Visual Composer provides a place on the page and a settings panel for the element. Advance Post Grid renders the selected content group and adds visitor controls. The site's theme defines the container, base typography, and possible width constraints. A caching layer, if present, can save the generated page, but it should not determine which content enters the query. When these responsibilities are mixed together, familiar symptoms appear: the filter is visible but changes nothing; the grid looks good in the editor but is cropped by the theme; or a newly published post does not appear on the live site.

Good use cases

The best pages are those where the same card pattern repeats many times and visitors are choosing among materials rather than arriving for one known item. This can include a case-study catalog, a services list with individual pages, a document library, a news collection by topic, an event calendar, a team section, or a publication showcase. In every case, decide in advance what the source is: standard post entries, page entries, products, or a custom post type registered by the theme or another extension.

A filter only makes sense when it uses a stable attribute. If ten case studies describe their category differently, the buttons will create the appearance of navigation rather than provide useful navigation. For a portfolio, it is better to use one dedicated taxonomy such as project_type instead of mixing blog categories, tags, and freely typed words. For editorial content, categories are usually enough. Tags are worth adding only when they are genuinely maintained through editorial policy and do not grow into dozens of nearly identical variations.

Who the add-on may not suit

Do not choose this product just for one static collection of three cards: a simple Visual Composer block or the theme's built-in output will be enough. The add-on is also not a replacement for full-featured search with multiple conditions, price ranges, stock availability, and complex relationships between fields. Its stated model is based on post queries and taxonomy filters, not a faceted-search builder. If the site is already built entirely with the block editor or another page builder, first assess whether the Visual Composer dependency is justified. The historical product listing names Visual Composer as a system requirement and does not position the solution as optimized for Gutenberg.

Also consider the site's lifecycle. An older project that already uses Visual Composer can gain a straightforward way to standardize archive pages without rewriting a template. For a new project that will be handed over to editors with no experience using that builder, compare it first with modern tools that offer blocks or native support for the chosen editor. This does not make Advance Post Grid a poor choice; its value is simply tied to a specific existing environment.

What Creates Predictable Content Output

Before opening the element settings, it helps to map out the chain mentally: post type - published content - taxonomy terms - query settings - card template - method for loading the next batch. If the first part of that chain is missing, no grid setting can fix the content. A card cannot display an image that the post does not have; a filter cannot find a term that has not been assigned to the content; and date sorting cannot create a meaningful order when migrated content has inconsistent dates.

Test with at least four or five items. For each one, prepare a title, permalink, featured image, short excerpt, and one or two terms from the relevant taxonomy. Then publish the items instead of leaving them as drafts or scheduled posts. If another extension creates the custom post type, make sure it is publicly available and supports the required taxonomy. Advance Post Grid can query custom post types, but the add-on is not necessarily responsible for creating them for you.

Why taxonomy should be designed first

A taxonomy is not a decorative label below a card. It is the vocabulary that the filter will rely on later. A good vocabulary is concise, non-overlapping, and clear to visitors. For example, a portfolio might use terms such as "Online Stores," "Corporate Websites," and "Services." Avoid assigning the same project "Store," "E-commerce," "Online Sales," and "Retail" if those are simply different words for the same idea. That kind of set bloats the filter bar and forces visitors to guess at the distinction.

Create the required terms in the relevant WordPress section first, assign them to the content, and only then add the element to the page. This order gives you a simple test: open the administrative list of posts and filter it by each term. If the output is unclear there, fix the data rather than the grid styles. You cannot expect a visual filter to repair a fragmented content structure.

Practical guideline: before configuring effects and card borders, create a query of five published items from one taxonomy on a test page. This quickly separates a data problem from an output problem.

Preparing WordPress and Activating the Add-On Without Extra Variables

Before installation, create a site backup and, if possible, work on a copy of the site or a test page. This is not just a formality: the add-on affects content output, so a small mistake in the data source can hide useful posts on the public page. A backup is particularly important on an older site where Visual Composer, the theme, and other extensions already form a tightly connected setup. The goal is not to predict every possible conflict, but to preserve an easy way back if enabling the add-on changes the page display.

Next, verify that the Visual Composer used on the site is available in the editor for the relevant page type and that your account can edit that page. Product sources identify Visual Composer as a required component. Do not confuse it with the generic term "visual editor": the element appears specifically in this builder's add-on library. If the site uses a different editor, do not look for the element in that editor's panel or attempt to paste code from unrelated instructions. First confirm where and by whom the target page is assembled.

Quick checklist before uploading the archive

• Create a backup of files and the database, or save a hosting restore point.
• Prepare a test page where you can publish the future grid without changing the main navigation.
• Prepare content: at least several published posts with images, titles, and assigned terms.
• Confirm the source: standard posts, pages, a custom post type, or, in an appropriate older project, products.
• Temporarily disable aggressive page caching for testing, or make sure you know how to clear it after saving.

The final point does not mean that caching must remain disabled permanently. It is only needed for a transparent test: after changing the query or ordering, you want to see the new output rather than previously saved HTML. If the site uses several caching layers, clear only the layer that actually serves the public page. There is no need to make broad optimization changes for a single grid.

Installation and finding the element in the builder

After receiving the installation ZIP archive, use the standard WordPress path Plugins - Add New - Upload Plugin. Select the archive, install it, and click Activate. An alternative method through a file manager is appropriate only when it is part of your established technical procedure; for ordinary add-on use, it offers no advantage and often makes troubleshooting harder if the folder is extracted to the wrong location.

After activation, open the test page specifically in Visual Composer and open the element-add dialog. Do not rush to fill out dozens of fields. First find the elements related to grid or list output, add one to an empty container, and save the draft. If the element does not appear, record the facts: is the plugin itself active, does Visual Composer work for this page type, and is there an error message in the admin area? Do not try to solve a missing element by changing the theme or restructuring categories; those are different layers of the problem.

Save the page and open it in a separate tab. On the first pass, a simple or even unattractive output is acceptable: the important thing is confirming that at least a few expected items enter the block. If the output is empty, do not start adjusting columns. Return to the source settings and verify publication status, the selected post type, and the category or taxonomy conditions. If unrelated content appears in the block, the query is still too broad and should be narrowed before working on cards.

Using an initial query as a control sample

For the first test, use a simple rule: one post type, a limited number of items, and date sorting. The product description lists source selection, item count, sorting order, categories, tags, taxonomies, individual posts, pages or custom post types, and author settings in its query builder. This is a powerful set of options, but it is safer to add conditions one at a time. The initial query should answer one question: "Can I see the exact posts I prepared?"

Do not set the item count to All immediately on a large archive. For testing, choose a small number so that the content is easier to compare. Then change the sorting and confirm that the first card changes as expected. Only after that should you add a category or custom-taxonomy term. This lets you identify the cause if the output disappears: not "the plugin does not work," but specifically that a taxonomy condition does not match the data.

Selecting individual items

A mode that uses specific posts is useful for a "Featured" showcase where the selection is deliberate and rarely changes. It does not replace a structured archive query. If you need a newly published project to appear automatically in a portfolio, filter by type and taxonomy rather than manually adding each ID. Manual selection provides control, but increases the chance of forgetting a new post.

Author and ordering as editorial conditions

Author filtering makes sense for an expert page or editorial column. For a general article section, however, it can easily create an unnoticed gap: readers expect a topic, but receive only some of the content from one author. Sorting should also match the task. News usually makes sense in reverse chronological order. Case studies can be manually ordered by the editorial team if the data source supports that, or can reflect project launch dates. Random order works for a small entertainment collection, but makes the content harder to verify repeatedly and maintain over time.

Moving From a Working Query to a Meaningful Layout

Once the control sample displays correctly, you can work on presentation. Visitors read an image, title, topic marker, and reason to open a post within seconds. The more fields you keep, the more important the grid, container width, and source-excerpt quality become. A dense magazine page benefits from short titles and compact excerpts. A case-study catalog usually needs only an image, a title, and one project-category label. Do not try to turn every card into a reduced version of the full post.

The product provides both grid and list modes. A grid quickly shows the variety of available content, but does not handle long titles and inconsistent images well. A list is better for text, dates, and excerpts, but requires careful image height and predictable width. Do not choose a view based on an attractive demo thumbnail. Open your own test set with the longest titles, the brightest image, and the weakest excerpt. If the layout remains readable with those items, it will hold up in normal editorial work.

First-launch checkpoint: by this stage, you should have a saved element with a limited, verifiable query. Every later change can be compared against this control sample, and its settings can be restored quickly if needed.

Configuring the Grid: Layout Type, Columns, and Card Content

Once the query returns the right content, choosing a grid type becomes an editorial decision rather than a cosmetic one. The original Advance Post Grid description lists a standard grid with fixed rows, an extended MixItUp-based grid, and a masonry layout. Do not select among them based on their names. Fixed rows create a calm rhythm and work well when image proportions are similar. Masonry uses vertical space more efficiently when covers and excerpts vary substantially. The extended grid is useful where the filtering and rearrangement behavior matters more than strictly uniform rows.

Start with the simplest view, where errors are easiest to spot: a regular grid. Only once cards show correct data should you try masonry or a more advanced option. Otherwise, you will be diagnosing why a post did not enter the query, why a card changed height, and why a filter rearranges items all at once. Separating these questions saves more time than searching for "perfect" settings on the first day.

Column count is not a measure of how much information to show

The product description states that desktop, tablet, and mobile column counts can be configured separately. This is one of the most useful settings because it controls readability rather than decorative density. Start by identifying the actual width of the theme container. Three columns in a wide template may look spacious, while the same three cards in a narrow content area become cramped columns. On a test page, begin with a moderate count and test it using the longest titles.

For a magazine feed, three columns on a wide screen, two on a tablet, and one on a phone often work well. A compact image catalog can use greater density if card text is reduced. For a list, first decide whether readers need a side image, then choose its size. The product mentions medium and large image options in list mode. Medium size leaves room for an excerpt; large size makes the image the main identifying feature, but quickly lengthens the page.

Do not test the mobile version merely by narrowing the editor window. Open the published page on a real phone or at least use browser emulation. Press every filter button, scroll to the bottom row, open a card, and go back. Pay particular attention to a filter that leaves one card. It should not lose its width, extend beyond the container, or leave an adjacent empty area that looks like a failure.

Two approaches to card styling

The marketplace description presents two grid appearance options. The first offers a visual element composition with draggable parts, border settings, and a choice between a button or text link for the "read more" link. The second uses a set of predefined styles and effects for grid elements. Treat them as separate ways to control the display, not as required layers that must be enabled together.

The first approach is useful when the site already has an established card pattern: image at the top, a small taxonomy line, title, short excerpt, and a restrained link. It helps to define the order of those parts on paper or in a draft first, then recreate it in the visual settings. A simple order is easier for editors to maintain. If a card includes four separate meta fields, several icons, two links, and a long excerpt, visitors lose sight of the main action and row heights begin to vary dramatically.

The second approach works when the goal is to produce a neat output quickly on a test or secondary page. A preset effect should not be treated as a quality guarantee. Test it with keyboard navigation, on a touch screen, and without relying on hover behavior. Everything essential, including the title and link, must remain accessible without a hover effect. An overlay and icon can improve orientation, but should not be the only way for visitors to understand where a card leads.

Border, background, and visible hierarchy

Per-side border settings can help cards fit a theme more precisely. However, separate colors and sizes for every side are rarely necessary. If the theme already has a system-wide card style, use that first and add a border only when items blend into the background. Do not try to reproduce every line from the add-on demo: in another theme, it may clash with spacing, buttons, and shadows. The goal is to give visitors clear content groups, not to display the maximum number of available fields.

A reliable review order is this: first background and text contrast, then spacing between cards, then image consistency, then borders, and effects last. If you change everything at once, it becomes difficult to tell which setting caused extra height or horizontal scrolling. After every significant step, save the element and view the outcome in a separate tab.

What to display below the image

The product offers switches for excerpts, metadata, categories, tags, comment count, and author information in different modes. Being able to show a field does not mean it needs to be shown. For an article catalog, a category, title, short excerpt, and date may be enough when freshness matters. For a portfolio, project type is usually more valuable than a date. In a collection of content by one author, repeating the author's name on every card is unnecessary. For each line, ask one question first: does it help visitors choose an item, or does it only increase the card height?

An excerpt is useful when an editor has written it as a standalone explanation. An automatically clipped first paragraph often begins with an introductory phrase and does not explain the value of the content. Prepare short, meaningful excerpts for test items rather than using a random string of opening words. Then choose a length where two lines remain readable and a third does not make adjacent cards appear to jump visually. If a level grid matters more than a detailed preview, hide the excerpt and give readers a clear title instead.

The "read more" link

A button is more noticeable and suits a showcase with one obvious action. A text link is more subtle and fits an editorial list better. Choose one principle for the entire block. Do not make the image, title, overlay, icon, and large button all clickable if they lead to the same page. It is not technically wrong, but visitors receive too many competing signals. Keep natural click targets and confirm that they do not overlap at narrow widths.

Responsive Design and Images: Check Before Publishing

Grid quality depends on the source thumbnails as much as on the number of columns. Establish one consistent cover approach: for example, horizontal illustrations with the same aspect ratio for articles, or vertical covers for case studies. Mixed proportions are acceptable in masonry layouts, but even there, an image that is too small becomes noticeable when stretched. Do not solve the problem by uploading unrestricted heavy originals: first generate suitable thumbnail sizes through WordPress and confirm that the theme does not crop them unexpectedly.

After saving, review four conditions: a wide screen, a medium width, a phone, and the state after applying a filter. In each case, look beyond the column count and follow the visitor journey: is the title visible, does the button fit within a touch target, does an overlay cover text, and do images load without abrupt height shifts? Good responsiveness means that the action remains equally clear, not that the desktop grid has merely been scaled down.

Verification checkpoint: if you can identify the data source, visible category marker, and one clear action for every card, the layout is ready for the next step: configuring filters and output order.

Category and Taxonomy Filters: Making Choices Clear

A filter in Advance Post Grid is only useful when it reflects an already understandable content structure. The original product listing states that custom taxonomies can be selected for filters, while the query builder can limit the source by categories, tags, and taxonomies. These are related but different settings. One determines which posts enter the block at all. The other determines which attribute visitors can use to switch among the prepared output. If these levels are not distinguished, you can easily end up with a category menu whose options contain no cards, or a long row of meaningless buttons.

First decide what question visitors are asking the page. In a portfolio, it might be "Which projects were built for online stores?" In a magazine, it might be "Which materials concern analytics?" On a resource page, it might be "Which documents are intended for beginners?" The answer should be one clear question. Do not place project category, year, region, author, and content format in the same panel unless visitors truly need a full multi-parameter search. For most pages, one taxonomy and a short list of terms are enough.

A setup order that avoids hidden exceptions

1. Limit the base query by post type and, when needed, by a broad section so that unrelated content does not enter the block.
2. Assign each test item a term from the taxonomy that visitors will see in the filter.
3. Enable filter controls in the element settings only after the base output is already correct.
4. Select one taxonomy and test every term individually on the published page.
5. Test the "All" state, returning to it, and sets with one or zero matching cards.

This sequence is intentionally stricter than simply "adding buttons." It prevents a data error from being hidden behind animation. For example, if a term is not assigned to a post, the filter should not be expected to guess the correct card. If an item has several terms, it can appear under each of them, and that is normal behavior. But if one term represents a project category and another is an internal editorial tag, visitors should not see both together in the same panel.

Categories, tags, and custom taxonomies

WordPress categories work well when a page displays standard posts and the editorial structure is already consistently organized around categories. Tags are useful for fine-grained, overlapping attributes, but more often create an overly long vocabulary and require strict discipline. A custom taxonomy is the better option for portfolios, real-estate listings, case studies, events, professionals, and other content types where the filtering attribute differs from a blog category. It makes button meanings obvious and keeps the editorial post list clean.

Do not create a new set of terms simply because a taxonomy field is available in the settings. First make sure that the vocabulary exists, is attached to the correct post type, and is actually being used. If another plugin or theme code creates the taxonomy, Advance Post Grid reads its data but does not become the owner of that structure. Keep this in mind when updating the theme, changing the custom-post-type setup, or moving the site to another environment: a disappearing filter often means that the source of the terms disappeared, not that the visual block itself broke.

How to choose button labels

Filter buttons should be shorter than article titles. Users should not need to read instructions to understand the difference between "Research," "Interfaces," and "Development." If a term is too long, shorten the displayed label after confirming that it still matches the content rather than hoping the grid will fit it into a narrow column. Maintain a consistent grammatical form and style: either all terms describe an output type, or all describe an industry. Mixing "Finance," "Websites," and "Completed in 2025" in one row signals different classification systems.

The word "All" also needs testing. Visitors normally expect it to restore the base collection for this block, not every post on the site. That is why the initial query must be limited before filters are enabled. If the target page is about case studies, the "All" button should return case studies rather than news, pages, and test posts. This is one of the best indicators that the query settings and filter bar work as one system.

Output order and sorting as part of navigation

The add-on lists sorting controls and allows output order to be selected through the query builder. Sorting is useful when visitors understand what is changing. For news, that is usually the date. For portfolios, a carefully curated order may be more useful if your data structure supports it, or project recency may be appropriate. For a page with a few featured items, an additional sorting panel is often unnecessary: it creates another choice without improving the task.

If you enable order controls, test them together with the filter. Select a term, change the order, return to the general view, then repeat in the reverse order. The content set should not unexpectedly expand or shrink. Also review labels and localization: older Visual Composer-based solutions may display system phrases in English. Do not replace plugin files for the sake of one word. First check whether a standard language file or safe WordPress translation mechanism is available. If it is not, keep page-interface wording neutral rather than creating a fragile modification to the add-on core.

Load More, Pages, and Grid/List Switching

When the number of items grows, the main question changes: how many cards should appear at once, and how should visitors reach the rest? The product lists modes with no pagination, a Show More button, infinite scrolling, and page numbers. It also describes switching between grid and list views without reloading the page. Choose the method not for a modern-looking effect, but based on how visitors return to content they have already reviewed.

No navigation works for a small, carefully curated collection. A load-more button gives visitors control: they decide when to load the next batch. Infinite scrolling suits a lightweight feed, but can make it harder to return to a previous position and verify the lower part of a page. Page numbers are useful for an archive where users want to understand its size and return to a particular section. No single mode is best for every site.

Combining filtering and incremental loading

This is where the most careful testing is needed. First enable filtering with a small number of cards above the fold. Then select a term, click the next-batch button or go to the next page, return to the general view, and repeat. Check whether cards are duplicated, whether the active filter state disappears, and whether an older set returns after loading. If behavior becomes unpredictable, temporarily keep only one mechanism: for example, a filter plus a load-more button without the grid/list switch. A simpler page that is easy to verify is more useful than a rich set of controls with an unclear state.

The grid/list switch is particularly justified in a material library where some visitors scan images quickly while others want to read excerpts. In a highly visual portfolio, it may be unnecessary: the list removes the very value the page was created to provide. If you enable the switch, maintain the same card meaning in both views. The title should lead to the same destination, and the filter and selected order should retain their meaning. Changing the presentation must not change the data set.

Do not overload the control panel

A panel with filters, sorting, a grid/list selector, and pagination can take more space than the first cards. For a portfolio page, a filter and one output format are often enough. For a material library, you can retain a filter plus controlled loading. Make the decision after reviewing the page on a phone: if the top of the page is filled with buttons, visitors have not yet understood what content is available but are already being asked to choose how it should be displayed.

Checkpoint: a visitor filter is not considered configured when buttons first appear, but after every term, the return to the general collection, and the interaction with the chosen loading method have all been tested.

Practical Example: A Case-Study Catalog Filtered by Project Category

Let us walk through a complete example that uses Advance Post Grid's strengths without inventing additional features. Assume that a web studio has a custom post type called "Case Studies." It already has a taxonomy called "Project Category," with terms such as "Online Stores," "Corporate Websites," and "Services." The owner needs a compact grid on the work page so that visitors can start with the full collection and narrow it to the required project type with one click. Each card should lead to a detailed case study, while each newly published project should automatically appear in the appropriate group.

This is a strong use case because the source, filtering attribute, and card purpose are distinct but aligned. The source is only the custom post type. The filter attribute is one project-category taxonomy. The card is a short entry point to detailed work. If you use standard blog posts, internal tags, and a random page instead, visitors will not understand what they are filtering, and editors will have to maintain the collection manually.

Preparing data for the example

First create or verify five to seven case studies. Each should have published status, a clear title, a permalink, a cover of comparable quality, and one project-category term. Two case studies can belong to online stores, two to corporate websites, and one to services. A single item may belong to two categories only when that genuinely helps visitors. Do not add a second term simply for demonstration purposes, because it becomes harder to notice when the classification is no longer precise.

Write excerpts as independent short explanations. For example, instead of "In this case study, we explain," use "A product catalog with item selection and editorial landing pages." That excerpt retains its meaning even outside the full article. Prepare images with similar aspect ratios. If one case study uses a vertical photo and another a wide illustration, first decide whether that contrast is part of the intended design. For an even grid, it is better to prepare separate covers than force the add-on to compensate for inconsistent source material.

Building the block on a test page

1. Open the "Our Work" page in Visual Composer and add an Advance Post Grid element in a separate container.
2. In the query builder, select the "Case Studies" custom post type, set a small number of items for the initial view, and choose a clear order.
3. Do not add conditions for individual terms yet if the page should show all case studies on its first load.
4. Select the standard grid and a moderate number of columns for the active theme width.
5. Keep on the card an image, the project-category term, title, short excerpt, and one natural path to the full case study.
6. Enable filtering by the "Project Category" taxonomy, save the page, and confirm that only meaningful terms appear in the panel.

After the first save, do not tune effects. Open the page as a visitor and compare the collection with the administrative case-study list. The general state should show all published projects. Selecting "Online Stores" should leave only the two matching items. Selecting "Services" should leave one. If the count does not match, record the discrepancy simply: "The term has three posts in the admin area, but the page shows two." This wording leads to data verification faster than the vague statement "the filter behaves strangely."

Styling cards for the page goal

For case studies, images and titles matter more than publication dates. Therefore, it is best to hide the date and comment count in the first version. The project-category term can appear as small but noticeable text, but it should not repeat the large filter button on every row so frequently that the page becomes noisy. Keep the excerpt to one or two short lines. If titles are long, shorten them editorially rather than trying to compensate with smaller type.

The "read more" link can appear as a text link such as "View Case Study" or as a small button. Choose one format and verify that the image, title, and link lead to the expected permalink. In a particularly image-driven portfolio, a clickable image and title may be enough, but do not hide the availability of navigation solely in a hover effect. Phone users should not have to guess the gesture.

Loading the next batch

If the number of case studies grows, start with a load-more button rather than infinite scrolling. It shows that the block continues without removing visitors' control over the page. Choose a batch size that completes a row on a wide screen and remains reasonable on a phone. After enabling it, test a filter term, the load-more button, and the return to "All" again. Only after this test should you decide whether numbered navigation is needed. For a small studio, a button is usually easier to maintain and easier to understand in a showcase.

How to Verify the Output After Each Change

Verification should not consist of one glance at the top of the page. A filterable grid has at least four layers: the data set, card appearance, control behavior, and behavior after content changes. Review each of them. This process is especially useful when handing a page over to an editor: they receive not only a completed block, but also a clear understanding of what to check after publishing new content.

Follow this path after changing the query, filters, output mode, or column settings. You do not need to repeat every step manually after changing a border color, but you should never skip it after changing the content rules. Test more than the ideal collection. Open a card without a long excerpt, a term with one post, and a state with no matching results. A clean empty state is more honest than old cards remaining on the screen because of a configuration error.

Testing after publishing a new case study

To make sure the page is truly dynamic, create one test case study after completing the configuration. Assign the appropriate type, image, and term, publish it, then clear only the necessary page cache and open the catalog in a private browser window. The new card should appear in the general collection and in the matching filter. Then delete the test post or turn it into real content. This test validates the whole chain, not just the collection saved at configuration time.

If the new item does not appear, first check its status, post type, and term. Then compare the ordering: perhaps the new item is not at the top, but in the next batch because of the selected sorting and limit. Only then inspect caching. This order matters because clearing a cache will not fix content that does not meet the query conditions.

Performance and restrained interface design

Advance Post Grid builds output from WordPress data, while cards often contain images and effects. Performance therefore depends on query size, the number of simultaneously visible items, cover-image weight, theme scripts, and caching behavior. Do not assume that one effect or one setting will make the page fast. A practical approach is to avoid loading every item at once, prepare appropriate thumbnails, and reduce the number of secondary decorative elements on each card.

If filtering appears to happen without a full page reload, do not rush to disable site optimization. First compare the output in regular and private windows, both after clearing the cache and without clearing it. If script combining or deferred loading causes a problem, temporarily exclude one specific file or function from optimization only after a technical specialist has identified the dependency. Disabling minification globally for one portfolio page is an overly broad and often temporary measure.

Example outcome: the editor gets one clear workflow - create a case study, assign a project category, publish it, and check it in the general view and the correct filter. The visitor gets a short path to the desired content without requiring the page to be manually edited after every new publication.

Troubleshooting: Why Cards, Filters, or Switches Do Not Behave as Expected

Problems in a filterable grid are easier to investigate by visible symptom rather than by the plugin name. This prevents the unhelpful sequence of "update everything, clear everything, reinstall everything." Advance Post Grid has several levels where an issue can occur: element availability in Visual Composer, the WordPress query contents, post data, theme markup and styles, as well as caching and scripts on the public page. First record what visitors actually see, then inspect the closest relevant layer instead of changing every setting at once.

The element does not appear in Visual Composer

Symptom: the plugin is active in WordPress, but no Advance Post Grid grid or list appears in the add-element dialog. Possible cause: Visual Composer is not active, is not enabled for the page type being edited, or the add-on cannot load its elements because of an incompatibility in the current environment. The product listing identifies Visual Composer as a system requirement, so having another builder installed does not by itself confirm that the setup is ready to use.

What to check: open Plugins and make sure both components are active. Then create a clean test page of the same type as the target page and open it in Visual Composer. Compare whether the element is available on the test page and the working page. If it is visible on the test page but absent from an older page, the cause may be the page template or editor restrictions. If the element is absent everywhere, do not mask the issue by inserting an unrelated shortcode.

How to fix it: restore a compatible configuration from a backup point, confirm that Visual Composer truly works on this site, and compare the issue with the project's known environment. The historical add-on listing mentions older WordPress and Visual Composer versions, so testing it on a site copy is especially important on a modern site. When to roll back: if activating the add-on creates admin errors or prevents the editor from opening, disable it on a test copy and do not continue styling until compatibility has been investigated.

The grid appears but remains empty

Symptom: the container and controls are visible, but there are no cards. Likely cause: the query cannot find posts of the selected type, category, tag, or taxonomy conditions are too restrictive, items are not published, or the selected source is incompatible. An empty grid does not prove that the styling is broken: first establish that the data set exists.

What to check: temporarily remove all restrictions, leave one explicit post type and a small item count. In the admin list, make sure test content has published status. If you are using a custom post type, open that specific list rather than the standard Posts list. Then add conditions one by one: first a category, then a taxonomy, then an author or individual items. After every save, view the public page in a separate tab.

How to fix it: return to the last working query and compare every condition with the actual post data. The issue is usually resolved by publishing the item, assigning the correct term, or selecting the correct post type. When to roll back: if the empty block appeared immediately after adding one condition, remove that condition only and do not change columns, effects, and navigation at the same time.

A filter button exists but shows zero or incorrect cards

Symptom: the filter row is visible, but selecting a term leaves an empty block, does not change the output, or shows materials from another group. Likely cause: the visible filter is tied to the wrong taxonomy, terms are not assigned to posts, the base query includes another content type, or the filter and query use different rules. This is the most common case where the interface seems configured but the data does not support its behavior.

What to check: choose one term and list every post assigned to it in the admin area. Then compare that list with the cards on the page. Make sure the filter settings select that exact taxonomy rather than a similar category or internal tag. Click "All," one term, another term, and then "All" again. At a narrow width, repeat the same actions with a finger or touch emulation because a visually active state can sometimes differ from the actual output.

How to fix it: assign terms to the appropriate content, standardize taxonomy labels and structure, and limit the base query to the correct post type. If the page is intended for case studies, do not use blog categories and project-category taxonomy together. When to roll back: if enabling a second filter set makes behavior unclear, keep one useful filter and restore the previous saved element configuration.

A new post is published but does not appear on the page

Symptom: an editor can see a new post in WordPress, but it does not appear in the general collection or its filter. Likely cause: the selected order placed it below the first batch, the post does not meet every query condition, it has no image or term, or the visitor is viewing a cached version of the page. Do not begin by clearing every cache: first determine whether the post should appear in the current view.

What to check: open the post and confirm Published status, post type, and assigned taxonomy. Compare its date and the selected order. Temporarily raise the item count or use navigation to reach the next batch. Then open the page in a private window. Only when the conditions are met and the item still does not appear should you clear the specific cache layer serving this page and test again.

How to fix it: complete the post data, adjust the ordering or limit, then refresh the cache through the site's normal procedure. When to roll back: if new items begin duplicating after infinite scrolling or load more is enabled, temporarily return to numbered output or a smaller initial batch until the cause is diagnosed precisely.

Cards are misaligned, text is clipped, or horizontal scrolling appears

Symptom: the block looks acceptable on a desktop screen, but on a tablet or phone, cards extend beyond the container, images lose their proportions, or a long title breaks the row. Likely cause: the column count does not suit the theme's content width, source images vary too much, too much metadata is enabled, or theme styles affect nested elements.

What to check: keep one layout type and reduce the card to an image, title, and link. Review the page at several widths. If the problem disappears, restore the excerpt, term, and other fields one at a time. Compare the problematic card with a normal one: does it contain an unusually long word, a very large image, or HTML inserted by an editor? Confirm that the theme container does not constrain width on that page template.

How to fix it: reduce column density at medium and narrow widths, prepare more consistent thumbnails, shorten excerpts, and keep only useful metadata. Do not edit add-on files for an isolated display issue. If a small CSS adjustment is needed, first find a stable selector on a site copy, place the rule in a child theme or the standard Additional CSS area, test it after updates, and make sure it can be removed with one edit during rollback. When to roll back: if a local adjustment affects other theme grids, disable it and address the issue through element settings or the page container.

Effects stop working after filtering or loading more items

Symptom: the first batch of cards looks normal, but after changing a filter, an effect disappears, height is recalculated incorrectly, or the next-batch button does nothing. Likely cause: a conflict with optimization scripts, an outdated Visual Composer and add-on combination, an error in another plugin that changes page markup, or several control modes combined without being tested on this site.

What to check: reproduce the issue on a test page with the same element but without extra blocks. Temporarily disable additional grid effects, then test the filter, load-more feature, and grid/list switch separately. Check whether the issue remains without aggressive script combining or deferred loading. Do not disable every plugin on a live site or change WordPress core files.

How to fix it: keep the working combination of controls, clear the necessary cache, and restore optimization one setting at a time. If the issue appears only with a particular pair of modes, that is valuable diagnostic information for a specialist or support team, not a reason to hide the problem behind vague wording. When to roll back: after a repeatable failure caused by enabling an effect, return to a standard grid without that effect and keep a verifiable page saved.

Troubleshooting rule: first compare WordPress data with the expected content set, then review Advance Post Grid settings, then the theme, and only after that inspect caching or optimization. This order preserves useful clues about the issue.

When CodeCanyon Advance Post Grid Is a Good Choice

This add-on is justified on a WordPress site that already uses Visual Composer and needs controlled output of posts, pages, or custom post types as a grid or list. The best outcome comes not from enabling the greatest number of settings, but from three aligned decisions: a correct data source, a concise filter vocabulary, and a card that helps visitors choose content within seconds. In that configuration, a new publication enters the section through the normal editorial workflow rather than through manual page rewriting.

Before launching on a live site, keep a control sample: a test page, several verified posts, and a documented review sequence. Then add real content, confirm that it appears in the general collection and under the correct term, check a narrow screen, and only after that restore caching and additional effects. This approach is especially important for an older builder-and-theme setup, where a subtle change in one component can sometimes affect another.

If your use case matches these conditions, you can download the latest version of CodeCanyon Advance Post Grid, install it on a site copy first, and recreate the described case-study catalog or a small resource section. Do not try to migrate a large archive immediately: one transparent test block provides more confidence than dozens of cards configured without verification.

The main sign of a successful setup is simple: visitors see a clear collection of content, quickly narrow it by a meaningful attribute, and open the page they need, while editors know what data to add to a new post so that it appears in the catalog. When that chain works, the grid becomes part of the site's navigation rather than a decorative showcase.