When designing dashboard interfaces or client portals, developers often need to display a compact list of the most recently uploaded files (e.g., “Last 5 Activity Reports”). Historically, developers achieved this by loading the entire list and hiding extra items using custom CSS rules (such as :nth-child or display: none;).
This document explains how Simple File Vault natively resolves this use case at the data registry layer using the limit attribute, detailing the server-side data lifecycle, query truncation, and how frontend pagination controls are automatically suppressed.
1. Defining the Limit Attribute
The file list rendering engine accepts a native limit parameter. This can be configured in two ways:
A. Via Gutenberg Block Settings
When editing a page containing the File Table or Safe File Vault block, locate the File Display Constraints panel in the block settings sidebar. Set the Max Files to Display input field to your desired count (e.g., 5).
B. Via Shortcode
If you are working in classic templates, PHP layouts, or page builders (Elementor, Divi, Beaver Builder), pass the limit attribute directly to the shortcode:
[sfvlt_safe_file_vault limit="5" orderby="date" order="desc"]
or
[sfvlt_file_table limit="5" orderby="date" order="desc"]
2. Server-Side Data Truncation (The Registry Layer)
Hiding elements with CSS is a security risk and wastes server resources because the browser still fetches the full list of files over the REST API.
In contrast, Simple File Vault processes the limitation at the PHP registry and REST API query layer. The data lifecycle operates as follows:
[REST API Request] ➔ [Fetch Registry Cache / Directory List] ➔ [Apply Sort (e.g., Date DESC)] ➔ [Array Slice Limit] ➔ [Return Truncated JSON Payload]
When a request is sent to the secure endpoint:GET /wp-json/safe-vault/v1/files?limit=5&orderby=date&order=desc
The server-side filter sfvlt_search_use_cached_registry() (in Simple File Vault Pro) handles sorting and then uses PHP’s native array_slice() to truncate the results before sending them to the client:
// Extract limit parameter from the request
$limit = $request ? $request->get_param( 'limit' ) : '';
if ( ! empty( $limit ) && is_numeric( $limit ) ) {
$limit_val = intval( $limit );
if ( $limit_val > 0 ) {
// Slice the sorted array cleanly at the registry layer
$filtered = array_slice( $filtered, 0, $limit_val );
}
}
Because the truncation happens on the server, a vault containing 10,000 files will only return a JSON payload with exactly 5 records, drastically saving database memory, network bandwidth, and client processing time.
3. Suppressing Pagination Controls
When a hard display limit is set, pagination controls are logically counterproductive. If a user could paginate, they would bypass the limit constraint.
The rendering callback sfvlt_render_file_table_block handles this automatically:
// Pagination is only shown if explicitly requested AND no limit constraint exists
$limit = isset( $attributes['limit'] ) ? $attributes['limit'] : '';
$paginate = isset( $attributes['paginate'] ) ? (bool) $attributes['paginate'] : false;
$show_pagination = $paginate && empty( $limit );
If $show_pagination is false, the pagination HTML wrapper and its controls (sfvlt-pagination-prev and sfvlt-pagination-next buttons) are omitted from the page output:
<?php if ( $show_pagination ) : ?>
<div class="sfvlt-pagination-container" style="margin-top: 15px; display: flex; justify-content: space-between;">
<button type="button" class="button sfvlt-pagination-prev" disabled><?php esc_html_e( 'Previous', 'simple-file-vault' ); ?></button>
<button type="button" class="button sfvlt-pagination-next" disabled><?php esc_html_e( 'Next', 'simple-file-vault' ); ?></button>
</div>
<?php endif; ?>
This clean omission prevents layout shifts, eliminates the need for styling overrides, and ensures client portals remain clean, secure, and performant.
