Matt Radford

Messing with links since <blink>

Notes from #wcuk – @jonnya

Published on 

Designing with Data

Content detection can be brittle (limited)
– i.e. detecting page IDs

  • More creative flexibility
  • Bespoke editing
  • Accomodate future development

Structure data

– content & design elements
-** functionality?**
What needs to be editable?
– e.g. don’t let clients alter theme colours

What needs to be queried?
– do you need to get to data attributes to alter what is displayed on the page?

How to achieve the design requirements?

e.g. instead of creating different templates for differently coloured pages, why not use a custom field that is pre-poulated in the edit screen, which targets a class

Data attributes

  • Page/post hierarchy
  • Post types/formats
  • Tags/categories
  • Custom tax.
  • Custom fields
  • Images/attachments

Design attributes:

General static(isj) design/structure
Editable WP menus
Editable Widget areas
– Jonny has a plugin to remove widgets, to leave in only the only that they need, and not allow breaking
Archive views

Sophistication using template hierarchy, esp taxonomies

Content Detection

– body and post class
– post id
– query variables
is_page() etc
– has post image
– has widgets

Can alter body class with a filter, add a custom name.
– all sort of content detection, then add a body class

Content detection with PHP
e.g. Displaying a fallback image if there’s no post_thumbnail.
(I do that already – sweet!)

get_ on a function returns it rather than echos output, e.g. get_the_post_thumbnail($post_id) rather than the_post_thumbnail($post_id)

is_active_sidebar( $name-or-id)
(has a user dragged widgets into an active widget area?)

Super-powerful. Don’t let it mess with the admin!

What about data input?

Validate user input
Always escape on output
Escape late
Use $wpdb class for the database

More coming:

WP metabox API