What Would you Like to See Next in Views?

   Amir

Announcements

October 13, 2013
57

Views 1.4 is just around the corner and we’re working on features for Views 1.5. This time, we thought it would be nice to ask you what you’d like to see next in Views.

First, a few words about what you can expect in Views 1.4, scheduled for the end of October.

  • Support for users
  • Slug display and editing
  • Better integration with WPML
  • More refined fields in the V menu
  • Little bug fixes

The users support is the major feature in Views 1.4. It will let you load and display users, together with their fields. Until Views 1.4, you could load only posts and taxonomy. Now, you’ll be able to load, filter and display also users. Thinking about a community site? Think Views 1.4.

Feature ideas for Views 1.5

But, that’s not the main reason for this post. We’re looking ahead into Views 1.5. There are a few features that we absolutely love, but we can’t do everything at the same time, so we’re asking you, to see what you need most.

The new features we’re thinking about are:

  • Support for many-to-many relationships
  • Dependent values in custom searches (like displaying relevant cities after selecting the country)
  • Better filters and hooks, so that I can add my stuff
  • Better debug output, so that I can understand what’s going on

Here are a few words about each of these candidates…

Many-to-many relationship

Today, Types allows to associate between parents and children. This creates what’s known as one-to-many. The parent is the ‘one’ and the children are many. Many to many relationship is a bit more complex, where each of the items on side A can be connected to different items on side B.

Dependent values in custom searches

Are you using the custom search feature in Views? If so, you might have wondered how to update the options in one field, when another field changes. For instance, if you want to display states and cities, you would probably want the cities field to show only cities that belong to the selected state.

Better filters and hooks

A View has different steps, starting with what to query, how to filter it, how to sort the results and how to display. If you want to further customize the View behavior, PHP filters might be handy. This would let you get 99% of the job done with Views and fill in the remaining 1% with your own PHP. Of course, using filters requires writing some PHP.

Better debug output

Ever built something with Views and wondered why it’s not happening right? Eventually, you surely managed to nail it, but we’re thinking that better debug output would be great. We’re planning to display a complete debug log, which shows the View query, filter, result set and iterations through the display.

Cast your votes

So now that you know what we’re planning to add, we’d like to hear your voice and learn what you need most.

Visit the Views 1.3 feedback survey and tell us.

I’m sure we’ll learn a thing or two from your feedback 🙂

 

Comments 57 Responses

  1. Many-to-many relationships and dependent values are definitely great features. The other two features might not appeal much to the regular user (though they’re helpful for devs).

    If I understand this correctly, many-to-many must be implemented in Types first before being incorporated into Views, correct?

    About dependent values, I have already had the need to create this in a recent project. I had a taxonomy select dropdown in my parametric search, and I wanted to populate a second dropdown with the children of the parent term that is selected in the first dropdown. So I assume this feature should support hierarchical taxonomies as well as custom fields.

    However, I also needed this to be present in CRED as well, because the site content is user-generated. So, the users submit the custom posts, and in the CRED form they should have the same functionality, that is, selecting one taxonomy term from the dropdown then the second dropdown would populate with child terms. I tried achieving it with conditional hide/show of fields, but it became overly complex and error-prone.

    So yeah, for Views v1.5 I’d like to see both many-to-many and dependent values 🙂

    Question about v1.4 feature “Slug display and editing”. What does this mean exactly?

    • Totally agree for real many-to-many (although good luck with that one for WP Core does not seemed design to support that properly…) and dependent values as priorities.

      • Many-to-many relationship will wait a bit. It’s on the radar for WordPress core and I think that it’s better for us to wait and see what gets added to WP and then add a nice GUI for it in Types. Views 1.6 will have a pretty amazing parametric search, with dependent values, support for post hierarchies and AJAX updates for results. Beta, next week.

        • Hi,
          Coming back to my favourite subject! The true many-to-many relationship.
          I’ve been surfing quite a while on WP core forums. And I am quite pessimistic to see this feature enter the core in a near future.
          My suggestion would be to position wp-types as the canonical plugin to manage many-to-many relationship in WP (started with p2p and zigconnect but not maintained and not very user oriented as you do guys especially with Views integration). Seriously I can pay an extra fee to see that happen!!
          My project is to develop a small but efficient, responsive, web-based Product Data Management (PDM) system which allows instant publication of the product on the woo store-page… Lean workflow, platform consistency and great UX (which could be nice for the PDM world is dreadful). BUT none of that is possible without a proper relational wp database management.
          Hope you might give me some good news. What about such a release for Christmas time, 10 months it’s not bad 😉

          • Many to many relationship for Types is certainly on our todo list and we will get there. It’s just that we cannot say exactly when. We’re looking for more talented developers, to join our team of 35 great people here. Want to try?

          • Would love to! Sadly I am no developer… I can understand more or less what’s happening, write detailed specifications from a project management point of view. But I cannot develop, that’s why I am using Toolset :))

    • Posts2Posts is a great plugin. If we can use it as the engine for many-to-many relationship, we will. At this stage, I’m not sure, but we’ll see. Like you know, the devil’s always in the details.

  3. I just want to bring up something I mentioned a while ago: https://toolset.com/2012/11/i-wish-types-could/comment-page-3/#comment-28627

    Here’s what I said:

    I would absolutely *love* to see some type of JSON output functionality with Types & Views.

    For example the ability to set up access a custom post type like so http://example.com/custom-post-type/postname?json that would output a JSON object with the content of that post. I currently use a method similar to this where I list out the Views and translate the markup into JSON so I can manipulate the output easier with JavaScript. It would be amazing if Types/Views would allow for something like that.

    So effectively raw output of views to another intermediary, like JSON for easy consumption by an external script (be that PHP, JavaScript, whatever)

    I think something like this would really open up views to be used in a more flexible manner for front-end heavy sites that want to retrieve data from views asynchronously.

    • This is why I think that filters would be good. There are a heap of excellent suggestions for what’s possible to do with Types and Views, but we cannot possibly add them all to the GUI. So, if we add filters to every step and make these filters easy to understand and use, I’m hoping that you will like to write tiny PHP that implements just this.

      For example, if you have a filter that receives the raw data, after query and filter, you can output your own JSON in just a few lines of PHP. I suspect that this solution will be more flexible and easier to use than a huge GUI.

      What do you think?

      • Hi Amir, yes you probably have to build it yourself for the tight integration you will want with Toolbox. What I mean is just take a look (but you already know it of course) at how the API is made. And maybe there’s something you find useful in there. As a developer I’ve enjoyed Posts2Posts API a lot. It is consistent, sane and straight forward.

      • If it’s possible to do that with filters and hooks then I’m all for that! Looking forward to seeing how I can use them to build cool things 🙂

      • Related post that never got answered, despite the developer promising to include some small hooks to allow this. 🙁

        • Right after this release, which is basically frozen for QA now, we are going to properly organize and document hooks in Views. The plan is to combine strong and useful hooks with clear debug. When you edit a View, you will get a debug screen, which shows you everything the View does, what it queries and what it gets back. Inline with that, the debug screen will list the filters that exist in every step, the values that they receive and how they alter the flow.

          I hope that this will make developing with Views a lot easier, without having to jump back and forth between your site and lengthy (and often outdated) documentation pages.

          This is one of the main planned activities for Views 1.5.

          Would that work for you?

  4. Many-to-many relationship!!!

    ASAP.

    It would be amazing to have great support for it soon.

    Any forecast?

    Peter

    • This looks pretty high on the priorities for everyone in the poll. I think that we’ll get to it right next.

        • Sorry, no news yet. Views 1.6, coming out very soon will include another major feature, which we’ve been working on for the last few weeks. I don’t yet have a good schedule for many-to-many posts configuration. It’s on our todo list, but not included in the upcoming version.

  6. As a brand new customer of Views I just realized I have no idea what 3/4 of this blog post means and I may have bitten off more than I can chew.

  7. Hi!

    Maybe not really to the topic -as I chose not to chose the above mentioned options, but I think this is crucial:

    The most neede feature is… optimization of database usage & speed.

    Now it’s quite heavy demanding the MySQL querries when you use more than one or even just one (but advanced) view template on the page. I really cannot express it much – this is crucial to make toolset less demanding on the database usage. I am not an experienced developer (still in training) so don’t know how to achieve this on my own.

    Have use toolset (types+views especially) on more than 20 sites now and over 10 server solutions – all of them are experiencing heavy database overloading and peaks RAM usage to often.

    Lukas

    • Certainly we are very interested in server resource utilization. The DB queries that Views produces depends directly on the website that’s built with it. If a page needs to pull in content from many objects in the database, it will cause queries.

      Having said this, today’s implementation for many-to-many relationship is not optimal. This is because Views doesn’t see through intermediary objects, so it needs to query them and then query the other side. Once we implement many-to-many queries directly in Views, this will drop significantly.

      • This is really important.

        Nested views is the worst performance killer.

        Say you have a view that lists “Content Type A”, and a nested view that shows “Content Type B” that is related to A.

        Now imagine the outer view returns 1000 posts. For every one of those posts, the nested loop will get the related posts.

        So you end up with:
        – Outer view: 1 query
        – Nested view: 1000 queries (one per result in Outer view)

        So, how to fix this? There are two ways the way I see it:

        1.)
        Make it possible to “preload” posts. So in our example we would preload all the possible results of the inner loop. This will use only one query, (so 2 in total), but there’s a lot of memory overhead if you have many posts.

        2.)
        Make it possible to specify relations in a View and run that use a JOIN query to fetch both the outer and inner view in the same query. Drupal Views does this, check it out.

        PS. I realize this last point is probably Views 2.0 material, not in the forseeable future, but please keep it in mind! 🙂

      • had i known the issue (explained pretty much here https://toolset.com/forums/topic/views-too-many-mysql-queries-killing-performance-and-load-times/) i would not have used wp-views. as it is now wp-views keeps my media temple VPS at 100% of resource usage constantly. i am sure it works great for the few-page sites that seem popular here but for my site (with 450+ directory entries and 3 types of interlinking child posts), it just kills it. i’m thinking of writing a scraper to get the resulting html and just going back to regular posts. i love the automation on my site with wp-views but it is grossly inefficient.

        • Difficult to tell without careful debug. Views isn’t “efficient” or “inefficient”. It runs the queries that you put into it. If one View loads another and another, you can easily end up with a lot of queries and CPU. It would happen the same no matter how you build the same site. I suggest to enable the debug mode and see what actually runs.

          BTW, in about 2 weeks, we’ll have a completely new debugger output for Views, which makes this work a lot easier. It will run in a browser window (not the console), display debug information hierarchically and show queries, CPU and memory. We’re already using it internally and I can tell you that it’s a great tool for understanding what designs actually do. Once you see the bottleneck, it’s almost trivial to understand what needs changing. I agree that without this debug information, sites can run slow and it’s difficult to tell why.

  8. Support for Advanced Custom Fields properties in views is essential.

    Types is a great plugin, but the features in ACF simply make it essential for much of advanced WordPress work – replacing the custom fields in Types almost entirely.

    I am sure Types will catch up, but until it does it is essential for Views to evolve.

    Ken

    • I also would like to see a tighter integration between Toolset and ACF. The two plugins would make a perfect marriage.

      I love the way Toolset is evolving thus far and can’t wait to see what future iterations will bring.

      Keep up the good work!

      • Yes, we want to do that too, but we need cooperation from Elliot, the author of ACF. Have you suggested this to him as well?

        • I agree with Darryl. I use ACF in all of my projects because of its state-of-the-art usability and wide range of resources (for ex., think of the Gallery field with drag-n-drop of multiple images). However, this is not always easy because of the lack of full compatibility between Toolset and ACF. My workaround so far has been using shortcodes (through Shortcode Developer plugin by Elliot) to render ACF fields properly in Views templates. It works but I wish Views could properly render any ACF fields without this approach.
          By the way, Elliot posted on his ACF blog his intentions for the upcoming ACF 5. He is rewriting the whole thing. He said: “I will be able to write the ACF core in such a way that it could be used to power 3rd party plugins which require custom field functionality”.
          So wouldn’t it be the right moment for this cooperation between You? Maybe this could open up a new partnership between You.

  9. It would be really great if Views can be used inside WP admin area. I often feel a need to create some views for internal use only (e.g. list of users registered for a certain event, or members with certain subscription level). Creating a View and attaching it to some admin menu would be the simplest solution to this problem. Yes I can create a page, put a view there, set access control, but actually because the view is for admin (and other authorized personnel) use only I feel it does not actually belong to pages which ideologically represent information that should be available to general public (at least to some extent).

  10. Hi there!

    Might be a little bit offtopic …

    You write that there are improvements regarding WPML integration in 1.4.

    I’m starting a new project at the moment and I want to use Types and WPML.
    Does it make sense to wait for 1.4 or can I just go ahead and update later?
    (Which I would prefer because I’m running out of time :-))

    Thanks for a short feedback!

    Cheers,
    Manuel

    • Types and WPML work well together already. All the improvements we made between the two plugins are related to editing and deleting repeating custom fields. We will be releasing Types 1.5 in about 2 weeks, but if you have issues right now with repeating custom fields, you can get a development version.

      • Hi Amir!

        Thanks for that superfast response!

        Great, then I will go ahead.
        I actually have repeating custom fields.
        So in case I have difficulties: how can I reach out to you for the dev-version?

        By the way:
        Is it better start with 1.4 (or 1.5) right away or is it no problem to update later?

        Manuel

  11. Dependent values in parametric searches

    Wow, now you are breaking new ground!

    Toolset Views has always been behind Drupal Views – this is the first feature I have seen that Drupal Views lacks, and it’s an awesome feature! Keep this stuff coming!

    • Oh and please add “Better filters and hooks”!

      I would love to develop my own custom fields that tie into Views (For example have custom Query Filter parameters.)

      Now that I think of it, I know there’s an example of how to make a Types custom field type, is there an example for integrating that custom field type into Views?

  12. Please make videos. For those of us who are not coders in php, and new to types and views, this can be confusing. I am starting to get it, but the child pages tutorial is completely confusing. It says to scroll down to body and leave it unchanged, but the graphic has no such entity.

  13. Any updates on when front end user registration for CREDS will be available?

    A bit off topic but it will go very very well with the ability for views to display user fields 🙂

    • It is taking a little longer than we had hoped for. In November, we are going to rework the fields output, throw away the Zebra forms library and make CRED output convenient to customize. It sounds like a small thing, but is actually a pretty big project. I think that the results will justify the effort.

      Then, we’re going to add users support to CRED. It’s coming up in Views 1.4, so we will have a strong foundation to build on.

    • This will take a while to add to Views, but we have good news. Simon, our applications specialist, is writing a comprehensive tutorial on how to display content with Views on Google maps. He is writing a small Javascript library, which you will be able to use on your projects. That library can be called from within any View, to plot results on Google maps. I’ve seen it working and it’s quite impressive.

  15. Views: Dependent values in parametric searches

    with possibility to define OR/AND condition between each fields instead of one rule for all fields.

    Thanks,
    Anton