Presentation Notes on Sunrise for Metamorphosis Notes (WordPress Post Meta Team)

Post Meta Meeting

Tuesday December 3rd & 10th 2013

What

Where

Who

  • Mike Schinkel
  • Micah Wood (wpcholar)
  • Andrey (Rarst) Savchenko
  • Taras Mankovski

Why

  • We built a company’s products
    • Platform for building large lawfirm website
  • Client didn’t respond well to: "Well we can’t (easily) to do"

Architecture

  • Focused on programmer productivity

    • Source code solution for version control
    • Sunrise was on 2nd generation code
    • ASIDE: We are now on 5th generation code style
      • See: https://github.com/newclarity/exowp
      • Exo is an MVC Skeleton for WordPress, w/mixins
        • Not Forms/Fields, but lower level for MVC
        • Redesign of Sunrise would follow Exo architecture
  • Core OOP layer

    • Fields
    • Forms
    • etc.
  • Sitebuilder layer

    • register_form()
    • register_field()
    • Virtual Field Types
  • Themer layer

    • get_field()
    • the_field()

Admin User Interface

  • Should be able to completely replace metaboxes in admin UI
    • Especially Title, URL and TinyMCE editor
  • Most common use-case; a single metabox
    • Optional "modules" should be able to add to that metabox
      • vs. adding another metabox.
    • Adding to metabox is not hard with Sunrise architecture.

Storage Format

  • For Post Meta Key & Value
  • See SQL Query

Field Features Objects

Fields generate collection of HTML elements.

Made sense to create "field feature" class to subclass because all shared so much code.

  • Entry
  • Label
  • Help
  • InfoBox
  • Message

get_field()/the_field()

  • Simple naming
  • Filters:

    • 'pre_get_field'
    • 'get_field'
    • 'empty_field'
    • 'the_field'
  • Virtual fields

    • "nested dolls"
  • Issue to address with naming conventions or $args type: Return values of string/numeric vs. object/array vs. HTML

Virtual Fields

  • Especially useful to output Schema.org valid markup
  • Postal Address: ‘postal_address’
    • Stored as:
      • ’street’
      • ‘city’
      • ’state’
      • ‘zip’
      • ‘country’

Virtual Field Types

  • "Real" types defined by class
  • Virtual types based on existing type w/set of arguments.
    • Like cascading properties of CSS

Storage Types

Field storage defined by field, themer need not no storage location.

  • Meta storage
  • Core storage
  • Table storage (custom sql)
  • Taxonomy (term) storage
  • Future/Plugins
    • Pods
    • MongoDB
    • Redis
    • Amazon S3
    • Other…?

Dynamic Forms within Forms

  • Form Selector Field
  • One field could display a form within a field
  • Created a ‘form_type’ meta field to control which form type

Repeating Fields

  • Overuse leads to madness
  • Should support simpler use-cases
  • Repeating should be in core framework, not its own field type
  • Complex use-cases should use object/post relationships (hint/hint)

Other Considerations

  • Minimize nested arrays when initializing
  • Separate Declaration from Fixup
  • Multiple register_field() vs. one register_fields()
  • Then there is MVC + Mixins…

Demo Code

1 comment so far ↓

#1 Pods project status update | Pods Framework on 12.13.13 at 5:55am

[…] project and collaborating with Mike Schinkel who has been sharing his experience with developing Sunrise, specifically which he’s done heavy architecting for that Pods could really really use in […]

Leave a Comment