Pods Development Blog

Tagged: testing RSS Toggle Comment Threads | Keyboard Shortcuts

  • sc0ttkclark 3:23 pm on August 9, 2012 Permalink
    Tags: , cost, ohloh   

    How much does Pods cost? 

    Pods is free and will remain free, but check out how much effort it’s taken to get it to where it is today!

    https://www.ohloh.net/p/pods-framework/estimated_cost

     

    • bjornet 8:23 pm on September 5, 2012 Permalink | Log in to Reply

      I really appreciate you for showing this, this example helps me as developer to set a decent pricetag on my work and of cause understand the tremendous amount of work you guys have put into Pods.

  • sc0ttkclark 7:17 am on October 4, 2012 Permalink
    Tags: , ,   

    Pods 2.0 has arrived! 

    Background

    The Pods Framework has been around since late 2008. Planning, design, development, and testing started in 2010 for Pods 2.0 leading to an Alpha release on January 2nd, 2012. Beta was released on August 12th, 2012. Now Pods 2.0 has finally arrived, as of September 21st, 2012!

    After our soft launch, we’ve been working on bug fixes for the past few weeks to ensure maximum stability and backwards compatibility before going full force with our 2.0 announcement. That point has been reached and we’re ready for the flood of new users that awaits, including our awesome Pods 1.x users who are anxious to upgrade.

    Have at it, and most of all — Enjoy the freedom of developing any type of content with any type of field that you can think of for WordPress!

    Bug Reports / Feature Requests

    Please report bugs and suggest features in our GitHub Issues area. We’ve got an awesome feature line up for Pods 2.1 that is already in progress, we’ll announce our 2.1 testing program in the next month. Pods 2.1 is scheduled to be released alongside WordPress 3.5 on December 5th, 2012.

    Big Thanks to our Sponsors!

    We have to really thank Automattic and Matt Mullenweg for all they’ve done to help us, we honestly could not have finished Pods 2.0 and taken it to the next level without their support.

    RD2 provided some awesome UI design work for our new 2.0 upgrade screens.

    MarkNet Group provided extra help when we needed it to keep the project going over the past two years, major kudos!

    What’s new?

    Below is a feature list that goes over what 2.0 offers, we hope you enjoy it as much as we have while we’ve used it on our own projects.

    • Slick new interface, fully revamped to make managing your Pods easy and stress-free
    • Large performance enhancements using transients and object caching (reducing queries per page load in both dashboard and site to the lowest possible number, sometimes that’s ZERO)
    • New Upgrade wizard screens designed by RD2 will help you upgrade from previous versions and report any potential known issues beforeit actually upgrades your site
      • We’ve partnered with Automattic to offer 1 free month of VaultPress service to users upgrading from Pods 1.x, you will see the offer in the upgrade screens.
      • We’ve also partnered with iThemes to offer 25% off of a BackupBuddy license to users upgrading from Pods 1.x, you will see the offer in the upgrade screens.
    • Add New Pod wizard guides you through creating or extending content types with custom fields
      • Create New Content Types
        • Custom Post Types
        • Custom Taxonomies
        • Advanced Content Types (each type lives in it’s own table, outside of the WP object architecture)
      • Extend Existing Content Types
        • Post Types (Posts, Pages, Existing Custom Post Types)
        • Taxonomies (Categories, Tags, Existing Custom Taxonomies)
        • Media
        • Users
        • Comments
    • Choose to store your data using meta-based storage (default) or custom table-based storage
    • New Field Editor and Field Types
      • New Field Type options built in (no more input helpers for most common input types!)
        • Date / Time – Date, Time, or both
        • Number – Plain Number or Currency
        • Text – Plain Text, Website, Phone, E-mail, or Password
        • Paragraph Text – Plain Paragraph, WYSIWYG (TinyMCE or CLEditor, or add your own), or Code (Syntax Highlighting)
        • Color Picker – Choose colors, because colors are great (Using the default WP color picker, Farbtastic in 3.4)
        • Yes / No – You can’t really go wrong with a checkbox, but we’ve added a few charms to make it stand out
        • File / Image / Video – Upload new media or select from existing ones with our Media Library integration, or use a simple uploader, your choice
        • Relationships – Relate any item, to any item of any WP object type or another Pod, now with improved Bidirectional relationship support
    • New grouping fields API on the Add/Edit forms for Post Types, Taxonomies, Media, Users, and Comments (We’re adding a management UI for this coming in 2.1)
    • New Shortcode popup integration with TinyMCE editor (now provide one-off templates within the shortcode itself)
    • New Widgets (and provide one-off templates within the widget itself)
    • New Form UI front and back
    • New Attachments option available for File Uploads allows you to click “Attach” and select media items from the normal built-in WP Media Library pop-up
    • New Componentsallow additional functionality to be enabled but not loaded if you don’t want/need them
      • Pod Templates
      • Pod Pages
      • Pod Helpers
      • Roles and Capabilities
        • Add / Edit Roles (Administrator, Editor, etc..)
        • Add / Edit Capabilities for each Role
      • Markdown Syntax for Paragraph Text fields
      • Migrate: Import from Custom Post Type UI
        • Import Custom Post Types and Taxonomies created by the Custom Post Type UI plugin
        • Import them all, or choose a few
        • Optionally cleanup the Custom Post Type UI options when done, removing the imported objects from it’s control
    • Basic WPML Integration and confirmed Polylang compatibility
    • Fully Localized interface and error messages! All of our text strings in the plugin now run through the i18n functions. We don’t have any translations yet, but we’re looking at getting GlotPress setup for translators to start getting in.
    • Requires at least WordPress 3.4 and is tested against WordPress 3.4 and 3.5 releases

    Not sure about Pods 2.0 yet? Screenshot time!

     

    • hsatterwhite 2:43 pm on October 6, 2012 Permalink | Log in to Reply

      Holy Cow in a plugin Scott! I’ve been looking at it since Thursday afternoon and it’s absolutely wonderful. The UI is great, intuitive, and very forgiving when you’re making mistakes. Love seeing how far you’ve come with Pods as it is by far one of the most powerful plugins/frameworks/extendomatic-in-a-box things to to ever happen to WordPress.

      I’m a big fan of how you re-vamped “Helpers”. Using it as a custom post type with the built-in WordPress revisions feature is spot on smart. This is honestly the first time I’ve ever looked at Pods 2.0 in any of its forms. The really cool thing to me is that you created “Helpers” in a way that provides flexibility and history. Using Code Mirror for syntax highlighting, storing it as a custom post type, and utilizing WordPress’ built-in revisions function takes “Helpers” light years beyond what it was in the 1.x.x releases. As a long time user of Pods I’m completely overjoyed with Pods 2.0!

      Again, thanks for all that you’ve contributed to the WordPress community.

      • sc0ttkclark 2:34 pm on October 8, 2012 Permalink | Log in to Reply

        It’s messages like these that make what I do worth it. That’s exactly what I set out to do for Pods 2.0, so I’m very glad that was successful!

  • sc0ttkclark 6:10 pm on October 15, 2010 Permalink
    Tags: testing   

    Pods Data Storage vs CPT Custom Fields – MySQL Testing 

    Comparing Data Storage Models on the MySQL level

    This is a specific comparison between Pods 2.0 and CPT on the MySQL side of things, there are a couple of minor differences data-wise with Pods as it is now, but it’s roughly the same figure.

    Here’s the setup — so we’ve got 1 content type called ‘test’. It has 20 custom fields. Each field is filled with randomized data (for real world probability of contents). For our testing purposes here, we are strictly comparing the Custom Field model WP uses vs the Pods Custom Table model for data storage. As such, the test has been simplified to target the differences between the two models.

    I setup three tables: test_data (the main fields), test_meta (custom fields storage example), and test_tbl (pods storage example). You can get the Table SQL downloading this file: test.zip (contains test.sql)

    I then inserted 50,000 ‘items’ into the test data type. I did this using this script: test-insert.php.txt (remove .txt to use, also I did this in phases, depending on your server you may need to modify the script $x end value until you’ve got your ideal amount of data inserted)

    Pods vs CPT Custom Fields – a MySQL Test

    (list shown in all cases with Pods first and CPT Custom Fields second)

    • The Basics
      • Empty Table Index Length (bytes):
        • 1024 vs 4096 (Pods is 4x less)
      • Table Columns:
        • 21 vs 4 (Pods stores each custom field as a column in it’s object type’s table)
      • SQL JOINs Required:
        • 1 vs 20 (Pods is 20x less)
    • With 50,000 ‘test’ items added w/ 20 additional non-main fields (Custom Fields)
      • Index Length (bytes):
        • 716,800 vs 31,690,752 (Pods is 20x less)
      • Data Length(bytes):
        • 32,400,000 vs 72,800,000 (Pods is over 2x less)
      • Rows:
        • 50,000 vs 1,000,000 (Pods is 20x less)
    • MySQL Testing
      • Test One: Listing using Relational Method – Select all Custom Field data from 20 rows
        • Query Time (seconds):
          • 0.010 vs 0.127 (Pods is more than 10x less)
        • Queries Used
          • Pods Query 
            • SELECT p.*, t.*
FROM test_data AS p
LEFT JOIN test_tbl AS t ON t.id = p.id
LIMIT 0,20
          • CPT Custom Fields Query 
            • SELECT p.*,
t1.meta_value AS custom_field_1,
t2.meta_value AS custom_field_2,
t3.meta_value AS custom_field_3,
t4.meta_value AS custom_field_4,
t5.meta_value AS custom_field_5,
t6.meta_value AS custom_field_6,
t7.meta_value AS custom_field_7,
t8.meta_value AS custom_field_8,
t9.meta_value AS custom_field_9,
t10.meta_value AS custom_field_10,
t11.meta_value AS custom_field_11,
t12.meta_value AS custom_field_12,
t13.meta_value AS custom_field_13,
t14.meta_value AS custom_field_14,
t15.meta_value AS custom_field_15,
t16.meta_value AS custom_field_16,
t17.meta_value AS custom_field_17,
t18.meta_value AS custom_field_18,
t19.meta_value AS custom_field_19,
t20.meta_value AS custom_field_20
FROM test_data AS p
LEFT JOIN test_meta AS t1 ON t1.related_id = p.id AND t1.meta_key = 'custom field 1'
LEFT JOIN test_meta AS t2 ON t2.related_id = p.id AND t2.meta_key = 'custom field 2'
LEFT JOIN test_meta AS t3 ON t3.related_id = p.id AND t3.meta_key = 'custom field 3'
LEFT JOIN test_meta AS t4 ON t4.related_id = p.id AND t4.meta_key = 'custom field 4'
LEFT JOIN test_meta AS t5 ON t5.related_id = p.id AND t5.meta_key = 'custom field 5'
LEFT JOIN test_meta AS t6 ON t6.related_id = p.id AND t6.meta_key = 'custom field 6'
LEFT JOIN test_meta AS t7 ON t7.related_id = p.id AND t7.meta_key = 'custom field 7'
LEFT JOIN test_meta AS t8 ON t8.related_id = p.id AND t8.meta_key = 'custom field 8'
LEFT JOIN test_meta AS t9 ON t9.related_id = p.id AND t9.meta_key = 'custom field 9'
LEFT JOIN test_meta AS t10 ON t10.related_id = p.id AND t10.meta_key = 'custom field 10'
LEFT JOIN test_meta AS t11 ON t11.related_id = p.id AND t11.meta_key = 'custom field 11'
LEFT JOIN test_meta AS t12 ON t12.related_id = p.id AND t12.meta_key = 'custom field 12'
LEFT JOIN test_meta AS t13 ON t13.related_id = p.id AND t13.meta_key = 'custom field 13'
LEFT JOIN test_meta AS t14 ON t14.related_id = p.id AND t14.meta_key = 'custom field 14'
LEFT JOIN test_meta AS t15 ON t15.related_id = p.id AND t15.meta_key = 'custom field 15'
LEFT JOIN test_meta AS t16 ON t16.related_id = p.id AND t16.meta_key = 'custom field 16'
LEFT JOIN test_meta AS t17 ON t17.related_id = p.id AND t17.meta_key = 'custom field 17'
LEFT JOIN test_meta AS t18 ON t18.related_id = p.id AND t18.meta_key = 'custom field 18'
LEFT JOIN test_meta AS t19 ON t19.related_id = p.id AND t19.meta_key = 'custom field 19'
LEFT JOIN test_meta AS t20 ON t20.related_id = p.id AND t20.meta_key = 'custom field 20'
LIMIT 0,20
      • Test Two: Searching AND Listing using Relational Method – Select all Custom Field data from 20 rows with Custom Field 19 containing ’59′
        • Query Time (seconds):
          • 0.013 vs 0.137 (Pods is 10x less)
        • Queries Used
          • Pods Query 
            • SELECT p.*, t.*
FROM test_data AS p
LEFT JOIN test_tbl AS t ON t.id = p.id
WHERE t.custom_field_19 LIKE '%59%'
LIMIT 0,20
          • CPT Custom Fields Query 
            • SELECT p.*,
t1.meta_value AS custom_field_1,
t2.meta_value AS custom_field_2,
t3.meta_value AS custom_field_3,
t4.meta_value AS custom_field_4,
t5.meta_value AS custom_field_5,
t6.meta_value AS custom_field_6,
t7.meta_value AS custom_field_7,
t8.meta_value AS custom_field_8,
t9.meta_value AS custom_field_9,
t10.meta_value AS custom_field_10,
t11.meta_value AS custom_field_11,
t12.meta_value AS custom_field_12,
t13.meta_value AS custom_field_13,
t14.meta_value AS custom_field_14,
t15.meta_value AS custom_field_15,
t16.meta_value AS custom_field_16,
t17.meta_value AS custom_field_17,
t18.meta_value AS custom_field_18,
t19.meta_value AS custom_field_19,
t20.meta_value AS custom_field_20
FROM test_data AS p
LEFT JOIN test_meta AS t1 ON t1.related_id = p.id AND t1.meta_key = 'custom field 1'
LEFT JOIN test_meta AS t2 ON t2.related_id = p.id AND t2.meta_key = 'custom field 2'
LEFT JOIN test_meta AS t3 ON t3.related_id = p.id AND t3.meta_key = 'custom field 3'
LEFT JOIN test_meta AS t4 ON t4.related_id = p.id AND t4.meta_key = 'custom field 4'
LEFT JOIN test_meta AS t5 ON t5.related_id = p.id AND t5.meta_key = 'custom field 5'
LEFT JOIN test_meta AS t6 ON t6.related_id = p.id AND t6.meta_key = 'custom field 6'
LEFT JOIN test_meta AS t7 ON t7.related_id = p.id AND t7.meta_key = 'custom field 7'
LEFT JOIN test_meta AS t8 ON t8.related_id = p.id AND t8.meta_key = 'custom field 8'
LEFT JOIN test_meta AS t9 ON t9.related_id = p.id AND t9.meta_key = 'custom field 9'
LEFT JOIN test_meta AS t10 ON t10.related_id = p.id AND t10.meta_key = 'custom field 10'
LEFT JOIN test_meta AS t11 ON t11.related_id = p.id AND t11.meta_key = 'custom field 11'
LEFT JOIN test_meta AS t12 ON t12.related_id = p.id AND t12.meta_key = 'custom field 12'
LEFT JOIN test_meta AS t13 ON t13.related_id = p.id AND t13.meta_key = 'custom field 13'
LEFT JOIN test_meta AS t14 ON t14.related_id = p.id AND t14.meta_key = 'custom field 14'
LEFT JOIN test_meta AS t15 ON t15.related_id = p.id AND t15.meta_key = 'custom field 15'
LEFT JOIN test_meta AS t16 ON t16.related_id = p.id AND t16.meta_key = 'custom field 16'
LEFT JOIN test_meta AS t17 ON t17.related_id = p.id AND t17.meta_key = 'custom field 17'
LEFT JOIN test_meta AS t18 ON t18.related_id = p.id AND t18.meta_key = 'custom field 18'
LEFT JOIN test_meta AS t19 ON t19.related_id = p.id AND t19.meta_key = 'custom field 19'
LEFT JOIN test_meta AS t20 ON t20.related_id = p.id AND t20.meta_key = 'custom field 20'
WHERE t19.meta_key = 'custom field 19' AND t19.meta_value LIKE '%59%'
LIMIT 0,20
      • Test Three: Get All Data using Relational Method – Select all Custom Field data
        • Query Time (seconds):
          • 14.057 vs 282.675 (Pods is over 20x less)
        • Queries Used
          • Pods Query 
            • SELECT p.*, t.*
FROM test_data AS p
LEFT JOIN test_tbl AS t ON t.id = p.id
          • CPT Custom Fields Query 
            • SELECT p.*,
t1.meta_value AS custom_field_1,
t2.meta_value AS custom_field_2,
t3.meta_value AS custom_field_3,
t4.meta_value AS custom_field_4,
t5.meta_value AS custom_field_5,
t6.meta_value AS custom_field_6,
t7.meta_value AS custom_field_7,
t8.meta_value AS custom_field_8,
t9.meta_value AS custom_field_9,
t10.meta_value AS custom_field_10,
t11.meta_value AS custom_field_11,
t12.meta_value AS custom_field_12,
t13.meta_value AS custom_field_13,
t14.meta_value AS custom_field_14,
t15.meta_value AS custom_field_15,
t16.meta_value AS custom_field_16,
t17.meta_value AS custom_field_17,
t18.meta_value AS custom_field_18,
t19.meta_value AS custom_field_19,
t20.meta_value AS custom_field_20
FROM test_data AS p
LEFT JOIN test_meta AS t1 ON t1.related_id = p.id AND t1.meta_key = 'custom field 1'
LEFT JOIN test_meta AS t2 ON t2.related_id = p.id AND t2.meta_key = 'custom field 2'
LEFT JOIN test_meta AS t3 ON t3.related_id = p.id AND t3.meta_key = 'custom field 3'
LEFT JOIN test_meta AS t4 ON t4.related_id = p.id AND t4.meta_key = 'custom field 4'
LEFT JOIN test_meta AS t5 ON t5.related_id = p.id AND t5.meta_key = 'custom field 5'
LEFT JOIN test_meta AS t6 ON t6.related_id = p.id AND t6.meta_key = 'custom field 6'
LEFT JOIN test_meta AS t7 ON t7.related_id = p.id AND t7.meta_key = 'custom field 7'
LEFT JOIN test_meta AS t8 ON t8.related_id = p.id AND t8.meta_key = 'custom field 8'
LEFT JOIN test_meta AS t9 ON t9.related_id = p.id AND t9.meta_key = 'custom field 9'
LEFT JOIN test_meta AS t10 ON t10.related_id = p.id AND t10.meta_key = 'custom field 10'
LEFT JOIN test_meta AS t11 ON t11.related_id = p.id AND t11.meta_key = 'custom field 11'
LEFT JOIN test_meta AS t12 ON t12.related_id = p.id AND t12.meta_key = 'custom field 12'
LEFT JOIN test_meta AS t13 ON t13.related_id = p.id AND t13.meta_key = 'custom field 13'
LEFT JOIN test_meta AS t14 ON t14.related_id = p.id AND t14.meta_key = 'custom field 14'
LEFT JOIN test_meta AS t15 ON t15.related_id = p.id AND t15.meta_key = 'custom field 15'
LEFT JOIN test_meta AS t16 ON t16.related_id = p.id AND t16.meta_key = 'custom field 16'
LEFT JOIN test_meta AS t17 ON t17.related_id = p.id AND t17.meta_key = 'custom field 17'
LEFT JOIN test_meta AS t18 ON t18.related_id = p.id AND t18.meta_key = 'custom field 18'
LEFT JOIN test_meta AS t19 ON t19.related_id = p.id AND t19.meta_key = 'custom field 19'
LEFT JOIN test_meta AS t20 ON t20.related_id = p.id AND t20.meta_key = 'custom field 20'
      • Test Four: Test One using Native Method and Full Data – Same as Test One in each table’s native method (Relational vs Key / Value) without the max 20 limit
        • Query Time (seconds):
          • 14.117 vs 80.717 (Pods is nearly 6x less)
        • Queries Used
          • Pods Query (Relational) 
            • SELECT p.*, t.*
FROM test_data AS p
LEFT JOIN test_tbl AS t ON t.id = p.id
          • CPT Custom Fields Query (Key / Values) 
            • SELECT p.*, t.*
FROM test_data AS p
LEFT JOIN test_meta AS t ON t.related_id = p.id
      • Test Five: Test Two using Native Method and Full Data – Same as Test Two in each table’s native method (Relational vs Key / Value) without the max 20 limit
        • Query Time (seconds):
          • 2.001 vs 9.591 (Pods is nearly 5x less)
        • Queries Used
          • Pods Query (Relational) 
            • SELECT p.id AS main_id, t.*
FROM test_data AS p
LEFT JOIN test_tbl AS t ON t.id = p.id
WHERE t.custom_field_19 LIKE '%59%'
          • CPT Custom Fields Query (Key / Values) 
            • SELECT p.*, t.*
FROM test_data AS p
LEFT JOIN test_meta AS t ON t.related_id = p.id
LEFT JOIN test_meta AS t19 ON t19.related_id = p.id AND t19.meta_key = 'custom field 19'
WHERE t19.meta_key = 'custom field 19' AND t19.meta_value LIKE '%59%'

    Remember, this is a ‘perfect world’ strictly MySQL Test. WP and Pods actually use slightly different queries and use PHP to handle a bit of the work too. However, from the data storage model aspect, it’s plain to see that there is a big difference, especially as you go further beyond the 50,000 item mark (easily done with revisions, posts, pages, media, menus, etc.. on a medium or large site). Custom Fields are great for simple stuff, but with content types you need to be sure you’re putting your data in the best place for performance and keep the long-term big picture in mind. This test covers the MySQL aspect of course, there are other areas that I will test in the near future.

    Also, this test does not account for Object Caching on the PHP level, which increases performance all around.

     

Wordpress Cloud Hosting