Types is ready to download and use. It allows creating custom post types, custom taxonomy and custom fields. It’s fully integrated with WPML and with Views, letting you build complex multilingual sites with WordPress without any coding.

Setting Up

Types creates three things:

  • Custom post types
  • Custom taxonomy
  • Custom fields (meta boxes)

First, download Types, install and activate it. Once setup, you’ll see this main menu:

Types menu

Click on Custom Types and Taxonomies to setup your own post and taxonomy types.

New custom post type

In the WordPress world, every piece of content is a post. This includes the standard posts and pages. When you want to add your unique content type, you’re creating a custom post type.

Taxonomy is the glue that connects related content together. List tags and categories group together related posts, so does custom taxonomy connect together custom post types. Custom taxonomy can connect any post type, including the standard types.

Click on Custom Fields to add meta-boxes to the WordPress editor.

New custom-fields group

Types arranges custom fields in groups. It lets you select which group to display on different content types.

Groups have fields. You can choose standard fields, such as single-line and multi-line text inputs, or more complex fields such as file, image or Skype contact.

Click on Add a custom fields group. Give it a name and an optional description and add fields by clicking on their names from the list at the top-right.

Adding a custom field

Once you’ve added a field, you can configure it. Give it a name and a description. Each type of field has its own unique setup.

This is how a group looks like on Edit screens:

Types custom fields in the content editing screen

You can see various types of fields, including text, check-box and image uploads.

Displaying Custom Fields

You’ll notice that there’s a shortcode hint below different fields in the editor screens. These shortcodes allow to include the fields in the page content. When authors enter these shortcodes to the text, Types will replace them with the field content.

Custom field display is different for each field type. Text fields simply output their value. Check-boxes and radio groups will display the respective text for their state. Image fields output the images (allowing you to choose image dimensions) and other special fields have unique display options.

Authors can use the T icon, at the top of edit screens to choose from available fields to insert.

Inserting custom fields to content

If you want to add fields to templates (so that they appear on all pages of the same type), you can use Views, to generate dynamic templates, or edit the template PHP files and use Types API calls to display fields.

Data Validation

Fields can also validate user-input. You can set any field as ‘required’. Other fields have other validation options. For example, numeric fields will check that users only enter numbers and email fields will validate for well-formatted email addresses. You can enable or disable each of these validations, per field.

When authors enter content and validation fails, Types will highlight the incorrect fields and instruct users to edit them.

Custom-Field Translation Options

Types lets you choose what to do when translating content that includes these custom fields. By default, WPML will translate text fields and copy non-text fields. This means that images, check-boxes and numeric values will auto-synchronize between the original content and translations and texts will get translated.

Multilingual Admin Screens

WPML lets different users have different admin languages. This is especially useful if there are different people configuring and running the site.

All the texts that you enter in Types appear in WPML’s String Translation screen. This includes names, descriptions and labels and field values.

Translating Types string in the String Translation screen

Once you translate these texts in the String Translation screen, users will see the localized languages on the WordPress Admin, as well as on public pages.

Translating Custom-Type Content

The central location for controlling what is multilingual is in WPML->Translation Management->Multilingual content setup. There, you will see all the custom types that you’ve added (post types, taxonomy and fields). Once you make custom types translatable, you’ll get the familiar translation controls in their lists screen. You’ll also be able to choose the in the Translation Dashboard.

WPML automatically adjusts the translation editor and according to the setup of different custom fields.

Custom fields in the Translation Editor

When you translate content that includes a custom field, you’ll notice that the name and description show for them. This allows translators to understand what they’s translating and where the text goes to.

Download, Cost and Support

You can download Types from Toolset website:


You’re welcome to read tutorials and complete reference documentation in Types & Views website.

Views is a powerful compliment to Types, allowing to display custom data without any coding. We’re offering commercial support for both Types and Views through the support forums on https://toolset.com.

Views and expert support for both plugins for one year costs $49 (USD).

27 Responses to “Types – multilingual-ready custom content setup”

  1. How to migrate from “Custom Post Types UI” to “Types” in existing site?

    Please supply a tutorial or at least a short instruction for this.

    In which order should the plugins be installed/uninstalled without losing existing custom post type data.

    Did not find anything about that on “Types” homepage or FAQ.

    • Good point. We didn’t think about that, but it’s pretty important to add. It will be safest to do with some code, because we’ll need to update the names of custom fields and copy the field declarations. I’m adding it to our todo list.

      Before you migrate to Types, please test it and see that it does all you need. We’re eager to get some feedback from real sites.

        • The above sounds maybe a bit rude, but before investing time in “Types”, there should be a statement about migration possibilities.

          If I invest time here, I would want to use “Types” also on already running productive sites, and then a migration without data-loss is absolutely necessary.

          Once I use your plugins, I even supply patches for bugs/missing features, e.g. http://forum.wpml.org/topic.php?id=5257 or http://forum.wpml.org/topic.php?id=4819 but you have to convince me (and probably many other “Custom Post Type UI” users) first to actually start with the “Types” plugin.

            • Maybe I want to buy “Views”?

              Then I would want to use “Types” to define the custom post types?

              Then I should know if/how I can migrate customer sites from “Custom Post Type UI” and not lose existing custom posts?

              Actually I was really looking hard for this information on the whole “Types” site before asking in wpml-forum and here, as I could not believe that it was not provided. If you take into account that “Custom Post Type UI” has been downloaded over 90000 times, there could be quite some customers for Types + Views, just saying…

  2. Looks promising, but from what I see you don’t provide the “repeat field” functionality for custom fields (so that e.g. when I set ‘gallery-image’ field user could add as many images as he wants and I could loop through them in template file?)

    • That’s a good idea to add to. I’m compiling a list of good ideas for the next releases and I’ll include this too. Keep them coming.

  3. Any plans to support “capability_type” and “capabilities” in “Types”?

    More about this:

    I did not yet use them with Custom Post Types UI, as the implementation is incomplete and requires manual adding of code in current version, but I plan to use them in a future project, where users will be limited to certain custom post types.

    • Excellent point. We’re planning to add Roles support for WPML with we certainly need to include it in both Types and Views. I’m adding to our todo list.

  4. Types look very promising, espacially for WPML users.

    I totally agree with qrc speaking about capabilities and roles, but I think it’s a more general thought about WordPress itself handling user roles and user access.

    My Types wishlist:
    – ability to translate it (I find it impossible at the moment)
    – conditional fields (if page is equal.., if post is not equal.., if post parent… etc)
    – or custom field templates

    • – What kind of trouble are you having translating Types itself? We made it top priority to make Types fully translatable.
      – We’re going to add conditionals. I’m just not sure how. I want it to be flexible and generic. I guess that we would learn best from use-cases.
      – What do you mean by custom field templates? Again, examples would be great.

  5. Problems with translation Types: No .pot, .po, .mo files included. No language folder into which I could drop for e.g. .pot file created by myself in Poedit application. Not accessible to Codestyling Localization plugin (don’t know why, it’s just “invisible” to it). Maybe there’s another way to translate it and I just don’t know it?

    Conditional custom fields are great in Advanced Custom Fields plugin (http://wordpress.org/extend/plugins/advanced-custom-fields/). I find it the best idea to handle that.

    Different approach to custom fields management is involved in Custom Field Template plugin (http://wordpress.org/extend/plugins/custom-field-template/).

    • You’re right about missing .po / .pot files. All the texts in Types and Views are wrapped in gettext calls, but we didn’t generate the .pot files. We’ll do this for the next release, as the texts get more finalized. We prefer to start the translation when the GUI gets its final content.

      Thanks for the suggestion about conditional custom fields. We’re going to review that very soon.

  6. There is a small glitch with WPML when we translate a custom type post that has a parent : it loose his parent… This bug is not happening when I translate a ‘core page’… For huge site, it’s not really productive to reset the parent in the drop down menu for each translation…

    Thanks for your support !

  7. How can we make appear the WPML ‘+’ signs into the index of a custom type post (home page of the custom type, where we see the list of this post type)? It is visible for custom post type index created manually (not form type).

    Thanks again

  8. I think Types is going right direction. I don’t know how ambitious your plans are but it would be great if it become a complete suite to create content in WordPress. Conditional fields, multiple field types, repeating fields (or sections of fields) and user access management combined into one suite would be a fantastic tool.

    So, another suggestion: WPAlechemy class (http://www.farinspace.com/wpalchemy-metabox/) Maybe you’ll find that useful in Types, as it has most of the features, except GUI.

  9. Question?

    What about if you already have custom types “Portfolio Section”. Can you use this plug-in to link up the translate feature?


    • You can use Types to continue managing (and translate) custom types that were defined before. If you defined them in PHP, do this:
      1. Backup your database.
      2. Delete the custom types definition in PHP. The data will ‘vanish’ from your site.
      3. Define the custom types again in Types. The data will appear again and now you can use Types to manage it.

  10. I´ve already used this plugin with success in other site, but in a new I can´t use image option. In my localhost version of site, the image is ok, I upload, than it appears where have to be, but when I put this in a server in internet, It doesn´t show the image, I´ve already try to recreate a new option, but the same occurs…I import type options form original site (localhost). Should I recreate all options again in the second site without import????

  11. Hi,

    I need to link a button to a (multilingual) Custom post type. I want to do this with the icl_link_to_element so it links to the translated version of the post type, but I can’t seem to find the required ID of this WP Types custom post type! Does anyone know how to retrieve this custom post type ID?

    Thanks in advance!

        • When you edit a taxonomy term, like the ‘projects’ category, you will have a link that looks like this:

          You need to use the tag_ID argument for WPML’s call.

          Every post and taxonomy has an ID and that ID must show when you edit it. If you are not seeing the ID, you might be in the listing page and not in the page that edits this specific item.

          Does this help?