AGS Frontend Reports - WordPress Plugin

How to Set Up AGS Frontend Reports to Display WooCommerce Reports on Your Site

AGS Frontend Reports is the name under which the plugin Frontend Reports for WooCommerce may appear on a product page. In this guide, we will focus not on a marketing overview, but on the practical side: how to prepare WooCommerce, where the report data comes from, how to build the shortcode, where to safely display a table or file link, how to verify the result, and what to do if the data does not appear.

The core idea behind the plugin is simple: a report that would normally need to be opened in the admin dashboard or exported manually can instead be shown on the front end of the site on a selected page, post, or widget area. But that simplicity makes one important detail easy to miss: store reports contain business data, so before publishing anything, you need to think through the report source, access permissions, and page visibility.

This guide is intended for WooCommerce store owners, site administrators, marketers, operations managers, and developers helping a team set up secure access to data. We will rely on official BerryPress/WP Zone materials plus WooCommerce and WordPress documentation, and we will treat any uncertain points carefully.

What the Plugin Does in the WooCommerce Reporting Workflow

AGS Frontend Reports does not replace WooCommerce reporting, and it is not a full analytics builder on its own. According to the official description, it is an add-on that takes a report from a compatible reporting plugin and displays it on the front end of the site through a shortcode or widget. It is best understood as a bridge between a ready-made report and a page available to selected users.

This architecture matters when planning your setup. If the site does not yet have a report source, AGS Frontend Reports alone will not create the metrics you need. You first need a plugin that can generate the report itself: for example, Product Sales Report Pro, Export Order Items Pro, Ninjalytics, or another compatible product listed by the developer. Then you create or select a report preset, and AGS Frontend Reports displays that preset on a page.

In day-to-day use, the workflow usually looks like this:

1. The report source collects WooCommerce data: sales, products, order items, statuses, order fields, or other supported metrics.
2. The preset saves the report configuration so the user does not have to select fields, filters, and format from scratch every time.
3. The AGS Frontend Reports generator creates a shortcode using the selected mode, source, preset, date range, and display parameters.
4. A WordPress page or widget shows either an interactive table or a file download link.
5. Access control determines who can view the page and open the report.

This approach is especially useful when you need to give an employee, contractor, partner, or client access to a specific report without exposing the full WooCommerce admin area. WooCommerce's built-in roles give a Shop Manager broad capabilities, including access to reports, orders, and products. AGS Frontend Reports lets you create a narrower working scenario: the person sees a page with a report, but does not get extra menu items or admin actions.

Key check before setup: if the selected report source is not installed, not activated, or does not have the required preset, the shortcode page will not become a usable reporting dashboard. Prepare the data source first, then publish it on the front end.

Who Frontend Report Display Is For

This plugin fits best on sites where reports are needed by more than just the administrator. For example, a store owner may want to give a regional manager access to sales for a specific category, an agency access to a summary for a campaign landing page, a supplier access to a product export, or a client in a private portal access to a periodic report for a shared project. In all of these cases, the goal is not to teach someone how to use the WordPress admin dashboard, but to give them a clear place to view data.

AGS Frontend Reports is especially useful if you already have reports configured in a compatible plugin. In that case, you are not rebuilding analytics from scratch, but using an existing configuration as the source. The front-end page becomes a presentation layer for the result: the table may be sortable, searchable, and paginated, or in a different mode the user may get a file download link in whatever format the report source provides.

Scenarios Where the Plugin Really Saves Time

The first strong use case is an internal report for the store team. The manager does not need to go into orders, products, and analytics sections. They open a private page, review the current report, and download the file if needed. This reduces the risk of accidental admin actions and removes unnecessary navigation.

The second use case is a partner or supplier-facing report page. If the compatible reporting plugin lets you build a preset for the needed products, categories, or order items, AGS Frontend Reports helps you expose exactly that result. The key point is not to promise something the report source cannot do: limits by products, roles, custom fields, and formats are defined not by the display add-on, but by the reporting plugin that generates the data.

The third use case is routine operational review. For example, a warehouse employee sees an export of order items, while a marketer sees a product sales table. If what you need is not an interactive table but a file for further processing, the download-link mode is the better choice.

When Another Tool Is the Better Choice

The plugin may be unnecessary if reports are only needed by administrators inside the admin dashboard, if you want full charting and deep analytics in a separate interface, or if the site has no compatible reporting source. For advanced analytics with charts, segments, forecasts, and a dedicated workspace, it makes more sense to look at specialized solutions. For automated scheduled report delivery, a tool built specifically to email presets is the more logical option.

Another case that requires caution is reports containing customer personal data. A table with names, email addresses, physical addresses, phone numbers, order totals, or internal fields must not be accessible to a casual visitor. If such data is displayed on a page, that page must be protected by an access-control mechanism before it is published.

What to Check Before Installation: Data Source, Access, and Test Environment

Before installation, it is worth doing a short preparation pass. It takes less time than diagnosing an empty table later or discovering that a report was accidentally exposed. AGS Frontend Reports depends on WooCommerce and a compatible reporting plugin, and the display location also depends on your page editor, theme, and access-control method.

The Report Source and Preset

Start by confirming which report you want to show. The plugin's official materials emphasize that it works with compatible reporting products and can use presets if the selected source supports them. That means before creating the shortcode, you need to prepare the report itself: fields, filters, time period, file format, and preset name.

For Product Sales Report Pro, that might be a sales preset by categories or products. For Export Order Items Pro, it could be an order-item export with the required fields. For Ninjalytics, it would be a report that supports the selected display method. If the report source does not have the needed limits by products or fields, do not try to solve that on the shortcode page. Build the correct preset in the source first.

Page Access

The plugin itself displays the report wherever you place the shortcode or widget. The official description explicitly warns that any user who has access to the page or post will be able to see the report. That means access control has to be designed separately. This may be a private page for logged-in users, a role-based rule, a membership restriction, an internal team page, or another method already used on the site.

Do not confuse this approach with giving someone the Shop Manager role. In WooCommerce, a shop manager gets access to broad administrative capabilities. If a person only needs a report, it is safer to show them one protected page than to grant wide admin permissions.

A Test Page and Test Data

Create a separate hidden page for testing. It gives you a safe place to test the shortcode, visibility for different roles, the table layout, and how the download link behaves. Do not start with a live public page. If the report contains real customer data, use a staging copy of the site, a test store, or a limited preset that excludes unnecessary personal data.

Before publishing, check four things:

• WooCommerce is active and there are orders that fall within the selected report period.
• A compatible reporting plugin is active, and the required preset exists and generates data in the admin dashboard.
• The page is protected from unintended visitors before you insert a live shortcode containing business data.
• Your theme gives the table enough width, especially if the report contains many columns.

A Quick Responsibility Map Before Launch

A reporting page may seem like a small technical detail, but in practice it quickly becomes part of an operational workflow. So before installation, it helps to answer one simple question: who owns each layer? The WordPress administrator owns installation and the page. The person who understands the store data owns the preset. The team lead or store owner owns the decision about who is allowed to see the result. The developer or technical specialist owns caching, theme behavior, and safe presentation.

If those roles are not separated, typical problems follow: the administrator publishes a report with extra columns, the marketer changes the preset without notice, the manager thinks they are seeing today's data while the cache serves an older version of the page. AGS Frontend Reports cannot solve organizational issues on its own because it only displays a finished result. So agree on the page's purpose first, then configure the plugin.

What Data Is Safer to Show

For the first launch, choose a report that contains only operational metrics: product name, SKU, category, quantity, amount, status, or aggregated totals. It is better not to include customer personal data until you have verified access control, caching, and file-handling rules. If a user genuinely needs an email address or shipping address, define why that field is necessary for their work and add it only to a separate preset for a narrow role.

What Data Is Better Left in the Admin Dashboard

Internal order notes, payment details, addresses, phone numbers, custom meta fields, and questionable internal markers should not be displayed on a general report page without a specific reason. If accounting or warehouse staff need that data, it is often safer to use download mode on a protected page, or to keep the export inside the report source where access is controlled by an administrative role.

Installation and the First Check in the WordPress Admin Dashboard

Installation works like any standard WordPress plugin: in the admin dashboard, open Plugins > Add New, choose to upload the ZIP archive, install the file, and click Activate Plugin. After activation, a Frontend Reports item should appear in the WooCommerce menu. This guide does not cover purchasing, license keys, or license retrieval, because its purpose is to explain setup and usage of a product you already have.

After activation, do not rush to publish a report right away. Open WooCommerce > Frontend Reports and confirm that the generator can see at least one report source. If the source list is empty, the problem is usually not the WordPress page, but a missing compatible reporting plugin or missing preset.

Initial Check After Activation

1. Open the report source in its own section and generate the report in the admin dashboard.
2. Save the preset if the source supports presets and you want to use a repeatable configuration.
3. Return to WooCommerce > Frontend Reports.
4. Select a display mode and confirm that the correct source is available in the Report Source field.
5. Generate a test shortcode and insert it on a protected draft page.
6. Open the page in a separate window as a user with the intended access level.

At this stage, it is important not to combine two different checks. The first check answers the question, "Does the report generate at all?" The second answers, "Does AGS Frontend Reports display that report on the selected page?" If you only test the public page right away, it is hard to tell where the actual failure is.

How to Tell the Installation Went Correctly

The minimum sign of a successful installation is a Frontend Reports menu item inside WooCommerce and a working shortcode generator. But that alone is not enough for production use. A good result looks like this: the report source is selected, the preset is available, the shortcode is created, the test page is published with access restrictions, and a user with the right role can see either the table or the file link.

If the menu appears after activation but the sources do not, check report-plugin compatibility and confirm that the preset exists. If the menu does not appear at all, check the current user's role, whether WooCommerce is active, and your list of installed plugins. If shortcodes stopped working after updating from an older version, review the developer's current changelog: the product history already includes fixes related to shortcode generation and updater initialization.

How Not to Confuse an Installation Issue with a Reporting Issue

Installation should be treated as its own phase. It only answers whether the menu item appears and whether the generator opens. If the generator works but the front-end page is empty, that is not necessarily an installation problem. This separation saves time: there is no need to reinstall the plugin every time the wrong preset or time period was selected.

A sensible post-install diagnostic sequence looks like this. First confirm that WooCommerce is active and that the site has orders of the needed type. Then open the report source and generate the report without involving AGS Frontend Reports. After that, create a new shortcode in the generator. Only then should you check the page, editor, theme, and cache. If you work in the reverse order, it is easy to start with CSS or cache when in fact the source is simply not returning data.

What to Record in a Working Note

For each report, it is useful to save a short technical note: source, preset name, display mode, time period, page, access rule, responsible role, and the date of the last manual verification. That date does not need to appear in the user-facing article, but inside the team it helps restore the setup logic quickly after an update or staff change.

The Shortcode Generator: Report Table or File Link

The shortcode generator is the main workspace in AGS Frontend Reports. It assembles parameters into a ready-made string that you can insert into a post, page, or any other block that supports shortcodes. In the classic workflow, you select a mode, report source, preset, time period, and display parameters. The generator then outputs a shortcode, and WordPress processes it on the page.

The plugin has two fundamentally different modes. In Display mode, the user sees the report table directly on the page. In Download Link mode, they get a file download link, and the file format depends on the selected preset in the reporting plugin. These modes solve different problems, so you should choose between them based not on habit, but on how your team actually uses the data.

When to Choose Display Mode

Display mode works best when someone needs to quickly review rows, sort the table, find a product, verify an amount, or view a report on an internal page. The official product page notes that displayed reports can be paginated, sortable, and searchable. That is convenient for day-to-day monitoring, especially if the report is not too wide and fits into the main page content area.

For display mode, pay attention to the parameters related to interactivity. If the standard interactive table is enabled, the user gets search, sorting, and pagination. If Plain mode is selected, the table becomes simpler, without interactive elements, which can be useful for embedding in a narrow area or for a quieter visual presentation. But that also removes part of the usability.

When to Choose Download Link

Download Link mode is a better fit for reports that need further processing: opening in spreadsheets, forwarding to a team member, attaching to an internal report, or handing off to accounting. Here it is important to configure the format ahead of time in the report source. If the selected preset generates CSV, XLSX, HTML, or another supported format, the front-end link should deliver exactly that output.

A download link is convenient, but it requires stricter access checks. A user can save the file locally and forward it elsewhere. So for reports containing business or personal data, it is better to restrict the page, remove unnecessary fields from the preset, and use link text that clearly explains what will be downloaded.

How to Configure Parameters Without Unnecessary Confusion

Key generator parameters and what they mean in practice

Parameter	What to Choose	How to Verify
Mode	Display for viewing on the page, Download Link for a file.	Open the page and confirm that you see either a table or a link, not an empty block.
Report Source	A compatible reporting plugin that is already installed and can generate the report.	Generate the report directly in the source first.
Report Preset	A saved report configuration, if the source supports it.	Check that the table displays the exact fields and filters you need.
Report Date Range	The number of days to include, or the period defined by the source if you want to preserve the preset logic.	Compare several rows against WooCommerce orders from the same period.
Include today	Enable it if the user needs the current day included, not only completed past days.	Create a test order and verify that it appears in the report after refresh.
Plain mode	Use it for a simpler output without search, sorting, or pagination.	Check that the table has not become too long or broken the page layout.

After changing parameters, always copy the newly generated shortcode. If you manually edit a shortcode that is already inserted, only change obvious values such as the number of rows per page. Do not guess at attribute names, because a single typo can result in an empty output.

How to Design the Page So the User Is Not Intimidated by the Table

Even a good report table can feel overwhelming if there is no context before it. The user opens the page and sees dozens of rows: products, SKUs, amounts, statuses, dates, order fields. Without guidance, they do not know whether they are supposed to look for an order issue, download a file, sort by amount, or simply verify totals. That is why it helps to place a short working instruction next to the shortcode.

For Display mode, the instruction can explain three actions: use search to find a SKU or product name, sort by quantity to identify best sellers, and download a separate file only if the report source provides one. For Download Link mode, it is enough to state what file will be downloaded, for what period it is generated, and who to contact if the file is empty.

Do not overload the page with a large tutorial. The details can stay in this guide or internal documentation, while the working page itself should only contain concise orientation. A good balance is one paragraph above the report and one paragraph below it with a clear action path, for example: "If you see a discrepancy, first check the time period and order status, then send the order number to the responsible administrator."

Presets and Date Range: How to Make the Report Repeatable

The most reliable way to use the plugin is to display not a one-off report, but a preset prepared in advance. A preset matters because it ensures the same report is generated each time using the same logic: the same fields, the same order, the same filters, and the same format. This is especially important for teams comparing metrics week over week or sending files into another system.

In Product Sales Report Pro, presets help you quickly repeat sales reports. In Export Order Items Pro, presets let you lock in a specific set of fields and filters for order items. In Ninjalytics, the approach to presets and templates is tied to a more modern reporting system. AGS Frontend Reports is not supposed to replace that setup layer: it simply displays the prepared result on a page.

How to Choose the Report Period

Date range is a common source of confusion. If you want to show "the last 7 days," you need to decide whether the current day is included. The official generator documentation states that without Include today, the default range ends at the close of the previous day. That works well for completed periods where the data does not change during the day. If a manager needs live oversight of current orders, Include today may be appropriate.

For financial reports and order-fulfillment reports, a completed period is often better. For monitoring current sales, a period that includes today makes more sense. The main thing is to explain this to the page users. If one employee thinks they are seeing today's data while another assumes the report only covers a period completed yesterday, they will reach different conclusions.

Which Fields to Keep in the Report

A useful report does not need to be the widest possible one. If the page is intended for a marketer, they often only need the product, quantity, revenue, category, and period. If the report is for warehouse operations, SKU, variations, quantity, and order status may matter more. If the report goes beyond the internal team, remove any fields that are not necessary for decision-making: email address, phone number, physical address, internal notes, and technical meta fields.

The fewer unnecessary columns you have, the cleaner the layout, the faster the review, and the lower the risk of exposing data. This is not just about convenience, but also about security. AGS Frontend Reports makes report display easier, but responsibility for the field set still belongs to the administrator configuring the source.

How to Document the Agreement Within the Team

For repeatable reports, it is useful to document the purpose of each preset directly in the site's admin documentation or in an internal team note. Specify who uses the report, what period it covers, which fields are included, where the page is located, and who is responsible for access review. It is a simple habit that prevents the situation where, a few months later, no one remembers why that particular data set is being shown on the page.

A Source-Selection Matrix for Typical Tasks

If the site has several compatible reporting products installed, do not choose a source based on whichever one appears first in the list. Start by defining what question the page user needs answered. Operations teams care about one set of fields, marketers another, suppliers a third. AGS Frontend Reports will display the result, but the quality of that result depends entirely on the source and preset.

How to match the page's purpose with the report source

Page Task	What Matters in the Preset	What to Verify Before Displaying
Product sales monitoring	Product, SKU, category, quantity, amount, and sort order.	Confirm that the needed order statuses are included and there are no unnecessary personal fields.
Order-item export for operations	Order items, variations, quantity, internal fields, and file format.	Check for duplicate rows and verify that returns and shipping are handled correctly.
Recurring summary for a manager	A short period, easy-to-read totals, and minimal technical columns.	Confirm that the methodology matches how the team makes decisions.
Partner report	Filtering by products, categories, or other attributes, with no unnecessary customer data.	Make sure the page is restricted to the intended partner or group only.

This matrix does not replace the source documentation, but it helps keep different goals separate. One report does not need to serve everyone. It is much cleaner to create several narrow presets and display each on its own protected page than to force everything into one universal twenty-column table.

Displaying the Report on a Page, Post, or Widget Without Overexposing Access

Once the shortcode is generated, the next step is choosing where to display it. The product documentation mentions pages, posts, and any content area that supports shortcodes. It also supports the WooCommerce Report widget, which can be added to a widget area. In practice, the right location depends on who will read the report and how often they need it.

A Page with a Shortcode

A page is the most controlled option. You can restrict it by role or membership, keep it out of the menu, give it a clear URL, and place guidance next to it explaining what the report shows, how often to review it, what the time period means, and who to contact if the data does not match expectations. In the WordPress block editor, the shortcode is easy to insert using the Shortcode block. In the classic editor, simply place the shortcode in the content area.

If the page is intended only for the team, do not place it in the public navigation. Add the link to protected navigation, an account area, an internal section, or send the URL only to users who already have access. The fact that "the page is not in the menu" is not security. Security means an access rule that does not serve the content to unauthorized visitors.

A Post or Documentation Section

A post makes sense if the report is part of an internal instruction, a recurring reporting post, or a knowledge-base section. For example, you might create a post called "Weekly Product Report" in a protected category and place the shortcode after the explanation. But a post is harder to control if the site uses RSS, archives, search, or automatically generated related-content blocks. So for sensitive reports, a dedicated page is usually safer.

The WooCommerce Report Widget

The widget is useful when the report needs to appear in a sidebar or in an area your theme displays across multiple pages. The documentation describes adding it through Appearance > Widgets and configuring widget parameters such as title, source, preset, date range, whether to include today, and display settings. On modern sites, some themes use the block-based widget editor, while classic widgets may appear through a compatibility block.

The main widget risk is width. A table report with multiple columns rarely looks good in a narrow sidebar. If the theme compresses the table, the user may end up seeing row-expansion buttons, horizontal scrolling, or clipped values. For that reason, the widget is better suited to a short report or a compact download link, while a detailed table is better placed on a separate page.

Access Restriction at the WordPress Level

The display plugin should not be your only barrier. For a protected page, use a proven content-restriction mechanism: a role rule, membership rule, user group, or login-status rule. You can use a content-restriction plugin, a membership plugin feature set, or a custom role structure if it is already maintained by the site's developer. What matters is that the rule protects the page itself, not just the menu link pointing to it.

Practical test: open the page in a private browser window while logged out. Then log in as a user who should have access, and as a user who should not. Only after that should you share the link with the team.

Practical Scenario: A Private Report for Merchandising Managers

Let us look at a working scenario that clearly shows the role of AGS Frontend Reports. Suppose the store sells several product groups, and the merchandising manager needs a daily sales report for a selected category. They do not need to edit orders, change products, or go into WooCommerce settings. They need to open one page, review the table, and download a file if needed.

Goal

Create a protected page called "Merchandising Report" where an authorized manager can view a sales table generated from a prepared preset for a selected period. The page must not be visible to site visitors, customers, or other roles that do not need access to business data.

Preparation

Before starting, WooCommerce, AGS Frontend Reports, and a compatible report source must already be installed. In the report source, you need to build the preset: select the products or categories, keep the necessary fields, set the column order, and confirm that the report generates in the admin dashboard. If the report uses custom fields, make sure the source can read them and that the values actually exist in the orders.

Setup Steps

1. Open the reporting plugin and create a preset, for example "Sales by display category." The name can be anything, but it should be clear to the administrator.
2. Generate the report in the source's admin screen and verify that the rows, totals, and period match expectations.
3. Open WooCommerce > Frontend Reports.
4. In the Mode field, choose Display if the manager should work with the table on the page.
5. In the Report Source field, choose the reporting plugin where the preset was created.
6. In the Report Preset field, select the needed preset. If the field is empty, return to the report source and confirm that the preset was saved.
7. Set the Report Date Range. For daily monitoring, a short range works well; for completed weekly reports, use a longer range without including the current day.
8. Keep interactivity enabled if the manager needs search, sorting, and pagination. For a compact report, you can test Plain mode.
9. Copy the shortcode and insert it on a new WordPress page using the Shortcode block.
10. Protect the page using an access rule for the selected role or user group.

Verifying the Result

After publishing, log in as a user who is allowed access. The page should display a table with clear columns. Test search by product name, sorting by quantity or amount, and pagination if the number of rows exceeds the page limit. Then open the page while logged out or under a different role: the report must be hidden.

If download mode is selected, verify not just the presence of the link, but the file itself. Download it, open it in a spreadsheet editor, and compare several rows against WooCommerce orders. For a report containing personal data, confirm that the file does not include unnecessary columns. If it does, fix the preset in the source, not just the page text.

A Nuance That Often Gets in the Way

If the report appears empty, the cause may be the time period, order statuses, product filter, an outdated preset, or the page access rule. Do not change everything at once. First check the report in the source, then the time period in AGS Frontend Reports, then the page, and only after that the theme or cache. In that order, diagnosis usually takes only a few minutes.

A Variation of the Same Scenario: A Supplier Report

A similar approach can be used for a supplier or external partner, but the requirements are stricter. The goal is to show sales only for the partner's products without exposing customer data, total store revenue, other categories, or internal notes. That is only possible if the report source can build that limited preset. AGS Frontend Reports should not become the last-resort filter.

In practice, the workflow looks like this: create a preset in the source with a filter by products or category, remove personal data fields, then generate a shortcode in AGS Frontend Reports for either a table or a file link. The page is protected with a separate access rule. After publishing, the administrator logs in as a test partner user and confirms that they only see the permitted rows.

If the report source cannot restrict the data precisely enough, it is better not to publish the partner page. Use a manual export, a separate reporting workflow, or another tool where the filtering is confirmed. External report access requires stricter review than internal manager access.

How to Verify the Accuracy and Security of a Published Report

Verification matters not only after the first setup. It should also be repeated after plugin updates, a theme change, a preset change, adding a new field to the report, or changing cache settings. AGS Frontend Reports sits at the intersection of several parts of the site, so an issue may come not from the plugin itself, but from the data source, access rules, theme, or page caching.

Data Reconciliation

Select 3 to 5 orders that should appear in the report and compare the rows manually. Check the product, quantity, amount, order status, and time period. If the report source uses its own logic for including or excluding statuses, compare not just against the orders screen, but also against the source settings. WooCommerce Analytics, for example, has its own settings for statuses, ranges, and analytics caching, so different tools may produce different numbers based on different methodology.

If the discrepancy is small, do not jump to conclusions. Check whether the report includes refunds, discounts, taxes, and shipping. Check whether the current day is included. Check whether the order was created, paid, and completed at different times. Different reporting systems may count periods by different dates, so for management reporting it is important to agree in advance on which date is considered primary.

Access Verification

The report page should be tested in three states:

• Guest cannot see the report and gets a clear message, login form, or redirect.
• Regular customer cannot see the report if they are not in the allowed group.
• Authorized user can see the table or link and perform the intended action.

If any one of those states behaves incorrectly, do not publish the link in the menu or share it with the team. Fix the access rule, clear the cache, and run the check again.

Cache Verification

A report containing business data must not turn into a static fragment that gets cached and served to all visitors. If the site uses a caching plugin, server-side cache, CDN, or page optimization, exclude the protected report page from full-page caching. This is especially important for pages that display different data to different users or should only be available after login.

After excluding the page from cache, open it under different roles and confirm that the content does not "stick." If a guest can see data after an administrator has viewed the page, that is a critical cache-configuration failure. In that case, disable caching for the page and re-check the access rules before republishing.

Checking Search Visibility of an Internal Page

For protected report pages, SEO is usually not the goal. On the contrary, the goal is to keep internal content out of search results, internal recommendation blocks, sitemaps, and public archives. If the page is properly restricted, a search crawler should not receive the report contents. But technically, it is still useful to do a few more things: remove the page from guest-facing menus, do not include it in public lists, set it to noindex through your SEO plugin, and avoid exposing report fragments in open content blocks.

Do not confuse noindex with security. A noindex directive does not protect data if the direct URL serves the table to a guest. Access control comes first, indexing rules second. That order matters especially in WooCommerce, where a report may contain commercially sensitive amounts, products, and indirect signals about customer behavior.

Display Settings, Table Width, and a Clean Layout

A report on the front end should not only be accessible, but also readable. WooCommerce tables often contain many columns, and a site's theme is not always designed for wide data inside normal content areas. So after placing the shortcode, you need to check width, rows, search, expand buttons, headings, and mobile appearance.

Interactive Table or Plain Table

An interactive table is convenient for search and sorting. It helps when the report contains dozens or hundreds of rows: the user can find a product, sort by amount, or move to the next page. But interactive elements require space and may conflict with a narrow theme column. A plain table in Plain mode is quieter and easier to fit into the design, but it is less practical for long reports.

For a manager page, it is usually best to start with interactive mode and limit the number of rows per page. For a widget or narrow area, it is better to test plain mode or a download link. Do not try to make one version work for every placement. Different display locations require different parameters.

A Safe CSS Adjustment for the Page Wrapper

If the report is too wide, do not edit the plugin files. It is safer to add your own class to the page or block group and style the table through Appearance > Customize > Additional CSS, a child theme, or a trusted snippet plugin. The example below does not use internal AGS Frontend Reports classes because those are not confirmed in the documentation. It works as a cautious wrapper around tables on your report page.

.report-access-page {
  max-width: 1180px;
  margin: 0 auto;
}

.report-access-page table {
  width: 100%;
  border-collapse: collapse;
}

.report-access-page th,
.report-access-page td {
  padding: 10px 12px;
  vertical-align: top;
}

.report-access-page {
  overflow-x: auto;
}

Add the report-access-page class to the page container or block group where the shortcode appears. Then open the page on a desktop screen and on a phone. The table should remain readable, and when space runs out, it should scroll horizontally inside the container instead of breaking the entire layout.

The rollback is simple: remove the CSS or remove the class from the container. If the interactive table styles disappear after the change, your theme or optimizer is probably merging styles too aggressively. Restore the previous version and test the page again without CSS minification.

Labels and Guidance Around the Report

Do not leave the table without context. Before the shortcode, add 2 or 3 sentences explaining which period is shown, which orders are included, who should receive questions about discrepancies, and what the download link means. This is not SEO copy, but a working instruction for the person who will open the page regularly.

A good line before the table might sound like this: "This report shows sales for the selected storefront during a completed period. If an order was created today and the current-day option is disabled, it will appear in the next report. Use the order number and SKU for reconciliation." That context reduces the number of questions and helps people read the numbers correctly.

How to Reduce Width Without Losing Meaning

The simplest way to handle a wide table is to remove unnecessary columns in the preset. CSS helps preserve the layout, but it does not make the report easier to understand. If the user only needs to compare products by quantity and amount, do not display physical address, email, technical fields, or long meta values. If order-level detail is needed, it is better to create a separate report for the operational role than to expand the shared report for everyone.

A second technique is to split tasks across different pages. One page can show a compact table for review, while another offers a detailed export through a download link. That way, a manager quickly sees the essentials and only opens the detailed file when needed. This also simplifies access: a short summary may be available to a broader group, while an export containing sensitive fields is limited to a narrow role.

Combining It with Access Control, Scheduling, and Report Sources

AGS Frontend Reports often becomes most useful not by itself, but when combined with other mechanisms. It is important to distinguish official compatibility from practical WordPress architecture. You should only call something "officially compatible" if the developer says so. Everything else is better described as a safe working pattern built on standard WordPress and WooCommerce capabilities.

Using It with a Content Restriction Plugin

The official product page gives an example: when used together with a content-restriction mechanism, reports can be shown to selected logged-in visitors without granting access to the admin dashboard. In practice, that means the sequence is: first create a protected page, then insert the shortcode, then configure a visibility rule by role, membership, or group.

The conflict point here is cache and preview behavior. Some caching plugins may save the page version after an administrator has logged in. So after configuring the restrictions, clear the cache and test the page as a guest. If the site uses a CDN, check those rules too. The rollback option is to temporarily remove the link from the menu, remove the shortcode from the page, or disable publication until access works correctly.

Using It with Scheduled Email Reports

If the team needs not only a page to open, but also a file delivered on a schedule, the separate Scheduled Email Reports plugin solves a different problem: it emails presets from compatible reporting plugins. In that setup, AGS Frontend Reports remains the self-service viewing point: the employee opens the page whenever needed. Scheduled email delivery is regular distribution without logging into the site.

A practical sequence looks like this: first create and verify the preset in the report source, then display it through AGS Frontend Reports on a protected page, and only after that configure scheduled delivery for the same or a similar preset, if that is actually needed. This way, you can see the result in the browser and compare it to the file being sent by email.

Using It with Product Sales Report Pro, Export Order Items Pro, and Ninjalytics

The source you choose determines what actually appears on the front end. Product Sales Report Pro is closer to product and sales reporting. Export Order Items Pro is a better fit when you need order items, fields, variations, and export formats. Ninjalytics is aimed at more modern analytics with charts, calculated fields, and presets. AGS Frontend Reports does not make those sources equivalent: it displays only what the source can generate.

If you need a product-level report, do not choose a source just because it happens to be installed. Compare the fields, filters, and formats available in each product, create the preset where the task is handled most accurately, and only then move the result onto a page.

Using It with Standard WordPress Pages and Account Areas

Sometimes it makes more sense to embed the report not on a standalone page, but inside an existing protected area: an internal dashboard, a partner portal, a team documentation page, or a custom account section. That is perfectly reasonable if the chosen section supports shortcodes and already has reliable access protection. What you should not do is insert the report into a random block that might appear across multiple public pages.

The safe setup sequence is this: first create an empty section and verify access without the report. Then insert a test shortcode using a safe preset. After that, enable the real preset and test access again under multiple roles. If the account area is built by a third-party plugin, make sure it does not cache the tab contents or expose them to guests.

When the Combination Becomes Too Complex

If one report page requires three access plugins, separate roles, cache exclusions, conditional menus, complex fields, and manual theme edits, it is worth stopping to rethink the architecture. The team may actually need a full internal dashboard, a separate analytics system, or scheduled exports rather than front-end report display. AGS Frontend Reports works well in a moderately complex scenario, but it should not be turned into a replacement for your entire data-management system.

Limits and Risks Worth Accepting Before Publishing

Displaying a report on the front end is convenient, but it requires discipline. The main risk is not an ugly table, but business data becoming available to the wrong people. The second risk is incorrect interpretation of data because of the time period, order statuses, analytics cache, or differences between sources.

The Plugin Is Not a Standalone Analytics Source

If you need a full reporting center with its own charts, segmentation, calculated fields, and advanced filters, look at the report source, not AGS Frontend Reports. Its job is to display a finished result. That limitation does not make the plugin weak. On the contrary, it makes it clear: it solves the narrow problem of moving a report onto a page without exposing unnecessary administrative access.

The Page Inherits the Theme's Limits

The report table is displayed inside your theme. If the theme has a narrow content area, aggressive table styling, or a complicated sidebar, the report may need a CSS wrapper, a wide page template, or a dedicated layout. Check the result in standard content first, then in the widget. Do not move a long table into a sidebar just because widget support exists.

A Downloaded File Leaves the Site

Download Link mode is convenient, but once the file is downloaded it is no longer controlled by WordPress. The user can forward it, save it to the cloud, or open it on another device. So before enabling this mode, configure the preset fields and page access with extra care. If on-page viewing is enough for the user, a table on a protected page is often safer than a file.

Reports from Different Systems May Not Match Perfectly

WooCommerce Analytics, Product Sales Report Pro, Export Order Items Pro, and other tools may interpret dates, statuses, refunds, taxes, shipping, and cached data differently. If the front-end table does not match another dashboard, that is not always an error. First check the methodology: which statuses are included, which date is primary, whether historical data was imported, and whether analytics caching is involved.

When the Report Does Not Appear or the Data Looks Wrong

It is best to troubleshoot step by step rather than changing settings at random. AGS Frontend Reports has several layers: the report source, preset, shortcode parameters, WordPress page, access rules, theme, and cache. If you skip one layer, you can spend a long time fixing the wrong part.

The Page Is Empty or Only the Shortcode Is Visible

Symptom: instead of a table, the user sees an empty block, the raw shortcode string, or a "no data" message. Possible causes include the plugin not being active, the shortcode being inserted into an unsupported location, no report source selected, a deleted preset, the reporting plugin being disabled, or the page being cached as static HTML.

What to check: open WooCommerce > Frontend Reports, generate the shortcode again, and insert it into a Shortcode block on a test page. Then check whether the source generates the report on its own admin page. If the report does not generate there, the public page will not help.

How to fix it: restore the report source, resave the preset, insert a new shortcode, and clear the page cache. If the problem started after an update, check the product changelog and update the connected reporting plugin to a compatible version.

The Report Source Does Not Appear in the Generator

Symptom: the required plugin does not appear in the Report Source field, or the list is empty. The likely cause is that the compatible reporting plugin is not installed, disabled, too old, or not supported by the current version of AGS Frontend Reports. The official documentation lists minimum versions for some sources, and the developer recommends checking the product page for the current compatibility list.

What to check: open the WordPress plugins list and confirm that WooCommerce and the report source are active. Then open the source itself and create a test report. If the source requires a preset, save one and return to the generator.

How to fix it: update the report source, create a preset, and reopen the generator. If the source still does not appear, do not swap in a different product without checking the fields first. Write down the report you actually need and choose a compatible source that can genuinely generate it.

The Data Does Not Match WooCommerce Analytics

Symptom: the amount, order count, or products differ from another WooCommerce dashboard. Possible causes include a different date range, different order statuses, whether today is included or excluded, refunds, taxes, shipping, analytics cache, or different logic in the report source.

What to check: do not compare only the final total. Compare several specific orders. Check the creation date, payment date, or completion date, the order status, refunds, and discounts. WooCommerce Analytics has separate settings for statuses, default range, date type, and cache, so it may calculate things differently from a third-party reporting plugin.

How to fix it: align the period and statuses to a single methodology. If WooCommerce Analytics shows outdated numbers, use its built-in tools to refresh or clear the analytics cache. If the report source is built on different logic, document that on the page so users do not compare incompatible metrics.

The Table Breaks the Layout or Is Hard to Read on Mobile

Symptom: columns get cut off, the search box shifts outside the block, row-expansion buttons look strange, or the widget becomes too wide. This is usually a conflict between the theme width and the number of report columns.

What to check: open the page on a wide screen, tablet, and phone. Compare Display and Plain mode, reduce the number of rows per page, and see whether you can remove unnecessary columns in the preset.

How to fix it: use a dedicated wide page, add a CSS wrapper with horizontal scrolling, or switch to download-link mode. For a widget, stick to a short report or a link only; otherwise the user gets a cramped table instead of a useful tool.

The Report Is Visible to the Wrong Users

Symptom: a guest, customer, or another role can see the report page. This is a critical access-control failure, not a cosmetic issue.

What to check: the page restriction rule, cache, menus, related-content blocks, site search, and the direct URL. Open the page in a private window while logged out and under several different roles. If a CDN is in use, check whether it is serving a cached version of the page.

How to fix it: temporarily unpublish the page or remove the shortcode until access is properly closed. Then configure a role or membership rule, exclude the page from cache, and run the test again. For reports containing personal data, start with the smallest possible field set and only widen access later if necessary.

The Download Link Does Not Return a File

Symptom: the user clicks the link, but the file does not download, an empty file downloads, or the format is not what was expected. Possible causes include the wrong shortcode mode, a preset that does not support the chosen format, the report source failing to generate the file, the server blocking a temporary directory, or a cache conflict.

What to check: generate the same file directly in the report source from the admin dashboard. Verify the format in the preset and the link text in AGS Frontend Reports. Then open the page as an authorized user and download the file again.

How to fix it: correct the format and fields in the preset, generate the shortcode again, and clear the page cache. If the problem is related to temporary files or download headers, check the product changelog and hosting settings. Do not disable protective headers or make directories public unless you fully understand the consequences.

How to Use AGS Frontend Reports in Daily Operations

After setup, the important part is turning the report page into a clear working tool. If you simply insert a table with no explanation, users will still ask why today's order is missing, what a number means, where to download the file, and why one role can see the page while another cannot. A good report page answers those questions right next to the data.

A Short Instruction Next to the Report

Add a short note above the table explaining who is responsible for the report, what time period is used, which statuses are included, how often the page should be checked, and when the data may not update immediately. If the report is intended for a manager, the text should be practical rather than technical. For example: "Check this table at the start of the day. If an order was created today, it will appear only when the current-day option is enabled. For any disputed rows, verify the order number in WooCommerce."

A Rule for Preset Changes

Assign a specific owner for preset changes. If any administrator can modify the report fields, page users will start seeing different data without warning. For recurring reports, it is worth keeping a simple log: who changed the preset, what was added or removed, why it was done, and how the result should be verified.

Post-Update Checks

After updating AGS Frontend Reports, WooCommerce, the report source, the theme, or the access-control plugin, open the test page. Check the table, search, sorting, file download, and guest access. That takes less time than rebuilding trust in the report after an error.

If the store relies heavily on data, create an update checklist:

• Open the report source and generate the preset manually.
• Open the shortcode page as an authorized user.
• Check a private browser window while logged out.
• Verify the downloaded file if Download Link mode is in use.
• Compare several rows against WooCommerce orders.

How to Train the Users of the Report Page

Even if the report is technically configured perfectly, users still need to understand the boundaries of the data. Run a short training session or write an internal quick-reference note: where the page is located, which roles have access, how to use search, how to sort the table, when to download the file, and what to do if a discrepancy appears. Be sure to explain that the page link should not be forwarded to people without access and that downloaded files should be stored in whatever approved location the company uses.

For a store manager, a simple validation formula is useful: period, status, product, amount. If a row looks wrong, first check the period, then the order status, then the product mapping, and only after that the display plugin itself. That habit reduces false technical escalations and helps distinguish a real error from a difference in methodology.

Questions About Setup, Limitations, and Security

Can I use AGS Frontend Reports without another reporting plugin?

No. According to the official description, it is an add-on for displaying reports from compatible sources. If a compatible source is not installed and active, the plugin has nothing to display. Configure the reporting product and preset first, then create the shortcode.

Can I show a report only to logged-in users?

Yes, but access is controlled not by the shortcode alone, but by the page, post, widget, or surrounding WordPress mechanism. Use a rule based on role, membership, group, or login status. Be sure to test the page both as a guest and as a user without access.

Which should I choose: a table or a download link?

A table is better for quick viewing, searching, and sorting on the page. A download link is better for further file processing. If the report contains sensitive data, a table on a protected page is often safer because a downloaded file is easier to forward outside the site.

Why are today's orders missing from the report?

Check the Include today parameter and the date-range logic. The documentation notes that without including the current day, the range may end on the previous day. Also check the order status and the methodology used by the report source.

Can I insert the shortcode into the WordPress block editor?

Yes. Use the Shortcode block. It is intended for inserting shortcodes into page or post content. After insertion, check not only the editor preview, but also the published page under the intended role.

Is the widget suitable for a detailed report?

That depends on the width of the widget area. For long tables, a widget is often too cramped. In that case, use a separate page or download-link mode. The widget is better suited to a compact report, a short table, or an internal block inside a wide theme area.

What should I do if the data differs from WooCommerce Analytics?

Compare the period, statuses, refunds, taxes, shipping, the date used for the order, and the analytics cache. Different reporting tools may calculate metrics using different methodology. For recurring reports, document that methodology next to the table so users understand exactly what they are seeing.

Should I block the page from indexing?

If the page contains a business report, the first priority is protecting it from unintended access. Indexing settings alone do not secure data. Use access restriction, cache exclusion, and direct-URL testing. If your SEO plugin allows it, you can also add a noindex rule to the protected internal page.

When AGS Frontend Reports Is the Right Choice

AGS Frontend Reports is a good choice when you already have, or plan to use, a compatible WooCommerce reporting source, and you need to show the result not in the admin dashboard but on a selected page, post, or widget. Its strength is a narrow, clear job: take a prepared report, turn it into a table or a file link, and give the user access without unnecessary administrative navigation.

Before going live, verify the report source, preset, time period, field set, access page, cache settings, and table appearance. Once all of that is configured, you can download AGS Frontend Reports and test the plugin on a staging copy of the site or on a protected page. Do not start with open public access: first make sure only the intended role can see the report and that the data matches the agreed methodology.

If you need a separate analytics center, automated email delivery, deep charting, or complex segmentation, start by choosing the right reporting source. But if the source already exists and the problem is specifically how to display the result safely on the front end of the site, AGS Frontend Reports handles that job cleanly without requiring broad WooCommerce access for users.