Types and Views 0.9.5 – Post Relationship, Better Performance and Streamlined Interface

   Amir

Announcements

March 27, 2012
28

We’re excited to announce Types and Views 0.9.5. This version is the result of two months of intense development by the entire team and brings a host of new features, improvements and a few fixes.

As always, our goal is to let you build even richer sites with Types and Views and do it easier.

When we asked you about repeater fields, we received a huge amount of feedback, which helped us craft the new features for this release. After careful review, we concluded that field arrays for the ‘parent’ post don’t sit well with how Types and Views work. We dug in deeper and came up with our own architecture for implementing arrays of related information.

Many of the sample uses talked about examples such as artists who have shows, products that have benefits and other things that look awfully close to parent /child relationship between different posts.

a car rental website schema
Agreements, connecting people and cars

So, in order to build even stronger infrastructure, we decided to add a complete framework for parent /child relationship to both Types and Views. As before, Types defines the relationship and Views takes care of the display.

To achieve the same functionality as repeater fields, which belong to one post type, we’ve added a way to make one post type the parent of another AND to edit the child posts right from within the parent post editor. This provides the convenient editing for repeating information, but doesn’t sacrifice database integrity on the way.

Post relationship

With Types 0.9.5, when you edit a custom post type definition, you’ll see a new ‘post relationship’ section.

Post relationship box

Once you’ve made one post the child of another, you open a whole new set of possibilities.

  • You can edit child posts from within the parent editing (see Field Tables below).
  • When you edit a child post, you can indicate who it belongs to, using a parent drop-down.
  • When you display parent posts with a View, you can display the fields of the child posts.

There’s already a manual page about post relationship. It shows a simple example of a house that has rooms (but these rooms can also have furniture) and a more complex, but very realistic example, of a car-hire site.

When you define post relationship you allow one post to point to another. You can use this relationship to display fields that belong to the parents.

Field Tables

Now that you’ve defined relationships between posts, it’s time to put them to good use.

First, you’d probably like to add some custom fields to the child posts. Then, you’ll be able to edit the child posts and their custom fields, in a neat table, directly from the parent post.

a fields table with 5 rows of content - each content entry is a single room post type
Editing child items from the parent post

But wait, is this thing exactly like repeater fields?

Not really. There’s a whole lot more to editing child posts in a table.

A child post can belong to different parents. In our car-hire example, agreements belong to both a person and a car. When you edit a person, you’d like to see all the rental agreements that he has. When you edit a car, you should see all the renters that this car had or are scheduled to have.

The ‘rental agreement’ type may have many fields. Not all are relevant for different parents, so Types lets you choose which fields to display when editing different parents.

You should read more about bulk editing with Field Tables to see how it works and what you can achieve.

Displaying child contents (Field Tables)

So, we’ve added a way to define post relationship and to edit child posts from the parents. Now, we just need a nice way to display all this information.

Views 0.9.5 can query and filter posts according to their parents. When you create a new View and the post type you’re querying has parents, you can choose to filter by those parents.

Like with ordinary WordPress pages, you can filter by the current parent or the parent set by the View. I hope that this last sentence doesn’t confuse for too long. The meaning is that you can easily have nested Views, showing child fields. For example, if you’re showing houses, each house can have a child View for the rooms.

This manual page about displaying child items explains how to easily display them using either a View, or with the new PHP API in Types 0.9.5.

Performance

It’s always fun to optimize our code and make it run faster. It’s especially fun when we ourselves depend on it for our production server on both wp-types.com and wpml.org.

This release sees a big performance boost in two places:

  • In the WordPress admin, we’re doing far fewer SQL queries in the post-edit and in Types setup pages.
  • AJAX page loads are now running without calling wp-admin and are cache-able. Just for figures, on our own 8-core dedicated server, this brings it down from 2.5 seconds to less than 0.1 second. If you’re using AJAX updates in your Views, you’re going to feel the improvement immediately.

Streamlined interface

Between all the shiny new features, performance improvements and bug fixes, this is actually my favorite new thing in Types and Views 0.9.5.

I’m acting as our webmaster. This means that I create new Views and Content Templates. I have a few other daily tasks, so I really like it when my webmaster role takes as little time as possible (and I can run the business).

Until this release, the field-insert popup dialog (which you get when you click on ‘insert field’ or the V icons) was a little cluttered. It could be a lot cluttered if you have lots of custom fields in the site (like we do).

To me, this was a big problem. I know what I want to insert, but I had to spend 3 minutes just finding it on the screen.

Only relevant fields show in popups

Views now does its best to eliminate options and show you only relevant fields. When you create a View, it knows exactly which content types you’re using. For Content Templates, it shows everything, but much more orderly.

Then, there’s that little search box. Try it by typing anything. You’ll see the fields list immediately adjust and irrelevant fields drop away. After entering just a couple of characters, you’ll immediately see the field you want to insert.

Stability

Since we had ample time to develop and review this release, we feel that it’s the most stable release to-date. It’s the first time that we managed to pass Types and Views through our complete QA cycle. This helped reveal numerous bugs, ranging from tiny wording issues to PHP bugs.

Types and Views 0.9.5 are already powering our own sites and we’re very happy with how it works for us.

Bug fixes

Most bugs were difficult to get to, and are even more difficult to explain. However, there are a couple of things that stand out:

  • WPML integration – now that wp-types.com is turning multilingual, we noticed a few places where Views was pulling items in the wrong language from the database.
  • Fields not rendering – this is somewhere in the middle between Types and WordPress core. Since we can’t control WordPress, we fixed it all on our side. Types will now insert fields that are 100% compatible with how WordPress parses shortcodes, eliminating the possibility of fields not being displayed.

Getting Types and Views 0.9.5

You can download Types 0.9.5 from the WordPress download page or from your wp-types account. Views 0.9.5 is only available to Views clients. Please login to your wp-types.com account and click on Downloads.

We’ve done a ton of testing on these versions and they are already powering our sites. However, it’s a major update, so before updating live sites, please please backup your database.

What Next

Version 0.9.5 is the last one in Views beta. We’ll be moving to the first non-beta release next week, calling it Types and Views 1.0. During this time, our mission is to clean any problem, warning, notice or glitch that anyone sees and to complete other tiny issues that we left out from this release.

After 1.0, we’ll be back to adding more features.

 

Comments 28 Responses

  1. This looks awesome! Need to try it right away. I was waiting for this update and you are just in time before I finished a project where I wanted to use the repeatable fields capability.

  3. This looks fantastic—but one thing isn’t clear to me, though it’s alluded to, and I’ve read through all the documentation. You mention it’s possible to attach a child to multiple parents, but the UI seems to show a single drop down to pick the parent.

    Here’s a use-case:
    You have list of people (each one being a CPT record of “employee”), and a CPT of “Offices”. Employees may be a child of one or more offices. How is this done through the new UI? Say I’m in the post for ‘Office1″. I create Employee A in Office 1’s field table. I then want to add Employee A to Office 2.

    Currently I do this connection via taxonomies— the employee would have the taxes “office1, office2”, e.g. Is this a setup that could be modified to work in the new Types system, or would it require a fundamental rebuild of the relationships?

    Thanks,
    Steve

    • The employee can be the child of only one office. You can make the employee type child of other post types, but of each type – one parent. It’s illustrated in the ‘car hire’ example above. A contract is child of both person and car.

      In your case, if you want to have many-to-many relationship between offices and employees, the solution would be to use an intermediate item in the middle. This would be exactly like the contract in our car hire example. I think that I better write a detailed tutorial about how many-to-many relationships work and what they’re good for.

      • This new Parent-Child relationship is great!

        I am going to buy Views only to support the development of Types! Or can I donate to Types development directly?

        This one-to-many relationship limits the given library example, as it seems to me that the relationship Parent-Child given by Author-Book is not complete, as many authors may write a single book. (oh! And many books may be written by the same author!) 🙂

        • I’m very happy to see that you like it. We put a whole lot of energy into this design!

          If you buy Views, you’ll be supporting the entire project AND getting a tool, which I’m sure you’ll enjoy. One-to-many relationship is the basis for many-to-many. Look at the car-hire example in this post. You’ll notice that the ‘agreement’ types actually connect between people and cars forming the many-to-many relationship that you’re looking for.

          We’re working on creating a complete reference design based on this and I’ll write a detailed tutorial and blog post as soon as it’s done.

          • Thanks, now I see how the intermediate post type can be used to create a many-to-many relationship.

            I have already bought Views.

            I will try to use an intermediate relationship, and if in the future you can provide a straightforward solution to a many-to-many relationship between post types I will be even happier!

            I will be following your blog post and tutorials 🙂

            Thanks again!

  4. Terrific additions and improvements, Amir! Really cool.

    Thanks for not only adding extremely helpful features, but also optimizing code for performance and improving the user interface.

    It’s quite common for us to see/use WP plugins that add features, but only improve code when fixing bugs.

    I’m curious: was there any sort of trade-off or compromise you needed to make with the two major optimizations, or was it all flat improvement?

    Cheers!

    • I’m very happy to see that you like the new stuff in Types and Views.

      When we started on this release, some 8 weeks ago, we first identified the key major features, being post relationship, child-item editing and usability. Then, we built the rest around that.

      And since we use Types and Views ourselves, bug fixes always come first. It’s pretty difficult to use all these great features if they sometimes work and sometimes don’t 🙂

  5. Can the Parent type of post be the default WordPress post type? I’ve added T&V to an existing site, by using categories to match custom posts to existing posts. (I don’t know the term for a non-custom post)

    • Yup. When you edit a type, go to the bottom of the screen. You’ll see buttons to choose parents and children. The standard ‘post’ and ‘page’ are there. Categories are taxonomy. This only works between posts and not taxonomy.

  6. Okay, now I’m confused. Your implementation of repeatable custom fields is far removed from Easy Custom Content Types or Advanced Custom Fields.

    In affect, I can only repeat child posts, not fields? So for an arbitory text field I need to repeat, I have to create a new container post for that field just to be able to repeat it?

    I’m sure for more complex needs this makes sense, but if you only need to repeat a single text field, this seems overkill. Every time I repeat this “field”, I actually create a new post? My database is going to fill up quick with posts that contain a single one-word text entry. I’ve got to say, not the elequent, user friendly, performant solution I had come to expect from you guys 🙁

    • That’s right. You should create the container child post and that post will have fields. You’re correct. It takes more clicks to set this up than just insert a field and say it’s repeatable.

      However, there are some major benefits here. When you start with a very basic architecture, you get the trivial things done easily and then more complex things become a big mess. When you start with a solid architecture, everything has the same complexity.

      We figured that it’s better to ask people to click 3 more times for the simple things but also be able to do the complex stuff without sweating. I think that it’s better than doing the simple things really trivially, but then getting completely stuck when power runs out. Would you prefer to work with 2 custom field plugins, using one for some projects and another for others, or choose the more advanced solution for all cases?

      • Fair enough, I guess you have to look at the big picture when developing for everyone!

        I’m just a little concerned how these trivial ‘child posts’ are going to effect things like search results / admin pages / caching. I guess once I’ve created / tested a few, it’ll become more clear to my tiny shinny mind 🙂

        I better starting reading the user doc’s (boggleboggleboggle)

        • OK, I’ve had a good play with 0.9.5 and will definitely have to look else where for repeatable fields. This plugin, as it stands, should not be used for creating what the vast majority of WP users would consider to be repeating fields. Not even close.

          That said, the whole ‘editing child posts from within the parent post’ is definitely clever. For creating / managing advanced post relationships, ‘Types’ is unrivalled. For that I can only tip my hat in respect. In fact, for everything other than repeating arbitrary fields / field groups, ‘Types’ is way ahead of its rivals.

          Lets hope I can get one of the other custom field plugins to play nice with it (Easy Repeatable Input Fields, Custom Fields Creator, Simple Fields, Custom Field Suite and Advanced Custom Fields all offer repeatable fields, so fingers x’d)

          • Totally agree.

            That solution is fantastic for complex sites. I definitely try to make use of it’s potential. But in most cases it’s just too much. First thing I thought when it appeared, was WOW! Then I started to look around for another plugin with repeater fields.

            • That’s fair. I’m sure that there’s a best solution for every case and if you’re happier with something else, that’s great.

            • Amir,

              I think’s Types is a fantastic, complete tool for content construction. Your solution for repeater fields is a new, very creative approach – I haven’t seen anything like that in WordPress before.

              Problem with your idea is technical – if I need a simple repeater field (for eg. title, description and file attachment) which is 90% of all usecases I have to create post type for it, to be a container for the data. If I build sites based on static pages and in many other cases, I just don’t need and wan’t to involve another post types. Avoiding that is one of the most advantages of repeating fileds as we know them from other plugins.

              Now, I believe that with some extra work Types could combine both approaches and I hope you’ll seriously look into that possibilty in the future.

            • We could automate creating the container posts, but does this really make sense? This means adding a bunch of PHP, which gets loaded into memory. All that PHP does, besides inviting bugs, it save a few clicks. Then, after we add it, I’m pretty sure that requests will start flowing in about how we should make the GUI more and more complex to support everything.

              So instead, I think that it’s better for Types to keep this separate. You’re right. In many cases, a single repeater field does the trick. But what do you do with those remaining 10%? Do you prefer getting a very streamlined solution for 90% of the cases but burn days trying to go around the limitations for those remaining 10%?

            • You’re right – automatisation of post type creation (a container for repeater) doesn’t make any sense.

              But it’s not the point I think. Let me give you a real-life example – a real estate site built for a client. I need to built a property post type and custom fields for all the data. Location, title, description, price and many others – it can be done easily. Now I think of some fields to be flexible for a client – he needs to add:
              1. property images (1 or more)
              2. contact phone number (1 or more)
              3. property owners (1 or more)
              4. floorplans in pdf (in 1 or more file)
              5. etc…
              It must be flexible as each property will be different, will be repeating or not. Now if I use Types, for each of those I’d have to create separate post types, and that is pointless – post metadata is perfect for that, as those will be unique, small pieces of data.

              I think about that 10% – 90% issue. Problem is that you did a great job but at the same time kicked yourself in the foot (at least when it comes to future popularity of Types and sale potential of Views).

              Maybe you should think of something like repeater filelds mode: 1) based on custom post types (just like you did now) and 2) based on post metadata (like in ACF and others). Then user could define (maybe right after Types activation) in which mode he wants to work – as combining both might be difficult I guess. That would be the ideal 100%.

              One more thought: the power of Types is it’s completeness – it seamlessly handles post types, taxonomies and custom fields (not mentioning WPML support). But repeater for custom fields is a standard now (just like file upload field), getting more and more sophisticated – WP users already know it’s potential and use extensively – I guess it was the last argument thay needed to give up other plugins. But things just got complicated.

  7. Hi,

    One thing annoying that makes Types unusable for me (at least without hacking the source) is that you are not allowing “special cars” for custom URL.
    When using some rewriting rule (in order to include some taxonomy as part of the URL), you will end up with some URL like this one: /products/%prod-tax%/features/ … which can’t be done with types.

    Agree 100% with Bartosz regarding Post Type relationships. Your approach may have its use at times but is way too cumbersome for most cases. Handling many post types is not really cheap and can get really messy on a UI StandPoint.
    If you ask me, repeating with multiple custom fields or even serializing into one custom field is the way to go in most cases.

    IMO, you should keep your post/relationship feature and add a repeating feature that will be much lighter and not involve post type creation.

    • I’m not sure that I understand the comment about special cars (char?). If you could give me an example of what you’re trying to do, how you’re doing it with WordPress API and how it’s not possible with Types, we can see what to fix. Generally speaking, Types just calls the WordPress API functions when it registers custom post and taxonomy, so it can’t be all that difficult to fix.

      We’re adding simple array fields to Types and Views 1.0. Bartosz and others have been kind to explain to us here what they’re trying to achieve with this, and we understand that child posts are overly complicated for this. There are great uses for a complete posts hierarchy and also for simple repeating fields. I hope to have this ready in about 2 weeks.

      These array fields will store values in multiple postmeta keys and not in a single serialized key. If we store them as serialized keys, it will make it impossible (or at least, highly inefficient) to query and filter posts according to these field values.

      • Hi,
        Sorry for the confusion. As you could guess, English is not my native language. I’ll try to clarify:

        When you create a post type, and *use a custom URL format* (in the advanced section), your plugin won’t allow to enter special characters in the text box (slug to prepend). If I try to enter the following “/products/%en-product%/features”, I’ll receive the following validation error message: “No special characters please”.

        The validation method (rewriteslug) is located in “additional-methods.min.js”. The activation of this validation rule is located line 381 in custom-types-form.php.
        I could workaround this limitation by commenting out this line.

        Using variables in a custom post type slug is not an uncommon scenario. If you would like to keep some validation, you could update your regex in order to allow for “%”.

        Hopefully, it makes sense this time.

        By the way, +1 for implementing the following option: *Allow permalinks to be prepended with front base* (“with_front” attribute). For some reasons, most of the plugins completely overlook this option (which make them useless if you are using custom URL and are also prepending blog posts with some slug in the Permalink settings).

        Serialized vs Multiple keys have pros and cons in my mind. You are completely right to say that it would make things difficult and inefficient for querying and filtering but for the cases when repeating fields are not involved in queries of filters (which is certainly often the cases – querying or filtering on repeating fields is not trivial anyway), serializing is certainly more efficient both on storage and access standpoint. That said, I’m not a WordPress expert and you may prove me wrong here.

        I can’t wait for the addition of repeating group of fields. I plan to use WPML soon and, obviously, would prefer having types/fields/taxonomies handled by your plugin instead of assembling various plugins.

        One thing that seems important to me is when editing a post with repeating fields, it should be possible to reorder the group of fields.

        • Thank you for the detailed explanation. I’ve added it to our todo list. Srdjan will review it and reply here. I would like him to send you a beta version, so that you can review and see that we’re not missing anything. We have your email and it’s included in our ticket description.

          • The ability to input “%” chars in a custom post type slug is an easy one. I can’t imagine you could miss anything here.

            However, I am clearly interested in accessing beta versions while you are progressing on repeating group of fields.

  8. I had a look around the update and I have to agree with Bartosz, this was way too complicated solution. Hope you can make something simpler, giving the opportunity to just collect custom fields into repeatable groups.
    Otherwise, I really appreciate the work done with the plugin so far, and hope to use the new connections and field tables in future!