Types and Views 1.0 Features Preview

   Amir

April 10, 2012

Types and Views 1.0 are scheduled for about 3 weeks from now and we’d love to hear your opinion about upcoming features.

Classic Repeater Fields

This time, you’re getting what you asked for, without any innovations or smart excuses.

I’d like to use this opportunity to thank Steve, Bob, Bartosz and Frederic who took the time to carefully explain what they would do with simple repeating fields.

We’re making every field kind in Types repeatable (perhaps with the exception of WYSIWYG fields). When you edit a custom fields group, you’ll be able indicate which field can appear multiple times in content editors.

Repeating fields in group setup

If you allow a field to repeat (“this field can appear multiple times when editing”), you’ll have button to add more and delete.

Repeating fields when editing content

Types saves these fields as independent postmeta entries. This means that when you click on ‘add another’, Types will create a new custom field, with the exact same name and add it to the post.

As a result, these fields cannot be ordered in the post editor. We’ve debated about this, going back and forth between using independent fields with the same key and a serialized array with all fields in it. Eventually, we selected to use multiple fields, as this seems to be fit best with WordPress and will be compatible with anything else that you can use. It also allows filtering by field values, which we think is a pretty big deal.

When you load the custom fields, you’ll get an array, which you can sort in the PHP (or Views will do it for you).

In the future, we might consider adding a second option for storing these custom fields as one serialized array, but it’s not implemented right now.

Grouping repeating fields

When you have groups of repeating fields, we think that container objects are suitable.

Let’s compare between two cases, where you might use repeating fields:

  1. Multiple email contacts for a vehicle
  2. Different engine attributes for a vehicle

The first example would be best implemented using the new repeating fields that we’re now adding to Types and Views 1.0.

The second example should use child posts. Yes, it’s technically possible to add them by grouping repeating custom fields and attaching them to the ‘vehicle’ post – but does this really make sense? If the group represents an ‘engine’, why not put all these fields under Engine and have Engines as children of Vehicle?

Time Filtering

The second major new feature in this release is time-filters in Views. Until now, filter items according to time was pretty difficult (hackish). This made things like event managers difficult to build with Views.

Views 1.0 will let you filter time and date fields in a natural way. You’ll be able create filters relative to the current time or a fixed date. For example, if you want to load all events for today, or all events in the next week, that’s going to be trivial to do.

Feeding arguments to Views

The last big thing that we’re including in this release is a way to control Views query using URL arguments.

Supposing you’re doing a listing site and you have items in different categories, or with different attributes (custom fields). Wouldn’t it be nice if visitors could see a drop-down with price ranges, select one and the View on the homepage would update to show just the relevant items?

Want to add filtering to Classifieds sites?

Views 1.0 will let you easily output HTML for View filters. For instance, you’ll be able to create drop-down lists with price ranges, check-boxes for colors or whatever you use to organize content.

The View will get that selection and use the values as filter arguments. This feature is still very much under construction. I’ll have detailed instructions and screenshots to share as we approach the first beta.

Finally, Types and Views localized

Types and Views 1.0 will ship with translation to Spanish, French, Chinese, Italian, Dutch, Russian and possibly  other languages. We fixed a few bugs related to loading .mo files and localization now works correctly.

If you need translation to any of these languages, you’re all set. If you’re translating to another language, this time, the .mo files that you create will load. Amazing, isn’t it 😉

Beyond Version 1.0

After this 1.0 release, we’ll be looking at better integration with search plugins (to make it easy to search through custom fields), View support for the standard WordPress index, taxonomy and archive pages and lots of other goodies.

Feedback?

What do you think about these features? We’d love to get your feedback!

 

Comments 93 Responses

    • You’re absolutely right. We’re working on a series of ‘getting started’ tutorials. These will start gradually and slowly work through all the functionality of the plugins.

      • Please keep/create reference documentation updated as the tutorials are created. The full access to details in reference documentation is helpful for finding all the capabilities, as well as for potential customers to learn that features exist. Investing time in tutorials requires knowing that desired capabilities are in both the plugins and explained in the tutorials. (Also consider including cross-links in both doc and tutorials so the relevant sections are easy to find from each.)

  1. Hi guys,

    Well done, repeater fields seems nice to have.
    My feeling is Types+Views is quite well featured for a launch, I would just ask for more testing and stability.

    1. I noticed a permission issue (I opened a ticket for that but see no response)
    2. When you modify a custom post type / taxonomy slug after you create it, I had some problems as it seems all references to that slug were not updated in the serialized config options.
    3. As a French, I’m using non ASCII characters and this causes some (minor) issues, as for example, you cannot create a content type with non ASCII chars in their name.

    So basically, great job on Types, gite some more stability so that we can use it with no fear on production websites.

    Cheers,
    Julien

  2. Just a clarification re:permission issue :
    With the latest features of post relationships, it seems a role of Editor cannot assign a parent from a child. It was working for me logged in as Administrator but my client couldn’t update his post associations when he was logged in as an Editor.

    Thanks

    • Permission management is on our todo list as well. No matter how we hard-code permissions, there will always be a good case when different roles are required. Types needs to work with access management plugins to let you choose who can do what. I hope we’ll have it in Types 1.1.

  3. Repeater Fields will be cool. I hadn’t even given them a thought, but now I want to use them!

    How about an archive manager, where you could control how every term listing is displayed, including ‘before’ and ‘after’ content. (ex: “You’re currently viewing items/posts in category XXXXXX”, then list the items/posts)

    • Yup – that archive manager is coming too, in release 1.1. This is something very popular and we need is also for our own sites. When it will be ready, Views will let you take full control over the standard ‘blog’, archive pages, taxonomy, search and every other list that WordPress creates.

  4. Would love to have repeater field that can create child posts. Because they are listed with all the other field and you don’t have to save the parant post before creating the child posts (that is a little annoying).

    Having inline conditioning would be great. Onlye show this field or group if the value of that field of group is x

    Regards,

    Abdul

  5. I bought the plugin months ago but wasn’t able yet to use it.. Now with these new features I am hoping soon to find some time to actually use the plugin!! The filter and reapeater functions are so cool!!! Great job, keep it coming please 🙂

    • Thank you for your support and understanding. We’re truly doing our best to make Views as complete as possible and I feel that we’re finally getting there.

  6. Great news, as usual. Views is really getting better and better.

    Simple repeating fields and grouping is good. I think that could be really good to make them sortable by dragging.

    Will “Feeding arguments to Views” be some sort of real time filtering (ajax)? Would be great!

    For versions beyond 1.0, why not add ajax searching?

    Thanks

    • AJAX updates should be possible as well. Today, Views already has AJAX for pagination and filtering should be very similar to this.

      • Great work as usual guys! I really love the direction you are taking Types & Views. Based on the current feature set and what you have planned, its undoubtably the go-to cck for WordPress.

        Just to add to what Antonio said, there are many cases where repeating fields will need to be sortable. Ideally it would just be a case of the user dragging the fields into the order they want, but a simpler solution, such as the user entering a numeric value next to each of the fields (in the order that they should be displayed, 1-10 = top to bottom) would at least be a start.

        Ajax filtering is something thats been on my wishlist for some time, as we have a couple sites we’re planning, where the search and filterable results is a big part of the sites core functionality.

        Last but not least, I really hope you guys add repeatable to the WYSIWYG field type. A simple use-case of where it would be useful, is for user-submitted recipes, where they are able to add additional steps, wherein they would enter the steps content in a simple editor textarea.

        I’m pretty jammed with projects at the moment, but as soon as I get some free time, I’m going to start prototyping the various layouts for our new foodie/recipe site, which should illustrate the various workflows and functionality.

        Once I’ve got something ready, I’ll post it on the forums for further discussion 🙂

        Cheers,
        Chris

        • Thank you for your support. With the current implementation, the simple repeating fields use multiple items with the same keys in the database. This includes its advantages and disadvantages.

          The advantages are that they can be searched and filtered. The disadvantage is that sorting is just not possible at all. WordPress will always return them as an unsorted array.

          To group fields together or use sorting, you will be able to use child items. Then, you can include several fields in the same group, sort, filter and whatever else needed.

          We fully understand that there’s more complication with this, but it’s what’s currently possible.

          WordPress makes it super-problematic to include multiple WYSIWYG fields. It’s due to the way it’s implemented, IDs and Javascript. We tried to make them repeatable, but saw that it’s leading to a number of problems which affect the entire design. I know that it’s a highly-wanted feature, we want it too for our own site, but it’s not included in the current design. I hope that WordPress 3.4 will make that JS more portable and it will be possible for us to repeat them.

          I’m looking forward to see what you build with Types and Views. When you have something, you’re welcome to add to our showcase.

          • Thanks for the detailed reply Amir! I wonder if it wouldn’t be a good idea to submit a patch that addresses the limitations on the WordPress issue tracker?

            • It’s not really a bug and it’s something that WP core keeps improving over time. The visual editor is pretty complex, both in terms of HTML and Javascript.

              Types (and several other plugins) try to do more than it’s been designed for and we’re just happy that most things are possible. Since quite a few plugins use that code, I wouldn’t expect WP to make sudden and major changes there. We’re following this and seeing what’s possible, but we don’t have any concrete suggestions on how to make that JS more portable, because we understand that there are many compatibility constraints.

          • How about, instead of using the visual editor, create a field type with its own simpler editor? There are a ton of great jQuery plugins that will turn any textarea into a visual WYSIWYG editor.

            Check the “content” tab of this site for a great example:
            http://someammo.com/

            Cheers,
            Chris

            • That’s very nice. I don’t want to promise what I don’t know well. We’re pretty packed with upcoming features for the next couple of months, up to Types 1.1. We’ll see when the todo list becomes a bit more manageable and then we’ll consider how to handle multiple visual editor fields.

  7. I forgot…
    New field types: checkbox group, color picker, slider…

    Would it be possible to make Types accessible from frontend to allow users to fill in forms and upload contents?

    What do you think of this: create a new db-table for each custom post type so each post type could have its own table.

    • Front-end content editing is also planned, but I’m not sure when. I’d love to have it for Types 1.1, but we’ll need to see where we are after the upcoming release.

  8. Still not support for multiple selection custom fields? not even on the horizon?

    This functionality is readily available in other custom field/custom taxonomy plugins but is missing from Types for some reason.

    I mean using check boxes and radio buttons is not a good solution, you need to be able to pick multiple items from a menu and save them to a field.

    • We’ll probably have multiple-option checkboxes in Types 1.0. Please note that this will not work together with repeating fields.

  9. “Wouldn’t it be nice if visitors could see a drop-down with price ranges, select one and the View on the homepage would update to show just the relevant items?”

    Sounds like what I think is called “faceted search”. “price range $100-200” and “red”
    I’m presently setting up a site where we’ll want faceted search, which I think I can do with an existing plugin and Categories for each facet (Category $100 to 200, and color categories).

    Would be nice if there were a way to migrate existing categories into repeating fields, so existing sites could use the new functionality.

    There is an existing bulk category plugin which can create categories from text data, so if there also is a way to list the data in fields then migration to categories would be an option (also, being able to access data in fields might offer report-generation options). Is there a CSV exporter of post data? I know of WP’s post export tool, but don’t know of a way to suck XML into a spreadsheet.

    • I think that faceted search is the right name for that. Can you explain why you’d like to move data from categories to custom fields?

      • I’d want to move from categories if the faceted search interface for custom fields is better than the interface available for WP categories. I’ll have to test the WP plugin with faceted search, as well as the custom fields abilities.

        Your phrasing for the 1.0 search ability seems very low-level, as if URL construction will be required, so we’ll have to wrap a user interface around these URLs (presumably with some Views shortcodes inside HTML). It doesn’t sound as if you have a [wpv-faceted-search fields=”price,color,size,weight,age”] facet-search-generating shortcode. So the comparison with existing faceted search tools will be interesting, but only mildly challenging for HTML-capable authors.

        • (For those unfamiliar with the “faceted search” term — I think it’s what eBay.com does on the left side after a search. Search for “blue wings” and on the left side you get facets for examining various aspects of the search — starting with “Categories” but also including “Price”, “Seller”, “Buying formats”, “Location”, etc. By clicking on facets you can view the results from several different angles, as it were, and narrow your search. And I made up the “blue wings” phrase and am amused by the fairy wings.)

        • Hmm… Maybe Views already has faceted search by categories and I haven’t noticed that ability? Views’ support for categories and custom fields would explain your puzzlement about moving data to custom fields.

  10. I find especially the time filtering and – by the sound of it – the faceted search the two most welcoming new features! Great stuff really!

  11. Great start. Here are a couple of things to consider going beyond 1.0:

    – Select options built from custom type: This is a must to eliminate duplicate keying of data. Real life example is to have a custom type for Pastors (with name, role, bio, picture) and have the ability to have another custom type such as Sermon with a select field that is populated with the records of the Pastor custom type. Currently have to use other plugin that converts a custom type into a category. Much cleaner to have just populate a select option with all entries in another custom type.

    – Mobile First: I really like the idea of using Views to create sliders, but must have responsive image support in fluid designs leveraging media queries to adapt to screen resolution.

    – Types support for user profiles? Seems like a shame to not use consistent Types functionality for user profile data changes.

    Thanks for the hard work, still using Types/Views on every project possible.
    -Derrick

  12. Its really coming together. I’m very happy to see the filter capabilty as this will greatly simplify a site I am working on at the moment. To have this AJAXed would be great.

    I’d also like to see more tutorials, especially videos of real life examples.

    Looking forward to getting my hands on 1.0 🙂

    Cheers, Mark

  13. Sorry to say guys but this is somewhat disappointing.

    I completely disagree with the idea that repeating group of fields would not really make sense. There are many cases where one would want repeating group of fields without the overhead of dealing with child posts. Your “engine” example makes sense but what about:
    – an “invoice”: I don’t want to manage an “invoice item” custom post type
    – a “Feature Set” that contains several features. I don’t want to display features individually nor do I want to have some custom post type for each feature.
    Even your “multiple email contacts” for a vehicle example would certainly take advantage of repeating group fields. One would certainly want to provide additional information for each email address (main, alternate OR regular, secondary). If you are providing multiple phone numbers, you will certainly want to specify “home”, “mobile” OR “week, week-end”… You certainly don’t want a separate custom post type just for having a phone number and to specify if it’s fixed or mobile.

    Believe me, you will be facing the limitations of a single repeating field very soon.

    Another point somewhat disappointing is the fact you would leave out WYSIWIG fields. Personally, not only I need repeating group of fields but I also need to have WYSIWIG fields to be repeated. This is something already handled by a plugin like Custom Fields Suite.

    Being able to sort repeating group of fields would be a killer feature… I’m sure there must be a way. As you said, you could offer the option to have one serialized array … by using this option one would accept the limitations but could also benefit ordering feature…

    I guess I had too much expectations…

    • We have to make some trade-offs. We would love to see everything implemented and allowing you to build sites exactly as you want, but when we look at the entire array of options and ideas and (very good) suggestions, we see that it’s drifting into bloat-land.

      Let’s see how you like the upcoming update and then we can discuss possible new features. Besides repeating fields (which are awesome and important), we’re also interested in other new functionality for Types.

      • It will go into bloat-land if you don’t go directly to the repeating group of fields route because you will have to maintain compatibility with your previous single-field repeating feature.

        Repeating Group of Fields let’s you handle complex entities/forms with repeating group of data whereas your post relation ship feature let’s you handle related entities. That’s something different.
        Now you can hack/workaround with your post relation ship feature but in all honesty I would rather workaround the need to relate entities (posts) with a “repeating group of fields” features with the addition of a field type that can link to some post than the other way around – that is to handle complex entities(posts) by creating unnecessary child post types (moreover, I’m limited to a singe post type child relation if I can remember).

        The upcoming won’t be of any use for me. I’m currently creating my custom post types in code (which is quite easy compared to the custom fields stuff). For repeating fields, I have recently discovered Custom Fields Suite. I thought I would replace this mixed approach with Types (knowing that I will need WPML) but obviously it won’t do.

        Well, enough ranting. I’ll have to check if Custom Fields Suite is compatible with WPML…

    • From my point of view repeating fields was the essential functionality and it’s coming (thank you!). Repeating group of fields is an improvement of it, which will be nice to have.

      But Rome wasn’t built in a day. Every custom fields plugin I know didn’t have repeating group of fields at start – it was developed after some time, when developers were trying to improve their work and provide better, more complex and more flexible solutions. I think Types is on the right track now. So let them focus on stability, bugfixing etc. and expect new, exciting features in 1.1

  14. Did I hear someone say ‘repeater fields’?

    (does a lil’ happy dance around the office…)

    Cheers guys, v.much appreciated!

    🙂

  15. I am so happy that I purchased this, it has to be one of the GREATEST tools to use in wordpress development!! I’m in the process of finishing up a site I did and used views to created a featured panel, and it worked great!

    Can’t wait to start my next one!

  16. I’m loving Types more and more and see myself using it in all future WordPress projects. I can’t wait to try out Types 1.0, ever since seeing the relationships functionality I have really wanted to have many-to-many relationship. Maybe this repeating custom field will help some, but I really want to assign other custom post types as related… for example if I have a CPT called Books, and another called Authors, I want to use relationships to assign Authors as parents to any number of Books and still be able to assign Books to any number of Authors.

    I have the capacity to help with beta testing if there is any way I can get my hands on the latest stable 1.0 beta. Is current development in the WP SVN trunk for Types?

    Thanks!

    • Types does that already today. When you edit the custom fields group setting, you will see a ‘conditional’ section. There, you can determine when to display certain fields.

  17. I’d LOVE it if Types would show its custom taxonomies on the post editing overview screens — i.e., as columns besides Title, Category, etc., *and* in the Screen Options. As it is right now it only shows them when clicking on the individual “Quick Edit” links, which is “incomplete.”

    The Ultimate Taxonomy Manager does that (in case you’re wondering what I’m talking about). And if your plugin would do this too I could uninstall UTM… 😉

    Thanks!

  18. I am definitely interested in time filtering– has the time field been implemented yet? I really need this. Thanks for the good work!

  19. Really trying to get everything out of Types and Views we notices two things we would love to get changed:

    1. First we would love 2 extra fields:

    – section break or header (so you can “group” fields together)
    – html field so you can add your own html (like a video tutorial or links or something else)

    2. We like there is inline conditioning but without it working with javascript its a little unusable. It would be great that the conditioning would just use javascript to show and hide fields (instead of having to save and then see the field)

    We would even be willing to pay for these to functionalities, they would make type perfect! adding the things you where already about to improve!

    • Types 1.0 will have AJAX for field conditions. This means that fields display correctly while you enter data.

      The other suggestion is great, but it didn’t make it into this version. We also want to let you fully customize HTML and CSS for edit pages, but it’s not included in Types 1.0.

      • Great! and you really should make this plugin more expensive … 50 dollars is really cheap 🙂 so you can hire people enc…

  20. Would it be possible to have the option of a child-picker? For example, I may have an existing child post, but for whatever haven’t associated it with a parent yet. So it would be easier, when in the Parent screen, to just pick the child, rather than have to go to the child to create the association.

  21. Hello,

    I just purchased Types & Views with the hope of using repeating WYSIWYG fields. I failed to search for and read this page before purchasing.

    Please let me know if the repeater was added for WYSIWYG fields as this is something I need for the project I’m currently working on. If not, I’m sure I can use these great plugins for something else. Thank you.

    K

    • The only field that we cannot display in child items is the WYSIWYG field. This is because it’s implemented with Javascript and CSS that makes it very complicated for more than one instance to appear.

  22. Hello Amir,

    For faceted search, I would invite you to look at 2 great plugins that build connexion with Apache SOLR search engine.

    The plugin is created by a startup offering Solr as Saas (but the plugin could be used with your own Apache Solr instance).

    Advanced Search with SOLR

    http://wordpress.org/extend/plugins/advanced-search-by-my-solr-server/

    Browse Content with SOLR

    http://wordpress.org/extend/plugins/browse-content-by-my-solr-server/

    I’ll integrate them with TYPES/VIEWS in a current project. So I will try to share my experience. But I would be an incredible association 😉

    Regards

    F

    • SOLR search is great, but I’m not sure if we can support that initially. It’s pretty complex and un-frequently used. We’re going to start by adding GUI for controlling which fields to index in Relevanssi. Have you looked at that?

      • Looking forward to the Relevanssi integration! Any updates on getting Types to play nicely with the Gravity Forms plugin?

      • That is interesting (Relevanssi) not yet tested.

        I know Dominique the Dev of SOLR plugin. In fact he’s offering a service with a subscription model to SOLR instance.

        http://www.mysolrserver.com

        When you’re using those plugins, you are connected to your MySOLRserver account. And the synchronisation works smoothely.

        There is also an opportunity for WP-Types to receive an affiliate fee per new subscriber added.

        So if you want a direct contact with Dominique, you’ve got my email. I’ll be glad to introduce you.

        Anyway in the following weeks 2 to 3, I’ll test the integration of WP-Types with his service. I’ll come back with that experience.

  23. Repeatable fields is exactly what I’ve been waiting for. Unfortunately I need the function this week.

    So my question is… If I use ACF today and their repeater plug, can I use Types in the future to handle the custom fields already created (and deactivate ACF)? I understand that I might need to change the PHP code for the presentation of the values. Migration is perhaps the right word to use here?

    Thanks!

    • The repeater functionality in Types and ACF is not identical, so you’re not going to have a 1:1 migration. And, it’s not going to be released this week. There are a few more issues to handle and a lot more testing before we release Types 1.0.

      • Holy smoke!
        That was a quick answer Amir! 🙂

        Ok, then I’ll just have to convince my client to be patient for some time 🙂
        Thanks

  24. hello,

    Type and view are actually great as i could see on this website. For a project i use type and i’m near to use view.

    Here is some question i have about the future of Type and view :

    1rst question :
    In wordpress custom post type and custom field are great same for taxonomy but when you want to build a website with lot of information link them self it’s pretty complex for editor. Perhaps type and view could help in the future.

    I explain imagine website like “http://www.imdb.com/”. this web site have data base of movie actor and so on. It could be done with type and view. Then imagine you would to include some news about movie and in back office make link between news post and database of movie (custom post type with custom field).

    Right now I don’t find a good simply solution for do that. Mean when you write a news for the next “James bond” with the native post system of wordpress click on a “select box” for choose movie relative on and then “in auto mode “ link this post to custom post type of movie. Then in “View” you could make a template that present the movie information in the post about next james bond.

    Same way make link between movie and actor with view and after when write a new with native post system when click on select box for movie make link between this post the movie and as the movie is link to actor make link also with the actor. With “view” then have information about movie and actor in the post page 🙂

    2nd question :
    Is there on the next version a system to “scan?? the wordpress installation, detect custom post type and taxonomy already install and then import them on Type for use with View ?

    Thanks for make the dev/design life more happiness with great plug-in

    jona

    • IMBD is a pretty good example for what you could do with Types and Views. To properly answer you, we would have to analyze the data structures and decide what would be custom posts, fields and taxonomy. This is only clear when you look at the big picture. Breaking it into separate things makes this analysis problematic.

      Types is not going to scan existing posts. This is technically possible, but I feel that it’s a lot of code to add for something that is better done manually. I’ll write a FAQ about how to do this. Currently, all FAQ items are here:
      https://toolset.com/documentation/frequently-asked-questions/

      • Thanks for answer.

        As I readed faq and forum, now I can said “I have a dream” 🙂 that in some days we could buy complete theme include “type and view” plug-in that ready for some business (e.g : real estate, car, high tech news mag…).

        Custom post type, field and taxonomy done and ready to use or customize. Same for View template.

        It was a dream perhaps it will be reality…

        • We share that dream, but we’re also working to make it a reality faster.

          We’re working on our own base-theme, which will make it much easier to build flexible sites with Views. Additionally, we’re working with a few premium theme authors to make their themes and Views integrate perfectly.

          I hope to have our base-theme ready in about a week. Integration with PageLines and Headway should follow soon too.

          • Wonderful…depend on theme and price but perhaps I will be your first cutomer of that theme base.

          • Have you heard of the work being done by the guys over at ultimatumtheme.com?

            They have taken a radically different approach to designing and laying out themes with true drag and drop layouts.

            If Type and Views are compatible, then that would one powerful combination.

            • Yes, almost. We’re doing some more work on Header customization and other touch-ups. We’ll have it ready in a few days.

  25. I love repeating field and custom search.

    For search plugin, are you planning to create a search plugin as part of views or it would be a widget added. Lets say there can be a ‘layered navigation’ widget that pull custom fields and taxonomies according to ‘types’ powering ‘view(s)’ displayed at the moment on the page.

    Or the search can be a another plugin associated with view(s) and can be displayed in a widget sidebar wherever required. (my wild thoughts 🙂 )

    Lastly, is there any list of all small updates and fixes to be released with ver 1.0 ?

    Regards,

    • Types and Views 1.0 are very close to release now. They are running QA and will be ready in about a week.

      Repeater fields are in, testing and polished. Some other features didn’t make it in, but we did spend a huge amount of time on usability, responsiveness and stability. A good number of bugs and confusing issues have been resolved.

      I’ll write about this next week, when we either have a final release or a solid release-candidate.

  26. First, let me just say I am blown away! Awesome tools, great approaches. Really happy with this purchase… combined with Headway and Gravity Forms I feel armed to the teeth!

    Just a few bits…

    1) Keep adding predefined field types. I am now aggressively looking forward to a Select I can populate from another Type. Will open foreign key relationships and enumerations where parent/child is not the right approach.
    2) Calculated fields? Perhaps a simple aggregate implementation to begin with? Example: Parent View Template includes Sums and Counts of fields in a child type. I think you see where this takes you… goodbye CMS hello application platform.
    3) Solid UI for adding Parent fields into Child Views and View Templates. It can be important to include Parent Title in Child tables…
    4) Alphabet Pagination option in Views (based on first letter of Title or chosen field). This could later be expanded to include other derivatives such as numeric bands (aka partitioning)
    5) A UI builder for new View Layout styles? Blue sky…

    Thanks again folks.

    • Thank you Garet for these suggestions.

      Today, adding child Views requires building a new View and filtering by parent attributes. What do you envision in a dedicated GUI for child Views?

      And, can you explain more about your 5th item? One of the reasons we’re partnering with Headway is that you can do the graphics stuff in Headway and the HTML / CSS in Views.

      • On the first point I am more referring to the adding of parent fields into child views/view templates, as opposed to a UI for building children. At present the docs indicate I have to ‘hard code’ parent field references into the children?

        On second point am referring to the dropdown ‘Layout’ selector for the View (e.g. Grid/Table/ etc). I presume these are coded as some kind of template and would be good to be able to create more.

  27. This is GREAT! When 1.0 comes out I am purchasing views. Right now I am still playing around with types to get it organized the way i need it to be.

    I am most excited about the content filter being able to filter what is show on a list of post types by any characteristic of that type.

    • Thank you for the support. Both Types and Views 1.0 are now at the end of the QA run. We plan to have them out next week.

  28. Great job !
    Your Types and Views could be a kind of Holy Grail on the road to make wordpress a great user friendly CMS !
    I’ve purchased Views and I’m very happy with this plugin. But now, I’m waiting for Types 1.0 with a great impatience, arghhh !

    Thank you so much for your work.

    Probably not the most useful reply, but…

    By the way, do you have any idea to import custom-post types made with another plugin (Custom Content Type Manager) ?

    • We don’t have any import code from Custom Content Type Manager. You should:
      1) Disable that plugin. All the custom content will temporarily ‘vanish’.
      2) Define the exact same custom types using Types. Especially, make sure that the slug is identical, as it identifies the data. Everything will ‘appear’ again.

      • And don’t forget to backup everything before trying the migration 😉

        Can’t wait for the new release. ‘Types’ really makes WordPress feel like a proper CMS. With Relevanssi (search plugin), Gravity Forms and things like Editflow, WordPress can be surprisingly flexible.

  29. A few general comments – As you move past beta:

    1) Avoid “death by a million features”. It’s great to be responsive to the community – but when it degenerates into a popularity poll about how to implement (or worse, re-implement) a feature – then there are going to be serious adoption issues for people looking to use this to develop solutions for end users – or scale their implementation to zillions of records. I’d rather see strong, reliable, and scalable (ie: “fast”) and a well thought-out implementation that I can rely on – than you solving my implementation issues… The WP E-commerce plugin in attempting to be all things to all people, eventually became feature-full, bloated, and clumsy. Do one thing correctly – reliably and fast – and people will use your stuff – otherwise….

    2) Build a regression test-bed so that you can confirm that the latest iteration is not breaking existing applications – or else you will spend most of your development bandwidth re-factoring end-users’ solutions – and any real development will stall…and customer service will suffer. Differentiate forums from end-user requirements that are driven from their need to make your code do something that is needed so they can offer it as a solution to their own customers – from TRUE bugs in which your code doesn’t operate as advertised or documented….

    3) Track the WP codex – and refactor your solution as the capabilities that you have augmented become a part of the core implementation of WP. Build compatibility with whatever evolves out of the “collective” as a standard – but, get yourself a head of the curve by submitting your solutions and approach to those who might be implementing similar features in an “official” capacity. If necessary – find new ways to add value.

    4) Consider all the implications of someone adopting your asolution on a grand scale – including the ability to import and export configurations – and converting and upgrading existing impementations of custom types – such as might be the case with certain themes – such that they can be managed appropriately by your UI. The ability to selectively place pre-existing custom types could be useful – but equally true would be to ignore them…Consider that some may be looking to incrementally migrate to your solution – in order to keep their own code-base stable.

    5) Offer Views purchasers a discount on your localization (and other?) plugin(s) (ie “cross-sell”)…

    Thanks.

    • There’s a field for ‘menu icon’, but no upload mechanism. If you upload that icon via the Media screen, you can copy/paste its URL to that field. Have you tried that?

      • That adds the logo to just the wp menu. But keep in mind the wp menu and the icon on the CPT are different sizes.

        drop me an email mike.zielonka at tunatraffic dot com if I can send you a little more info.

  30. This is AMAZING! 2 of the features you explained were features I wanted and was debating asking for a rebate for when I found that it didn’t work.

    I kept the faith and you delivered! Great job guys!

  31. I am working on a site for a Theater. It requires an events custom post type. I am not able to figure out how to implement “Time” in conjunction with date. For instance, an event may have multiple showings (ie. 2012/12/08 @ 7:30pm, 2012/12/09 @ 3:00pm). I need to be able to create multiple instances of date with times for each event. It appears that I can only do date currently. Is there a way around this limitation?

    I also need to be able to expire events based on the last show-time, but I believe I can figure out how to utilize Views for that.

    Thank you much!

    • We don’t have a “Time” field yet. We’re planning on implementing that next. It will probably be available in about 4 weeks.

      The current “Date” field can store the time as well as date. We just don’t have the UI to support this at the moment.