FacetWP Time Since - WordPress Plugin

How to Configure FacetWP Time Since for Time-Based Content Filtering

FacetWP Time Since is not meant for a standard calendar date picker. It is designed for clear filtering by relative time periods: "past day," "past week," "past month," "past year," "today," "tomorrow," or any other interval you define in the facet settings. In this guide, we will walk through how to prepare a WordPress site, choose the right date source, build a useful list of time periods, verify the output, and tell the difference between a Time Since issue and a broader FacetWP problem.

This guide is for site owners, webmasters, and developers who already understand why facet-based filtering is useful on a page, but want to make it practical for a real catalog: news, events, job listings, classifieds, recently updated posts, a knowledge base, or any content list where freshness affects the user's decision. It does not cover purchasing, licensing, or unofficial ways to obtain the product. The focus here is configuring and testing a plugin that is already installed.

The core idea behind Time Since is simple, but the implementation has a few important details. The plugin pulls a date from the selected field, interprets the period string through PHP's relative date handling, compares it to the current time, and shows the visitor only the items that fall within the selected window. That means the option labels are only part of the setup. The field format, WordPress timezone, FacetWP indexing, interface type, and the way the listing itself is built all matter too.

Where Relative Time Filtering Is Actually Useful

Time Since works best when the user does not need to enter an exact date. If someone is looking for fresh news, new products, updated documents, upcoming events, or older posts in an archive, it is usually easier to choose a ready-made period than to open a calendar and figure out the right date range. That is what sets Time Since apart from a traditional Date Range facet: it does not force the visitor to think in start and end dates, but instead offers predefined, meaningful options.

A good example is a "News" or "Articles" section. A user can choose "Past 7 Days" and immediately see recent posts. In a job listings catalog, you might offer "Past 24 Hours," "Past Week," and "Past Month," because older listings are usually less useful. For events, bookings, or schedules, Time Since can also work in the other direction: "Today," "Tomorrow," or "Next 7 Days." The official documentation also shows a past/future setup where choices like "Future" and "Past" are built around broad relative ranges.

It is important not to confuse a relative period with grouping by month or year. Time Since is not intended for a facet like "2024," "2025," "January," or "February." The official documentation states this directly: for month/year filtering, you need a different approach, such as indexing a custom value with facetwp_index_row. If the goal is to give users a year-based archive, Time Since is not the best tool. If the goal is to separate fresh, older, current-day, or upcoming posts, it is a much better fit.

Common Use Cases

For most sites, it is better not to start with every possible period. Start with one question instead: what decision is the user making based on the date? If the date helps indicate freshness, you need short past intervals. If the date represents an event, you need current-day and future intervals. If the date marks the validity of a listing, you may need a separate range such as "Older than 1 year" or "Archive."

• Media and blogs: "Today," "Past 7 Days," "Past 30 Days," and "Past Year" help users narrow down a fast-moving stream of content.
• Knowledge bases: filtering by Post Modified highlights recently updated articles, which is useful for documentation and support.
• Events: options like "Today," "Tomorrow," and "Next 7 Days" help keep past and current events separate.
• Classified listings: visitors can hide outdated entries if the publish date or update date genuinely reflects relevance.
• Private document libraries: administrators can quickly find items added or changed within a recent period if FacetWP is configured against the correct listing.

You should not use Time Since as a decorative filter "just in case." If the listing is updated rarely or the date does not affect how people choose content, the facet will only add noise. In that case, the space is usually better spent on a filter by topic, category, author, price, status, or another attribute that does more to help users find what they need.

How Time Since Differs from Date Range

FacetWP's built-in Date Range provides calendar-style input: the user selects a specific date, a start and end date, or an exact range. That works well for hotels, schedules, archives, reports, and event listings where the visitor knows the calendar boundaries. Time Since works differently: the administrator defines the selectable strings in advance, and the visitor clicks a clear, human-readable period. That usually makes Time Since simpler for the public-facing site and faster for common tasks.

There is a tradeoff. Time Since is limited to the intervals you list in the Choices field. If a visitor needs a custom range from one date to another, they will need Date Range or another tool. That is why the choice between these two facet types should be made before setup, not after users start complaining that there is "no calendar."

Practical rule: if the user thinks in terms like "recent," "past week," "upcoming," or "older," choose Time Since. If they think in exact calendar boundaries, choose Date Range.

Who FacetWP Time Since Is For, and When a Different Approach Makes More Sense

FacetWP Time Since is a strong fit for sites that already use FacetWP, or are planning to build full facet-based filtering on top of WordPress posts, custom post types, taxonomies, and custom fields. The add-on does not replace the core FacetWP plugin. It extends the available facet types and adds a time-based selection type. So the first question before installing it is whether you already have a working listing that FacetWP can filter.

The plugin is especially useful for teams that want administrators to stay in control of the time periods. You can show users a clear label like "Past 30 Days" instead of a technical string like "last 30 days"; you can keep only two periods if a long list gets in the way; and you can choose an interface type that fits the page better. Time Since is especially effective on pages with a large amount of content, where date is only one of several filters alongside categories, types, locations, authors, or tags.

Good Candidates for Installation

If you already have a FacetWP Listing Builder template, a WordPress archive, a custom WP_Query, or a block-based listing that works correctly with FacetWP, you can add Time Since as a separate facet. It does not require you to rebuild the whole page, but it does require careful selection of the Data Source and a full re-index after configuration.

• Content sites with frequent updates: news, reviews, articles, reference sites, and documentation.
• Event sites: schedules, event calendars, webinars, training sessions, and listings with an event date stored in a custom field.
• Job boards and classified catalogs: pages where freshness directly affects whether users trust the listing.
• WooCommerce catalogs with FacetWP: cases where shoppers want to see recently added products, assuming the listing is built around products as posts.
• Technical knowledge bases: article listings where filtering by Post Modified helps users find recently updated materials.

When Time Since May Be Unnecessary

If a page contains ten items and gets updated only a couple of times a year, a dedicated time filter may feel artificial. If the date is stored in an unstable format, such as arbitrary text like "spring," "coming soon," or "after approval," Time Since will not be able to build reliable ranges either. It needs a date source that can be mapped to an actual point in time.

You should also not expect Time Since to provide a full calendar, advanced recurring event logic, or filtering across a pair of start/end fields with range overlap. For those cases, you are better off looking at Date Range, event-focused plugins, custom hook-based indexing, or a specialized filter built into another system. Time Since solves one problem cleanly: "select posts relative to the current date." The farther you move away from that use case, the more extra machinery you will need.

What the Administrator Needs to Know

For a basic setup, it is enough to be comfortable in the WordPress admin: install the add-on, create a facet, choose a data source, place the facet next to the listing, and click Re-index. But if you need non-standard periods, dynamic string translation, counter customization, or a filter like "Older than 1 year," you will also need to work carefully with PHP snippets. The official documentation suggests adding that code in a child theme, through the Custom Hooks add-on, or with a code snippets plugin.

If you do not want to touch code at all, stay within formats that strtotime understands: -1 day, -7 days, -30 days, today, tomorrow, yesterday, and +7 days. That is enough for most public-facing pages. Code-level customization is only needed when the business rules do not fit standard relative date formats.

What to Check Before Installing the Add-On

Preparation matters more than it may seem. If the page does not have a valid FacetWP listing, if the date is not stored where you think it is, or if the index has not been refreshed, Time Since may look "broken" even though the add-on itself is working normally. Before installing it, it is worth doing a quick environment and data check.

First, make sure the core FacetWP plugin is installed and already used on the target page. Time Since is an add-on facet type. It adds a new facet type, but it does not create the filtering system from scratch. The page needs a listing that FacetWP recognizes as filterable: a Listing Builder template, a supported block, an archive, an Elementor/Bricks/Beaver Builder integration, or a properly marked custom query.

Checking the Date Source

The official Time Since documentation lists several possible sources: Post Date, Post Modified, or a custom field in YYYY-MM-DD format. The ACF documentation also notes that FacetWP can handle ACF Date Picker and Date Time Picker fields as data sources while respecting how those values are stored in the database. That is convenient, but it does not remove the need to verify the actual values saved in your posts.

Before adding the facet, open a few items from the future listing and confirm that the date is actually filled in. For a custom field, every post that should appear in the filter must have a saved value. If the field was added through ACF after the posts were already published, older entries may not have a stored value until they are resaved or updated in bulk. In that case, Time Since will not be able to calculate the options correctly, and the problem may look like an empty facet.

When to Choose Post Date

Post Date works well for news, articles, products, classifieds, and any post type where the publish date is the relevance date. It is the simplest source. It does not require ACF, and it is usually populated for every post. But it has one limitation: if an editor updates an older article, the publish date does not change. For a knowledge base or documentation section, that may not be what you want.

When to Choose Post Modified

Post Modified is better for sections where update freshness matters. For example, a user may want to see recently revised instructions, updated documents, or corrected records. But this source can change unexpectedly after bulk edits, migrations, imports, SEO field updates, or automated metadata changes. If your editorial workflow touches posts frequently, make sure the team understands that this filter reflects the modification date, not the original publication date.

When You Need a Custom Field

You need a custom field when the date has its own meaning: an event date, application deadline, release date, tour start date, or listing expiration date. In those cases, the post publication date may have nothing to do with the filtering behavior. With ACF, it is usually better to choose the field from the ACF group in the FacetWP source list rather than selecting a technical meta key with the same name, unless the documentation for your specific case says otherwise.

WordPress Timezone

Time Since uses the timezone configured in WordPress under the general settings page. This matters most for values like today, tomorrow, yesterday, and short ranges such as -1 day. If the site serves an audience in one region, set the site timezone to that region. If the admin team manages the site from another country, do not rely on the editor's local time. Use the time that should define the public-facing filter.

Timezone differences are rarely noticeable for a range like "past year," but they can completely change the listing for "today" right at the day boundary. That is why your tests should include posts near the edge of the day: one slightly before and one slightly after. That will quickly show whether the editorial expectation matches WordPress behavior.

Checking the Listing and the Index

FacetWP relies on its own index table. After creating or changing facets, you need to run Re-index. If you skip that step, the facet may show no options, display outdated counts, or miss new values. FacetWP's official troubleshooting documentation also reminds you that the page must have a valid listing template, and a custom post type's exclude_from_search setting must not interfere with indexing.

Quick pre-install checklist: core FacetWP is working, the target listing responds to another simple facet, test posts have the date field filled in, the WordPress timezone is clear, and you are ready to run a full re-index after setup.

Installation and Initial Validation in WordPress

Installing FacetWP Time Since is similar to installing other FacetWP add-ons. The official installation documentation explains the general process: upload the ZIP from your account through Plugins and Add Plugin, or manually place the folder into /wp-content/plugins/, then activate it. This guide does not cover purchasing, payment, or access keys. For practical purposes, it is enough to know that Time Since is installed as a separate add-on on top of the core FacetWP plugin.

After activation, do not start by checking the public page. Go to the FacetWP admin settings first. Open the facet settings and confirm that a new facet type called Time Since appears in the list of available types. If it does not appear, first make sure the add-on is active, then verify that core FacetWP is active and not failing because of a PHP error. Do not start building the listing until the new facet type is visible in the interface.

First-Run Order

1. Confirm that core FacetWP is working. It is best to test this with a simple facet, such as category or post type, so you do not mix a base FacetWP problem with a Time Since problem.
2. Activate the Time Since add-on. After activation, open the facet creation screen and find the Time Since type.
3. Create a test facet. Give it a clear editor-facing label and a short technical name without spaces, such as freshness or event_period.
4. Choose a simple date source. For the first test, it is safer to use Post Date if it fits the test listing. Add a custom field only after you have confirmed that the facet type itself is working.
5. Add 2-3 choices. For example, Past 7 Days | -7 days and Past 30 Days | -30 days. Leave more complex custom ranges for the second phase.
6. Place the facet next to the listing. Use a FacetWP block, shortcode, or PHP output depending on how the page is built.
7. Click Re-index. Then open the public page and confirm that the listing changes when you select a period.

This sequence may not be the fastest, but it reduces the number of moving parts. If you immediately choose an ACF field, a complex custom token, fSelect, translated labels, and caching, any issue will look like "Time Since does not work," even though the real cause may be the data, the index, the template, or external optimization.

Where to Place the Facet

FacetWP lets you output facets through shortcodes, blocks, widgets, or PHP. The important thing is to keep the facet out of the container that FacetWP replaces after filtering. The troubleshooting documentation specifically mentions problems with facetwp-template: if the filter ends up inside the container being replaced, it may disappear after the first refresh. Listing Builder usually prevents this automatically, but in custom templates and page builders you need to check the page structure more carefully.

On a standard page, it is usually best to place Time Since with the other filters, above or beside the listing. If the period is the main navigation method, you can place it first. If it is a secondary refinement filter, it usually makes more sense after the category or content type filter. On mobile pages, a long list of periods is often better collapsed into a dropdown or fSelect, especially when several other facets are already present.

Configuring the Facet: Date Source, Choice Options, and Interface Type

The most important part of the Time Since setup consists of a few simple-looking fields. They seem straightforward, but this is where mistakes usually happen: the wrong date source, an invalid period format, too many options, or an interface that does not match user behavior. It is better to think of the setup not as a list of fields, but as a sequence of decisions.

Data Source: Where the Date Comes From

Data Source should point to the date you actually want to filter by. If the filter is supposed to show fresh publications, use Post Date. If it should show recently updated content, use Post Modified. If it should work from an event date, deadline, course start, or another domain-specific date, use a custom field that stores the date in a valid format.

When choosing a custom field, do not rely on memory alone. Open a couple of posts, check how the field is filled in, and make sure you are selecting the exact source that FacetWP indexes. For ACF Date Picker and Date Time Picker fields, use the ACF group entry in the source dropdown, because FacetWP applies special handling to those fields. If the facet is empty after indexing, create a temporary test facet with Post Type as the Data Source. If that works, the problem is almost certainly not the page itself, but the selected date source.

Default label: What an Empty Selection Means

Default label controls the "Any" text for the selected interface type. In Radio mode, it can add an option above the others; if you leave the field empty, the "Any" option can be removed. In Dropdown and fSelect, it becomes the first empty option. On a localized site, you should not leave the public-facing interface with the English word "Any" if the rest of the filters are translated.

The label should answer the user's question. If the facet is called "Period," the empty selection might be "Any Period." If the filter is used for events, "All Dates" may be a better fit. If it is a knowledge base filtered by updates, you could use "No Time Limit." Just do not make the label too long, because in a dropdown it sits in the first position and can look like a full choice rather than a reset state.

The documentation notes that the label can be translated with facetwp_i18n. That is useful for multilingual sites, where dynamic strings stored in the database are not always exposed to WPML or Polylang like standard translation strings. In a simple single-language project, it is usually enough to enter the translated text directly in the setting.

Choices: How to Write Periods Without Errors

The Choices field accepts lines in the format label | format. The label on the left is what the visitor sees, and the format on the right is what Time Since passes into the relative date parser. The official documentation gives examples like these:

Past Day | -1 day
Past 7 Days | -7 days
Past 30 Days | -30 days
Past 90 Days | -90 days
Past Year | -1 year
Next 7 Days | +7 days
Today | today
Tomorrow | tomorrow
Yesterday | yesterday

The label can be written in any language, but the format on the right should stay as a PHP-friendly English relative date string. That is not "English text in the interface"; it is the technical value of the setting. The | separator matters. If you forget the vertical bar or swap the label and format, the facet will not be able to parse the choice correctly.

Do not overload the list. For a news section, four options are often enough: "Today," "Past 7 Days," "Past 30 Days," and "Past Year." For events, you might use "Today," "Tomorrow," "Next 7 Days," and "Past." For jobs, shorter periods are often more useful because freshness matters more than archive depth. The longer the list, the higher the chance that users stop noticing the most important choices.

How to Choose Intervals

The interval should reflect the actual density of the content. If the site publishes one article a month, "Past Day" will almost always be empty. If the catalog updates every hour, "Past Year" may not help at all. Before finalizing the setup, review how posts are distributed across dates: how many fall within the last day, week, month, and quarter. You can do that in any familiar way from the admin panel or a report; this guide does not require running technical commands.

Values like "today," "tomorrow," and "yesterday" are especially sensitive to timezone settings. If an editor sees a post as "today" in local time, but the site runs in another timezone, the filter may behave differently. On sites managed by teams across regions, it is best to agree in advance which timezone counts as the official one for public-facing filtering.

UI type: Radio, Dropdown, or fSelect

Newer versions of Time Since include a UI type setting. The official documentation describes three options: Radio, Dropdown, and fSelect. The right choice depends on how many options you have, how much space is available on the page, and what kind of behavior users are likely to expect.

How to Choose a Time Since Interface Type

Type	Best fit	What to watch for
Radio	A short list of 2-5 options where the period matters and should be visible right away.	Takes up more space, shows counts next to each option, and needs concise labels.
Dropdown	A compact filter panel, sidebar, mobile view, or a medium-length list of options.	The native select looks different across browsers; you may need CSS or prefer fSelect instead.
fSelect	When you want a more controlled dropdown look and styling that matches other fSelect-based settings.	Do not choose it just for appearance; test accessibility, mobile behavior, and translation of helper strings.

For an initial launch on a content site, Radio is usually the easiest choice because editors can immediately see which options appear and what counts each period has. Once that is validated, you can switch to Dropdown or fSelect if the interface takes up too much space. After changing important facet settings, always re-index and verify the page on the public-facing site.

Show ghosts: Whether to Show Empty Periods

Show ghosts displays options that currently return no results, but shows them as dimmed and unavailable. For Time Since, that is useful when you want the filter to keep a clear, stable structure: the user can see that "Today" exists even if there are no matching items right now. If the setting is turned off, empty choices will be hidden.

This setting matters most for short periods. On an events site, "Today" may be empty some days and populated on others. If the option disappears completely, users may think the filter is unstable. If they see a dimmed option, the behavior is easier to understand. But on long lists, empty choices can clutter the interface, so enable Show ghosts only when a stable structure genuinely helps users orient themselves.

How Time Since Turns a Post Date into a Period Filter

To troubleshoot Time Since properly, it helps to understand how it works. The user clicks "Past 30 Days," but several steps happen behind the scenes: FacetWP takes the selected technical format, calculates the period boundary relative to the current time, compares that boundary against the indexed post dates, and returns an updated listing HTML over AJAX. If any part of that chain is wrong, the final list can look confusing.

Input: The Date in the FacetWP Index

FacetWP does not scan the entire WordPress database every time a user clicks a filter. It builds its own index table that stores facet values. In the FacetWP documentation, that table is called facetwp_index. After a re-index, it contains the values FacetWP uses to render choices and filter results efficiently. For Time Since, the critical requirement is that a valid date ends up in the index in a format the system can understand.

If a post has no value in the selected source, it may not participate in the expected time-based choice. If the value exists but is not a date, the outcome depends on whether the parser can interpret the string correctly. For standard Post Date and Post Modified, that is usually safe. For custom fields, everything depends on how those fields are stored.

Rule: Period String and Relative Date Parsing

The format on the right side of the vertical bar is based on how strtotime works. This PHP function accepts an English text description of a date and tries to convert it into a time relative to a reference point. That is why strings such as -7 days, +1 month, today, tomorrow, and similar values can work as technical formats. But relative dates have edge cases. The official PHP documentation warns about timezone impact and the subtleties of some relative expressions.

For a public-facing filter, it is best to use simple, obvious formats. Strings such as last Monday or more complex month-based combinations may be understandable to PHP, but not necessarily to the editor who will maintain the site after you. The simpler the format, the easier it is to verify the outcome and explain it to the team.

State Change: The Selected Item Updates Query Variables

FacetWP adds selected facet values to the URL as query variables and sends a refresh request. That is helpful to users because the filter state can be saved, shared with colleagues, or restored after a page refresh. For Time Since, this means the technical value behind each choice should be stable and should not conflict with other facets.

If you change the choice label, the public-facing text changes. If you change the technical format, the filtering behavior changes. That is why it is better to agree on the final formats before launch and avoid changing them every week. If a filtered URL has already been shared in email or used in the site's internal navigation, sudden value changes can break user expectations.

Output: Updated Choices and Listing

FacetWP facets are aware of each other and update their choices based on the current result set. You can see this in FacetWP demos: selecting one facet changes the available options in others. For Time Since, that means the count for "Past 30 Days" depends not only on the date, but also on all other active filters. For example, if the user selects the "Releases" category, the "Today" period may become empty even though there are posts from today in another section.

This behavior is useful, but it can be confusing during testing. If a Time Since choice "does not show the expected post," reset all other filters first. Then verify the period by itself. Only after that should you test it together with categories, a search facet, sorting, or WooCommerce attributes.

The workflow: the post date enters the index, the selected format defines the time boundary, FacetWP compares it to indexed values, and then updates the choices and the listing. Troubleshooting should follow that same order.

Custom Ranges, Future Dates, and Use Cases Beyond "Past Month"

The basic formats are enough for many sites, but Time Since becomes much more useful when you tailor the intervals to the real meaning of the content. The documentation highlights two important directions: custom time ranges via facetwp_time_since_date_range and a past/future facet for splitting upcoming and past records. These features should not be applied automatically, but they solve problems that a simple "day, week, month" list does not cover.

Custom Range "Older than 1 Year"

The official example shows an "Older than 1 year" choice with a custom token over-1-year. PHP does not understand that token on its own, so the developer adds the facetwp_time_since_date_range filter and manually defines the lower and upper boundaries. In a public-facing interface, this can be presented simply as "Older than 1 Year."

First, add this line to Choices:

Older than 1 year | over-1-year

Then add a small PHP snippet through a child theme, the Custom Hooks add-on, or a reliable code snippets plugin. Do not edit WordPress core, the main FacetWP plugin, or the add-on files.

add_filter( 'facetwp_time_since_date_range', function( $range, $format ) {
    if ( 'over-1-year' === $format ) {
        $dt1 = new \DateTime( '1970-01-01' );
        $dt2 = new \DateTime( '-1 year' );

        $range['lower'] = $dt1->format( 'Y-m-d' );
        $range['upper'] = $dt2->format( 'Y-m-d' );
    }

    return $range;
}, 10, 2 );

After adding the code, run Re-index and test several posts manually. If this range is only needed on one page, make sure its presence does not confuse other Time Since facets. The code responds to the format token, not the facet name, so the same token used in multiple facets will behave the same way everywhere.

Past/Future for Events and Schedules

Time Since can also be used to separate future and past entries. The official example suggests choices with broad boundaries:

Future | +100 years
Past | -100 years

For this use case, it is especially important that the data source point to the event date, not the post publication date. If you use Post Date, "future" posts will only appear if the WordPress query itself outputs future post dates. The documentation explicitly calls this out. On a typical public WordPress site, future publications often do not appear as ordinary published posts, so for event listings it is usually better to store the event date in a custom field and build the listing from published posts rather than future publication dates.

Testing a past/future setup should include at least three posts: one with a past date, one with today's date, and one with a future date. That will show how the chosen format treats boundary cases. If today's events should count as "future," label the filter more carefully, such as "Current and Upcoming," and validate the behavior against the real field.

Why Month/Year Filtering Should Not Be Built with Time Since

A request like "FacetWP year filter" sounds similar, but it is a different problem. Time Since compares a date to a relative boundary. A year or month archive is closer to a separately indexed value. That is why the documentation points you to a facetwp_index_row example if you need choices by month or year. For editors, this is an important distinction: "past year" and "year 2025" are not the same thing. The first is always relative to the current date; the second refers to a fixed calendar year.

If you are building a publication archive, use a separate year facet or custom indexing. If you are building a freshness filter, Time Since is a good fit. Trying to make one behave like the other leads to confusing expectations: users think they are looking at a calendar archive, but they are actually getting a rolling relative period.

Practical Example: Fresh Articles and an Updated Knowledge Base

Let us walk through a practical setup that can be repeated on most content sites. Suppose you have a WordPress knowledge base with many articles, some of which are updated regularly, and users want a quick way to find fresh or recently revised instructions. The goal is to add a facet called "Freshness" that filters the listing by Post Modified with choices like "Past 7 Days," "Past 30 Days," and "Past Year."

Goal

We want visitors to open the knowledge base page, select a period, and see only the articles that were updated during that time window. This kind of filter helps distinguish actively maintained documentation from older material, but it does not claim that every article is "better" or fully current. It reflects a date change, while editorial quality remains a separate judgment.

Preparation

Before setup, the following conditions should be in place:

• The core FacetWP plugin is installed and working.
• There is a knowledge base page with a FacetWP-enabled listing.
• The knowledge base entries are a searchable post type for FacetWP.
• The listing contains enough articles with different modification dates.
• The team understands that bulk-saving posts can change Post Modified and affect the filter.

If the knowledge base uses Listing Builder, open Settings and FacetWP, then the listings tab. If you are using a custom query, make sure FacetWP is detecting the correct query. In a more complex template, it is smart to test a simple category facet first so you do not blame Time Since for a problem that actually comes from the listing itself.

Setup Steps

1. Create a new facet and name it something like "Freshness." A short technical name such as updated_period works well.
2. Set the facet type to Time Since.
3. Choose Post Modified in Data Source, because the goal is to filter by update date rather than publish date.
4. Set Default label to "Any Period," or leave it empty if you do not want a separate reset option in Radio mode.
5. Add these lines to Choices: Past 7 Days | -7 days, Past 30 Days | -30 days, Past Year | -1 year.
6. For the first test, use Radio so you can see all options and counts. After validation, you can switch to Dropdown.
7. Save the facet, place it on the page next to the listing, and run Re-index.
8. Open the public-facing page, select "Past 30 Days," and confirm that the list narrows the way you expect.

Validating the Outcome

Select 3-5 articles whose modification dates you know. One should be recently changed, one should be old, and one should sit near the edge of the chosen period. Check whether each post appears in the expected choice. Then activate another facet, such as category, and see whether the Time Since counts change. That is normal FacetWP behavior: choices are recalculated against the current filtered result set.

After that, inspect the URL. Selecting a period should add a query variable for the facet. If the URL changes but the listing does not, look for a problem in query detection, JavaScript, the REST/AJAX response, or caching. If the URL does not change at all, the problem may be in how the facet is rendered, a script conflict, or the element being placed inside a container that gets replaced.

A Commonly Overlooked Detail

Post Modified does not always mean a meaningful editorial update. A change to an SEO field, a bulk migration, an author edit, an import, or autosave behavior can all update the modification date. If your site needs a strict editorial "review date," it is better to store that in a separate ACF Date Picker field and filter against it instead. That way, the editor decides when an article has actually been reviewed, and Time Since becomes a filter based on an intentional date rather than any technical change to the post.

How to Validate the Result After Launch

Testing Time Since should be multi-layered. It is not enough to click one option and see the list change. You need to verify that the choices appear correctly, the counts are not misleading, the listing refreshes without errors, the URL preserves state, and the selected periods match the actual post dates.

Checking Choices and Counts

Start with Radio mode, even if the final interface will be a dropdown. Radio makes it easier to see all choices and their counts at once. If Show ghosts is enabled, empty choices should appear dimmed and unavailable. If the setting is off, empty choices may disappear. Either behavior is valid as long as it was chosen deliberately as part of the interface design.

Counts should be tested both with no active filters and in combination with other facets. For example, "Past 30 Days" may show 20 posts without a category filter and 3 posts inside the "Documentation" category. That is not an error. It shows that FacetWP recalculates choices based on the current result set. The real problem starts when the count says one thing but the listing shows another, or when a selected period returns entries that clearly do not belong in that range.

Checking the XHR Request and Console

If the facet looks like it is not working, open your browser's developer tools and check the Network/XHR tab. FacetWP's troubleshooting documentation recommends reviewing response codes: 200 means the request succeeded, 401 can indicate restricted access, 403 can point to a firewall or security service block, 404 often signals a REST API problem, and 5XX points to a server-side error or PHP fatal. This is not specific to Time Since, but it helps separate an add-on issue from an infrastructure issue.

You should also check the console for JavaScript errors. FacetWP fills shortcode placeholders through JavaScript after the page loads and sends AJAX requests when users interact with facets. If an optimization plugin deferred, combined, or broke the required script, the facet may render only partially or stop updating the listing.

Checking the Index and the Date

If the interface works but the choices are empty, go back to the index. Click Re-index after any change: Data Source, Choices, custom range code, translated labels, or corrected post dates. If the facet is still empty after re-indexing, temporarily create a test facet for Post Type or another simple source. If that one shows values, the listing and the core FacetWP setup are fine, and the problem is in the date field or the choices.

For a custom field, do not check only the format. Also confirm that the value is actually saved. In ACF, there are cases where a field has been added to a group, but older posts have not yet stored a value in the database. FacetWP may see an empty field even though the editor expects it to be filled. A safe approach is to open several test posts, save them again, and run a re-index. If that helps, consider a proper bulk data update through WordPress or your import workflow, but test it on a site copy first.

Safe Interface Enhancements and Localization

Time Since often needs less deep development than careful interface refinement: translating dynamic labels, hiding counts where they get in the way, making a dropdown match the rest of the filters more closely, or adding a clear archive-oriented range. Below are a few safe techniques based on official FacetWP hooks and recommendations. Use them on a site copy or staging environment first, then move them to the live site only after validation.

Translating Labels with facetwp_i18n

If the site is multilingual and some dynamic strings are not picked up by WPML or Polylang, the FacetWP documentation recommends facetwp_i18n. It can be used for labels and some facet strings, including Time Since choices. The example below is not a universal dictionary for every site. It is a pattern: you map the source string and translate it for the active language.

add_filter( 'facetwp_i18n', function( $string ) {
    $translations = array(
        'Past 7 Days' => 'Past 7 Days',
        'Past 30 Days' => 'Past 30 Days',
        'Any' => 'Any Period',
    );

    return isset( $translations[ $string ] ) ? $translations[ $string ] : $string;
} );

After adding the snippet, open the page in the target language, clear the cache, and check not only Time Since itself but also User Selections if it displays the chosen values. If a string does not change, confirm that the source text in the array exactly matches what is actually saved in FacetWP. A common mistake is translating "Past 7 days" when the choice is stored as "Past 7 Days."

Hiding Counts Only for Time Since

Counts are useful during testing, but in the public interface they can sometimes clutter the filter. The official documentation includes CSS for hiding counters and a more targeted approach by facet type. If you want to hide counts only for Time Since in Radio mode, use a selector based on data-type:

[data-type="time_since"] .facetwp-counter {
    display: none;
}

This CSS is best added in a child theme or wherever your project stores its styles. After applying it, confirm that the counts disappear only where you intended. If you have multiple Time Since facets and only want to hide one of them, target the specific facet class, such as .facetwp-facet-updated_period. Do not remove counts with a PHP filter until you are sure simple CSS is not enough.

Rollback and Caution

Every customization should be reversible. For CSS, that is as simple as removing the rule and clearing the cache. For a PHP snippet, keep the original code, disable the snippet if there is a problem, and run a re-index if the code affected ranges or indexed values. Do not introduce several changes at once. If you translate labels, hide counts, and change choices at the same time, it becomes harder to tell which change caused the issue.

Required step: after a PHP change for a custom range or a translation of dynamic choices, verify the page on the public-facing site, the active URL, and the filter reset behavior. Seeing "saved" in the admin does not mean it has been tested from the user's perspective.

Working with Other WordPress and FacetWP Features

Time Since rarely works in isolation. It usually sits alongside search, categories, sorting, filter reset controls, a mobile filter panel, a page builder, or multilingual content. Those combinations are useful, but they also cause most of the "strange" issues. That is why setup is easier to understand when responsibilities are split clearly: Time Since handles the relative period, core FacetWP handles the index and AJAX, the listing handles the content output, and the theme or optimization layer affects rendering and script loading.

With Listing Builder

Listing Builder is convenient because you can visually assemble the output and then add facets. For Time Since, it is a good option if you want to surface fresh posts quickly without writing a manual PHP loop. In the Query tab, you can choose the post type, the number of items, and the sort order. If the listing is supposed to show posts based on an event date, make sure the query is not excluding the necessary items before the user even applies the filter.

Be especially careful with initial filtering rules. If you have already limited the listing to future events only, a "Past" facet will never return anything. That is not a Time Since issue. The data was excluded by the query before the facet ever ran. Decide first whether the query should include all potentially relevant items and let Time Since divide them for the user, or whether some items should always be hidden.

With the Block Editor

The FacetWP Blocks add-on provides a Facet block and a Listing block. That is convenient for block editor sites because editors do not need to remember shortcodes. But the same rule still applies: the page should contain only one main filterable listing. Static lists can exist alongside it if they do not respond to facets. If the page contains multiple dynamic lists, make sure Time Since is controlling the one you actually intend to filter.

With ACF

ACF is often used for event dates, deadlines, release dates, and internal editorial fields. FacetWP officially supports ACF Date Picker and Date Time Picker as data sources. But in a real project, choosing the correct field meaning matters just as much. For example, event_date and registration_deadline are both dates, but a "Next 7 Days" filter means very different things depending on which one you use. Do not call the facet simply "Date" if the user is really choosing "upcoming events" or "application deadline."

With Caching and Optimization

FacetWP updates results through JavaScript and REST/AJAX requests. Optimization plugins, HTML minification, deferred scripts, and external caching services can break automatic listing detection or script loading. The troubleshooting documentation mentions that HTML minification can remove the <!--fwp-loop--> HTML comment required for some template detection patterns. Caching can also interfere with JavaScript loading.

A practical testing order is this: first check Time Since on a test page with aggressive optimization disabled. Then turn optimization back on one layer at a time. If the issue appears only after minification or script delay, add an exclusion for FacetWP scripts or disable that specific setting on facet-heavy pages. Do not try to "fix" Time Since with code until caching has been ruled out.

With Multilingual Sites

FacetWP provides a Multilingual add-on for WPML and Polylang. The documentation covers support for standard translations and dynamic strings, but also warns about language settings for post types and taxonomies. For Time Since, this becomes especially noticeable when the choices are translated but the posts in the listing do not have language assignments, or some translations are not connected properly. After setting up multilingual behavior, run a re-index and test each language version separately.

If an English-language site still shows untranslated choices, fix that through the label settings, dynamic string translation, or facetwp_i18n. If the page returns the wrong records in another language, look for a broader cause: post language assignment, query behavior, shared slugs, the integration add-on, or the index. In that situation, Time Since may only be exposing the issue rather than causing it.

Best Time Since Settings for Different Page Types

There is no single set of Time Since choices that works equally well for news, events, jobs, and knowledge bases. The periods should match both the update rhythm and the decision the visitor is trying to make. If you use very short intervals on a slow-moving site, the filter will often be empty. If you use only long intervals on a fast-updating catalog, users will not be able to separate truly fresh posts from everything else.

Start with a content map. Look at how often new items appear, how long they stay relevant, which date determines the meaning of the page, and what other facets sit alongside it. Then choose no more than 3-5 main periods. A large list of choices rarely helps. It increases cognitive load and makes testing harder. Time Since is valuable precisely because it turns date into a simple decision.

News, Articles, and Editorial Content

For news, the publication date is usually what matters, so Data Source will most often be Post Date. A strong starting set is "Today," "Past 7 Days," "Past 30 Days," and "Past Year." If you publish heavily, you can add "Past 24 Hours," but do not treat it as the same as "Today" unless you understand the difference. "Today" depends on the site's calendar date, while "Past 24 Hours" is understood as a rolling window. They may look similar in the interface, but they are different promises to the user.

On a news site, Show ghosts is useful only if an empty "Today" option should remain visible. For example, the editorial team may want to show that fresh-content navigation is always available even if nothing has been published yet today. If empty choices only distract users, it is usually better to hide them.

Knowledge Bases and Documentation

For a knowledge base, Post Modified is often more useful, but it requires editorial discipline. If the team bulk-updates technical fields, every article can suddenly look "fresh." For serious documentation, it is often better to use a dedicated "review date" or "last meaningful content update" field. That is not a Time Since requirement as such, but a practical WordPress pattern: the editor stores a meaningful date in an ACF Date Picker field, and the facet filters by that value.

This is especially useful when the public-facing page needs to communicate trust. For example, "updated in the past 30 days" then means the article was actually reviewed, not merely resaved. The validation process stays the same: check a few control entries, run a re-index, select the period, and compare the listing against the expected set.

Events and Schedules

For events, a custom field is almost always the right source, because the event date is not the same as the post publication date. In Choices, you can use "Today," "Tomorrow," "Next 7 Days," "Future," and "Past." But in a past/future setup, do not forget that the base query must include the posts you want to filter. If the listing already hides past events, then a "Past" choice will be empty because of query logic, not because Time Since is broken.

Events often have both a start and an end date. Time Since works with a single selected date source. If you need range overlap logic such as "the event runs from Monday through Friday," you are better off looking at Date Range with two sources or a custom indexing approach. Time Since is simpler: it answers the question of where the selected date sits relative to the current moment.

Jobs, Classifieds, and Offers

For jobs and classified listings, freshness is critical, but the right date source depends on how the site is modeled. If the editor publishes a job once and never updates it, use Post Date. If employers renew or refresh listings, it is better to store a separate update date or deadline. In that case, Time Since helps visitors find active opportunities, but it should not replace actual publication status. An old listing with a future deadline and a new listing with no deadline are different situations, and a date filter alone cannot solve them without a sound data model.

Starter Choice Sets by Page Type

Page type	Date source	Example choices	Main validation point
News	Post Date	Today | today, Past 7 Days | -7 days, Past 30 Days | -30 days	Posts near the day boundary fall into the expected period based on the site timezone.
Knowledge base	Post Modified or an ACF review date	Past 30 Days | -30 days, Past Year | -1 year, custom "Older than 1 year".	Bulk technical edits do not make old articles look like meaningfully updated content.
Events	ACF Date Picker / Date Time Picker	Today | today, Tomorrow | tomorrow, Next 7 Days | +7 days	The base query includes posts with future event dates.
Jobs	Post Date or a refresh date	Past 24 Hours | -1 day, Past Week | -7 days, Past Month | -30 days	Closed or outdated jobs do not remain in the listing just because the date is recent.

This table is not a substitute for testing. It is a reasonable starting point that you can then refine against real data. If users often select a period and get nothing back, it is usually better to adjust the interval or enable Show ghosts with a clear interface behavior. If users do not interact with Time Since at all, the date may simply not be a primary decision factor on that page.

Editorial Support and Data Quality Control

Time Since depends on date quality. That sounds technical, but in practice it is an editorial issue. If the team does not understand which date controls the filter, they will break the behavior accidentally. One editor will update an article to fix a typo, another will change an event date after a reschedule, and a third will import old entries without filling in the custom field. The facet will still be working according to its rules, but users will see confusing output.

That is why it helps to prepare a short internal guide for editors before publishing the filter. It does not need to explain the whole FacetWP architecture. It only needs to clarify which field drives the filter, when it should be changed, which values are invalid, and how to verify the public-facing result. This is especially important for ACF fields because they may look like ordinary form fields even though they directly control the listing.

Mini Guide for the Team

• Which field controls the filter. For example: "Time Since on the events page uses the event_date field, not the post publication date."
• When to change the date. For example: "Only update the knowledge base review date after a meaningful content revision."
• What not to enter. Do not use text values, partial dates, or comments inside the date field.
• What to do after a bulk import. Check 5-10 records, run a re-index, and open the page on the public-facing site.
• Who to report odd results to. Assign an owner so the issue does not turn into random edits to the choices.

This kind of guide reduces false alarms. When a user says "the past week filter is not showing a post," the editor checks the date and post status first instead of immediately asking a developer to change code. That saves time and makes Time Since a more reliable part of the content workflow.

Test Posts as an Ongoing Control

On important projects, it is useful to keep several test posts in a private or internal category, if the site architecture allows it. One should fall into a short interval, another into a longer one, and a third should fall outside the chosen range. After changing choices, the date field, caching, the theme, or the page builder, you can quickly verify that the core behavior still works. If test posts are not suitable in the public catalog, use a site copy or staging environment instead.

Do not test against a single post. Time-based filters are sensitive to boundaries, so one successful example proves very little. It is better to validate at least three states: inside the range, outside the range, and right on the boundary. For events, include one past date and one future date. For a knowledge base, test an older entry after a technical resave so you can see whether Post Modified is replacing editorial meaning with technical noise.

Documenting Choices

If the choices feel obvious today, they may not be obvious a few months from now. Record somewhere in the task notes or project documentation why that specific set was chosen: "Past 7 Days = quick freshness snapshot," "Past 30 Days = primary working range," "Older than 1 year = archived materials." This does not need to appear in the public interface, but it helps the team avoid changing settings casually.

Be especially careful to document custom tokens. A string like over-1-year in Choices does nothing by itself without the PHP filter. If a future administrator removes the code snippet but leaves the choice in place, the filter will break. If they rename the token in settings but do not update it in PHP, the output will disappear as well. That is why a custom range must be treated as a linked pair: the choice string plus the snippet that handles the same format token.

Why Time Since May Not Work and How to Find the Cause

Troubleshooting should move from simple to complex. Time Since depends on core FacetWP, the listing, the index, the date source, JavaScript, and caching. If you start with PHP snippets right away, you can waste a lot of time and miss the fact that the facet is not even placed next to the correct listing.

The Facet Is Empty or Shows No Choices

Symptom: the facet block appears, but there are no choices, or only the empty label is visible.

Possible causes: Re-index was not run, the wrong Data Source was selected, the posts do not have dates in the expected field, the custom field stores the date in an unsupported format, the listing is not FacetWP-enabled, or the post type is excluded from search.

What to check: create a temporary simple facet for Post Type, run a re-index, and see whether values appear. If the simple facet works, go back to the date source. Open several posts, inspect the field, and resave one test post. With ACF, make sure you selected an ACF-aware source rather than a random technical meta key.

How to fix it: choose the correct date source, fill in or resave the data, and run Re-index. If the field is supposed to hold an event date, do not use Post Date just because it is always populated.

Selecting a Period Does Not Change the Listing

Symptom: the choices are visible, the user selects a period, the URL may change, but the listing stays the same.

Possible causes: FacetWP did not detect the correct query, the page contains multiple dynamic listings, the facet was placed inside a container that gets replaced, JavaScript did not run, or the REST/AJAX request is being blocked.

What to check: enable Debug Mode in FacetWP, then check the console and Network/XHR. If the response is not 200, the problem may be security-related, REST API-related, or a server-side error. If the response succeeds but the HTML does not refresh, inspect the listing markup and the placement of facetwp-template.

How to fix it: configure the correct listing template, move facets outside the replaced container, verify query detection, and temporarily disable JavaScript optimization. In a custom WP_Query, make sure the query is flagged for FacetWP wherever the documentation for that listing type requires it.

The "Today" or "Yesterday" Period Returns Unexpected Posts

Symptom: a post that an editor thinks belongs to today appears under yesterday, or the reverse.

Possible causes: the WordPress timezone differs from the editor's timezone, the event date was saved without the expected time component, the value sits on the day boundary, or the relative format is being interpreted differently than expected.

What to check: open Settings and General in WordPress and verify the site timezone. Compare the date and time on several test posts. For short intervals, create control posts near midnight in the site's timezone.

How to fix it: set the correct site timezone, refine the wording of your choices, and avoid overly ambiguous intervals if your audience spans multiple regions. For more complex international date behavior, you may need a more specialized date architecture rather than plain Time Since.

Future Events Do Not Appear

Symptom: choices for future periods exist, but future entries are not displayed.

Possible causes: Post Date is selected but the WordPress query does not include future posts; the event date is stored in a custom field, but Time Since is looking elsewhere; the initial query excludes future entries; or the post is not published.

What to check: determine whether the future event date is a publication date or a separate meta field. If it is an event, a custom field is usually the better choice. Check whether the post appears in the listing before Time Since is applied.

How to fix it: switch the data source to the event date field, make sure published posts are included in the base listing, then run a re-index. If you are using future post dates, configure the query itself to include them, but do that intentionally.

The Counts Look Wrong

Symptom: the numbers next to the choices do not match what the editor expects.

Possible causes: other facets are active, the choices are being recalculated against the current result set, the index is outdated, some posts have no date, Show ghosts is on or off, or the filter is based on a different date source than expected.

What to check: reset all filters, review the counts in a clean state, then enable additional facets one at a time. Compare the outcome against several known posts.

How to fix it: run a re-index, correct the date source, and explain to editors that FacetWP counts are contextual. If the numbers distract users, hide them with a CSS rule only after you have confirmed that the logic itself is correct.

The Facet Disappears After the First Selection

Symptom: Time Since is visible on initial page load, but disappears after a click.

Possible causes: the facet is placed inside an element that FacetWP replaces when the listing refreshes; the page builder rebuilds the DOM; or HTML minification altered the internal markup.

What to check: inspect the page structure before and after filtering. Facets should sit outside the replaceable results container. If you use a custom template, verify the facetwp-template class.

How to fix it: move the facets into a separate container, keep facetwp-template wrapped around the post loop, disable aggressive minification on pages that use FacetWP, or add exclusions for the necessary markup and scripts.

The Dropdown Looks Different Across Browsers

Symptom: the native Time Since select looks fine in one browser but clashes with the design in another.

Possible causes: the native select really does inherit different system styling across browsers. The Time Since documentation explicitly notes that it is difficult to style it identically everywhere.

What to check: test the main browsers and the mobile view. Compare Dropdown and fSelect.

How to fix it: apply light CSS to the select or switch to fSelect if it fits better with the rest of your facet set. Do not break accessibility just to force a perfectly uniform appearance.

Performance, SEO, and the Behavior of Filtered URLs

Time Since by itself should not become a heavy part of the site, because FacetWP relies on indexing and AJAX updates. But every facet participates in the broader filtering system, and the final speed depends on the number of posts, the complexity of the listing, hosting, caching, other facets, and how the queries are built. On large sites, you need to think not only about whether it works, but also about how quickly the user gets a usable result.

The Index and Large Content Sets

FacetWP stores facet data in a separate index table. That makes filtering faster than recalculating against the full content set every time, but it requires discipline: after changing fields, choices, or indexing behavior, you need to run a re-index. On large sites, a full re-index can take time. If you have a lot of content, plan facet changes during lower-traffic periods and avoid changing several core sources at once without testing.

If Time Since runs against a custom field, performance depends not only on the add-on itself but also on data quality. Empty or inconsistent values do not usually make the site slower so much as they create strange output and repeated troubleshooting. A well-maintained date field is both a content quality issue and a performance issue from a debugging standpoint.

Caching, REST, and Script Delay

Optimization plugins are useful, but pages with AJAX filtering need careful exclusions. If the wrong REST response is cached, if the FacetWP script is delayed, or if HTML minification removes the internal comment, Time Since may stop working along with other facets. After enabling caching, do not just test page load. Also test several filtering sequences in a row: choose a period, add a category, reset the filters, and refresh the page using a URL with query parameters.

From an SEO perspective, you should not turn every time-based selection into a separately indexable landing page without a clear strategy. FacetWP updates the URL, and those URLs can be useful for sharing or restoring state, but whether filtered combinations should be indexed depends on the broader SEO architecture of the site. Do not assume rankings will improve just because you added a "Past 30 Days" filter. User value and control over indexable pages matter more than the sheer number of URLs.

When to Add a Submit Button

FacetWP is often used as instant filtering by default: the user selects a facet and the listing updates immediately. On pages with heavy queries or many facets, the Submit Button add-on can make more sense so that the listing does not refresh after every single click. For Time Since, this is useful when the period is only one of several required search conditions. For example, the user chooses a content type, region, category, and period, then clicks "Show Results."

Do not add an apply button out of habit. On a small news listing, instant refresh is usually more convenient. On a large catalog with many filters, a button can make the behavior more predictable. Test it against real use cases: how many clicks the user makes, how quickly the listing updates, and whether it is clear that the changes have already been applied.

Questions to Resolve Before Publishing the Filter

Can I use FacetWP Time Since without the main FacetWP plugin?

No. Time Since is an add-on facet type. It adds a new facet type to FacetWP, but it does not replace the core plugin, the listing, the index, or the AJAX filtering system. Basic FacetWP must already be working before you configure it.

Why do "Past 7 Days" and "Past 30 Days" not appear after installation?

Those choices are not added automatically as a universal default set. The administrator must enter the lines manually in the Choices field using the label | format pattern. After that, save the facet and run Re-index.

Can I filter by an ACF event date?

Yes, as long as the field stores the date in a supported format and is selected as the correct ACF data source. FacetWP officially documents support for ACF Date Picker and Date Time Picker. But before launch, check real posts: the field must be filled in for the items that belong in the listing.

Which is better for a year-based archive: Time Since or another facet?

For a year-based archive, Time Since is usually not the right tool. It creates relative periods such as "past year," not fixed calendar choices. For years and months, it is better to use separate value indexing or a different facet type.

Why does "Today" depend on the timezone?

Time Since uses the WordPress timezone from the site's general settings. That means "today" is determined by the site time, not the editor's computer clock. Check Settings and General if boundary cases are landing in a different period than you expected.

Do I need to re-index FacetWP after every change to the choices?

After changing the facet, data source, custom range PHP behavior, or date values in posts, it is best to run Re-index. That clears outdated values from the equation and helps ensure you are looking at the current output.

Can I hide Time Since counts?

Yes. The official documentation shows both CSS and PHP approaches for hiding or customizing counts. The safest first step is CSS targeting [data-type="time_since"] .facetwp-counter if you only want to hide them visually rather than change the HTML itself.

Does Time Since automatically improve SEO?

It improves user navigation, but it does not guarantee SEO gains. Filtered URLs need to be handled within the site's broader SEO strategy: which combinations are indexable, which are blocked, how canonical is configured, and whether that page is actually useful to visitors.

When FacetWP Time Since Is the Right Choice

FacetWP Time Since is a strong option when the page already has, or is about to get, a FacetWP-powered listing and users need a quick way to narrow content by relative time. It is especially useful for fresh posts, updated documentation, upcoming events, job listings, and archive-style views such as "Older than 1 year." Its strength is the simplicity of the user choice and the fact that the administrator defines clear, meaningful periods in advance.

Before publishing, verify three things: the date source, the list of choices, and the output after a re-index. Then test the page on the public-facing site together with other facets, caching, and the mobile interface. If you need a calendar with an arbitrary range, look at Date Range. If you need a year-based archive, do not force Time Since to do another tool's job. If you need a simple, understandable freshness filter, you can get the FacetWP Time Since file and test it on a site copy with real dates.

The best sign of a successful setup is not just that a new facet type appears in the admin panel, but that the visitor gets a predictable experience: they choose a period, see the expected content, can reset the filter, share the URL, and do not run into disappearing choices or confusing dates. When that chain works, Time Since becomes a small but highly practical part of content navigation.