Termmeta support in Views
WordPress 4.4 introduced core support for termmeta. Views 1.12 provides support for termmeta as well.
Added termmeta query filters to Views listing terms
When working with a View that lists taxonomy terms, you can now add query filters using termmeta, in case your site has some.
Termmeta query filters share the same GUI with postmeta and usermeta, so they may already seem familiar to anyone who has used them before.
Those termmeta filters are applied on the frontend. Views 1.12 also provides support for Types termmeta fields, which are yet to be released, so Views 1.12 will be fully compatible with Types termmeta fields once the feature is rolled out.
Termmeta support in the Fields and Views popup and in the Loop Wizard
Since Views is a rendering engine, it required a way to display termmeta values.
When working with a View that lists taxonomy terms, on the Fields and Views popup a new entry is included for the new {{wpv-taxonomy-field}} shortcode:
Then, the usual dialog is opened to set the shortcode attributes. The attributes are the same as for the {{wpv-post-field}} shortcode, with autocomplete for the field name (which provides suggestions as you type), for example:
In addition, Views provides early support for the upcoming Types termmeta fields, although only when editing a View that lists taxonomy terms as yet. There is support for the Fields and Views popup (providing groups for Types termmeta groups, similar to postmeta and usermeta, which produce a Types shortcode):
In addition, there is support for Types termmeta in the Loop Wizard for those types of Views:
As with any other Types meta field (postmeta or usermeta), you will be able to edit the Types shortcode attributes from the wizard itself.
New shortcode generator in the admin bar
Views 1.12 makes it much easier to display Views inside page builders. When you use a page builder, you probably wish you’d had the Fields and Views button, to insert your Views into the page-builder designs. Now, you can achieve this easily.
The way to use it is:
- Edit any page that uses a ‘page builder’
- Create a cell that accepts shortcodes (like a text cell)
- Click on the Toolset shortcodes menu in the admin bar and select Fields and Views
- Select the field or View that you want to insert
- Copy the shortcode and paste it into the page builder cell
By default this is turned off, but you can enable it on the Views Settings page:
There are three possible options:
- Disable
- Enable just on edit pages, which include posts, pages, custom post types, taxonomy terms, users (own profile, edit and create user), Views, Content Templates and WordPress Archives.
- Enable in any admin backend page.
Note that Layouts theme integrations, when installed, have the ability to set this option to enabled on editors if this setting has not been edited. Once it is saved, Layouts integrations can not override it.
When enabled, this setting generates a new menu in the admin bar:
By now, this new menu contains the Fields and Views entry. When clicked, the usual dialog is opened:
There is one important thing to notice here: this dialog is finally a real one, instead of a container that is displayed below the Fields and Views button. This also applies to the same button located over post editors.
When selecting an item, the usual Views dialog to adjust the shortcode attributes will be open. Note that the button to insert the shortcode now is labeled Create shortcode:
Once you click the Create shortcode, instead of inserting the resulting shortcode into an editor (remember that the current admin page might not have any), we generate a secondary dialog that contains the output:
On a future review, we will add a way to copy the resulting shortcode to the clipboard. We did not do it for now because we did not find a good solution that works on all browsers on all operating systems.
Note that when dealing with Views, changing the Content selection target of the View will also adjust which dialog is shown here.
Create a page for a View when creating or editing it
Many times, you want to create a page that ‘just displays a View’ and nothing else. Views 1.12 makes it easier by offering you to create a page that includes this View.
Note that this button is on the top bar of the View edit page, so it is always visible as you scroll.
Improvements
Better AJAX pagination management
Views 1.11 added a very nice feature to Views that have manual AJAX pagination enabled: browser history management. With it, paginating a View and clicking the Back button in the browser returned the interface to the previous View page. We disabled this feature automatically for sliders, and for Views using infinite scrolling.
Most of our clients loved it, but some of them requested for a way to disable this feature. To ensure backwards compatibility, we added two new things.
First, there is a new global setting in Views for controlling the history management feature, in the Views > Settings page:
Disabling it here disables the history management feature site wide.
In some cases, you might want to keep the feature but disable it on some specific Views. To do so, there is a new setting in the Pagination section of the View, under Advanced options for AJAX pagination:
Note that this setting is enabled by default, and that it will not appear when the pagination effect is infinite scrolling (as the feature does not apply there).
As a final note, there were two extra changes related to AJAX pagination and browser history management:
- The feature gets disabled on inner Views when using a nested structure. For example, if a View lists categories and it contains a View that lists posts that belong to each category, and both Views have AJAX pagination, the inner View will not generate history events by design. This helped address some undesirable behavior.
- There was a problem with some Views sliders which got this history management feature enabled. We reviewed the logic to ensure that this does not happen henceforth.
Better parametric search filter by post relationships
Thus far, when using a post relationship filter in a parametric search, selecting one ancestor limited the descendants that were offered in lower levels.
For example, say that you have a Types post relationship for post types like Continent > Country > City, and you have a View listing cities, filtered by continents and countries. As yet, there was no restriction on which continents were shown first, and only by trial and error were you able to avoid selecting an option that produced no results.
Henceforth, post relationship filters also check options that produce results upstream. This means that if you have a continent Africa but none of your cities belong to a country that belongs to Africa, then that continent will not be shown as an option under the parametric search filter.
Display the last modified date for a post
We extended the {{wpv-post-date}} shortcode with a new attribute type that provides an option to display the date when the current post was last modified:
Frontend links to Views in current page
The Design with Toolset admin bar entry was improved, such that it links to edit the Views contained in the current page when visiting it on the frontend:
New modes on the filter by taxonomy term
When listing taxonomy terms using a View, you can add a query filter by specific taxonomy terms. That filter had two options: get terms set by the current post, or get only the ones that I will select.
That query filter got two new modes: get terms with term ID set by a shortcode attribute, or by an URL parameter:
Those modes work like any other similar mode for other query filters.
Other improvements
- Added a shortcut, Ctrl+S, to save sections containing editors in Content Template edit screens.
- Improved the Views output by removing one hidden input no longer needed.
- Improved all AJAX-related functionality by using a specific ajaxurl variable based on the native one provided by WordPress.
- Improved the internals used to duplicate all the Views objects.
- Improved the internals used on the Views Settings page.
- Improved the compatibility of the Fields and Views dialog with Layouts and Visual Composer.
- Performed a security review on generic POSTed data on several AJAX calls.
Bug fixes
- Fixed a compatibility issue between Views parametric search and server object caching.
- Fixed an issue on Views frontend cache related to Content Templates with custom CSS used inside a View.
- Fixed an issue on Views AJAX pagination on Views loaded via AJAX events, as in nested structures.
- Fixed an issue on slow responsive Views output and debounce tolerance.
- Fixed a problem in Views conditionals for when one of the compared values is a number and the other is a string.
- Fixed a compatibility issue with third party plugins that register 404 events.
- Fixed a compatibility issue with Masonry-based themes, related to a forced Views output width set on a resize event.