Views 1.8.1 – Bug Fixes and Improvements

   Amir

Announcements

April 29, 2015
3

Views 1.8.1 is a bugfix release. We will walk over the most relevant bugs that have been fixed in this small dev cycle.

Fixed an inconsistency on query filters getting values from shortcode attributes – empty values should apply no filter

Several query filters have an option to use a shortcode attribute to get the value to filter by. For example, when filtering by post author, there is an option to pass the author we want to get using a shortcode attribute.

Until now, we had inconsistent behavior when this shortcode attribute was passed an empty value. From now on, we have consistency: an empty value will produce no results.

See screenshots for an example.

Filter by author ID
Filter by author ID

Now, this shortcode will not apply any filter by post author:

{{wpv-view name=”My View” author=””}}

Fixed the export workflow – some setting were not exported

In the last update, we revamped the export/import codebase. While doing so, we introduced a bug that broke the export, so some Views settings were not exported as they should.

Fixed an issue about old Views which do not have a “view-query-mode” setting that can not be edited

It was not possible to edit some older Views, because fields that we added to Views didn’t exist in older Views. This version fixes the problem by updating all existing Views to have all necessary information.

Reported in the forum in this thread and this thread.

Fixed a bug about removing inline Content Templates from a View

When deleting an inline Content Template from a View, there was a javascript error and the Content Template was not removed from the page until a refresh was done. This has been fixed.

Removing CT from a View
Removing CT from a View

Fixed a bug about “lower than” options on the query filters by custom field, usermeta field and post date

The latest sanitization review went a little too far and we also tried to sanitize lower than < and lower than or equal <= comparison functions. As the lower than sign is the same as the HTML tag opener, the sanitization method we used transformed it into its HTML entities.

This means that the lower than comparison got broken for custom field, usermeta fields and post date filters. The stored data got corrupted. We have fixed that. In case some other user reports this error, please advice them to edit the filter and save it again after updating to Views 1.8.1.

Related ticket

Fixed the frameworks integration – frameworks using an option to store values were not registered correctly

The frameworks integration provides two modes: frameworks that have a proper function to get values and frameworks that store their values on a native option in WordPress.

The latter implementation had a bug when recovering the values. It has been fixed now.

Fixed an issue about Content Templates saved without slug
There was a problem on some cases when saving a Content Template without a slug.

It only happened when clicking the “Add new” button when editing another Content Template, because when creating it we need to check whether its title or slug has already been used, and in this case those fields have no value.

In addition to improve that check, we have removed the “Add new” button from the Content Template edit screen.

Fixed an issue that avoided changing the WordPress Archive assigned to an archive loop from the admin listing page

When clicking on the “Change WordPress Archive” link on the admin listing screen for WordPress Archives arranged by usage, there was a bug that prevented the dialog from being shown. This has been fixed now.

Change WordPress Archive
Change WordPress Archive

Download and upgrade

If you registered Toolset in your site, you will receive this update automatically. You can always visit your wp-types.com account, click on Downloads and get the recent version of Views.

Questions? Ideas? Suggestions? Leave your comments and we will reply.

 

Comments 3 Responses

  1. Hi Amir,

    I have a wish for Views. I would like to filter on Sticky posts. Can you add this in the new version? Thanks in advance!

    • Looks like a sensible request. We are adding a number of new filters to Views 1.10. I’ll see if this can go in or not. We are close to starting QA, so there’s a chance we cannot add this feature now, but to a next release.

    • Hey Dido

      This is Juan, Views lead developer. This seems like an interesting feature to add, but I would like to get more details on what you expect from this. You know that the native nature of sticky posts is that they are returned first, which raises some questions when you combine that with some other filters.

      I assume that you just want an easy thing 🙂 Do you mean that you would like to be able to apply, among other filters, one new filter that ensures that all the returned posts are sticky posts? If so, this may come to the next version 🙂

      Regards