• Resolved bostondave08

    (@bostondave08)


    I have very quickly installed and tested the 2.0 version of the plugin and came up with 2 questions before I dive in. 2.0 looks incredible. I am using a set of other plugins that I think might be covered in this one plugin?

    1. Storage of the data?
    1.x version of the plugins use separate tables to store data but this version appears to let you pick between creating default custom post types (as if you hand coded them) vs. a separate table. correct?

    It seems simple, but the language on the site, here on the repository and in the video still seems like a separation of the data. I was reluctant to use 1.x because I felt if would lead to incompatibility with a range of other plugins that might use native CPTs.

    2. Pod vs. “types and views” plugin
    I realize the relationship between the “types” part of the “types and views” set of plugins but I was curious as to the “views” part. Is this what is within the “templates” component?

    I am not sure if you are familiar with that plugin but I would like to create lists, grids, etc from the custom post types. For example, a page that lists of the items from a CPT.

    https://www.ads-software.com/extend/plugins/pods/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Contributor Scott Kingsley Clark

    (@sc0ttkclark)

    Sorry for the delay, we’ve been working with our users to ensure our latest 2.0 release is as stable and as backwards compatible as possible with all of their projects. We’re also in the process of getting our beautiful new docs area up.

    1. Right, in 1.x it was a separate table for each content type. In 2.0, the defaults are set to WP standards, so Post Types are meta-based, but you can opt-in on creation to choose to make them table-based instead. So you’ll be covered with compatibility there, we’ve tested compatibility with many plugins including Polylang and WPML.

    2. Types and Views are quite a bit different. I’d actually suggest you try out the LoopBuddy plugin instead, it’s pretty cool and was I believe the first major attempt to reproduce the functionality brought from the Drupal Views module.

    Anyways, our templating is pretty simple, you can use {@field_name} within the template content to output values of fields pretty easily. You can also use our templating syntax from within our [pods] shortcode. There’s more flexibility we hope to highlight in our documentation soon.

    Thread Starter bostondave08

    (@bostondave08)

    Thank you for the quick reply and the tip on LoopBuddy. I had not seen that one yet and was trying to get a bit of the drupal side into wp.

    Great job on the new update – I am experimenting with it now.

    Thread Starter bostondave08

    (@bostondave08)

    …I could have just read this as well. ??
    https://dev.podsframework.org/tag/pods2/

    Plugin Contributor Scott Kingsley Clark

    (@sc0ttkclark)

    Check out our comparison between the many different plugin options for Content Types and Custom Fields:

    https://docs.google.com/spreadsheet/ccc?key=0AoY8IFUX301qdFhBaERLUEUwa3U0YjFYTnBmaU1mbmc#gid=1

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘[Plugin: Pods – Custom Content Types and Fields] Pods 2.0 – 2 simple questions on data storage &’ is closed to new replies.