The Control slot lets you restrict the View content to be shown on certain template type, or on post/page IDs or any custom post type ID and much much more.


Control bricks designates where the content you have built in the View slot will be shown. You can also determine for how many post / pages or any custom types you want to loop through.
You can filter the content by many control filters. For example, if you want to see only posts from this or that category, or this or that meta value, or filter pages from the same level of the currently seen page and many  more.

All the logic behind the Control bricks is nothing super special, no magic what so ever. It just make use of the WordPress built in query logic plus couple other WordPress logic and hooks.

The purpose of Easy is to make the WordPress easy manageable. Once you learn the Easy logic, you can fluently jump in the WordPress tags and you find the same structure there.
Easy is the ideal tool how to get understand how WordPress works. Easy can be taken as sort of graphical learning tool of the WordPress structure and logic.

Remember the output, the View content will be show only when all the control conditions are met!

Hajime mashte …

By date



Filter the result by date.

  • Year (num.)
  • month (num.)
  • week (num.)
  • day (num.)
  • before – Date to retrieve posts before. Accepts strtotime()-compatible string, or array of ‘year’, ‘month’, ‘day’
  • after – Date to retrieve posts after. Accepts strtotime()-compatible string, or array of ‘year’, ‘month’, ‘day’

(before and after has many possibilities, you can describe your self plainly like: 1 day before, 1 week ago… check the full description here )


Multiple allowed

Category filter

Show only post in category.

  • category – post under one any of the given category will pass
  • category__and – only posts with all given categories will pass
  • category__in – category belongign under category will pass
  • category__not_in – post not belonging to a category will pass

Cat ID

Category IDs separated by comma.


Debug brick is an extra animal. It does not filter anything!
The debug brick is grate when you want to check what filter have you actually build and compare it with the result on the front-end.
The debug output is shown right before the widget output so you are not confused when using multiple Easy widgets. You can even compare settings among widgets on the same page.

What is special on this debugging tool is that it debugs only the bricks which are above the debug brick. That way you can debug the query step by step. …sweet huh?

If you want to debug all control settings of the particular widget put the debug on the end of the slot ;)

Exclude actual post/page

Excludes currently visible post or page from current widget loop.

For actual post/page

This brick has no settings. It simply catches the post ID of the actually visible post/page or your custom post type, and shows the content defined in the Control slot.

note: If the template has some incorrectly finished custom queries it might mingle with the actual query and the “guess” post ID might not match.

Hierarchy based


  • Pages from the same level as current page – It returns all the pages (if there are no other restrictions) from the same hierarchy level as the currently seen page
  • Pages from the same level as given ID – only one ID is accepted
  • Child pages of current page 
  • Child pages of given ID – only one ID is accepted


Define the page ID. makes sense only for for all choices …of given ID

Exclude current

Make sense for choices: .. from the same level. Then it returns all pages from the hierarchy level but the reference.


Meta filter. Lets you loop through posts only when they have or have not this or that custom field.

Meta key

Name of the custom field

Meta value

What value you are checking.

Comparison type

On what logic the value should be approached .. as like string, or number, or date etc.

  • CHAR
  • DATE
  • .. (default CHAR)

Comparison operator

Here you set if the meta have to be same as defined key, or not. If the value should exists etc.

  • =
  • !=
  • <=
  • >=
  • ..


If you use more then one meta filter here you define how they relate with each other.
Full explanation how it works in the WordPress codex.


What you think it does?
Right, by this brick you can determine the maximum number of posts / pages or custom post types it should return.


For instance; if you want to skip the first post then you set the offset 1, and so on and so forth..
Note: Setting offset parameter will ignore the paged parameter. 



Set the order


  • Descendingly
  • Ascendingly

Order by

  • none
  • title
  • date
  • modified
  • rand
  • comment_count
  • menu_order
  • parent
  • meta_value
  • meta_value_num

Meta key

Name of the meta key you would like to sort out the result (in case of Order by: meta_value or meta_value_num)


Allow the content to be show only to certain user groups.


  • Subscriber
  • Contributor
  • Author
  • Editor
  • Administrator

Grate if you want to play on live site and do not want to show common users your half work. In that case set your user level Admin I suppose and play as long as you like. Once done switch it for others as well or remove the brick completely.



Post2Post is a integration of the gorgeous  Post2Post plugin.
With this brick you can catch all connected post/pages/whatever you have and show for it the content pieces as you normally would for post/pages etc.
Just specify the connection type and you are set.

note: Be aware that you have to set up your connection types as noted in the plugin wiki page.

Post type

This is one of the most important control brick!

Here you set what post type you want to see.

Show / hide on ID

Multiple allowed

The output will or will not be shown when the user see the post of page with given ID.

Multiple ID allowed. Separate them by comma.

Show/hide based on hierarchy

This brick works as a resistor.. If the conditions are meet it will let the widget create its VIEW content.
(unlike the “Hierarchy based” brick which selects the content based on the hierarchical parameters.)

scenario example:
Say you would like to show some content only when the user visits a concrete page and also it’s children pages “no matter” how deep the structure is.
The settings are one by one; show, “on child pages of defined IDs”, the ID or IDs of pages (which possibly have some child pages) would like to see the content on. Set the depth of level how far you want to go in the hierarchy (default 1 level). And check if it has to happen also for the given page or only for the child pages. You are done!

Show or Hide

Decide if you would like to see the content or hide the content if the parameters are meet.

Show on

If you want to look up or down the structure… look for child pages, or parent pages.

Page IDs

This is the most important value. Here you set the referenced page IDs.


How deep you want to search through the hierarchy.

Include/Exclude given IDs

Decide if you would like to show or hide the content also on the reference IDs

The post type has to be hierarchical obviously.

Show / hide on Template types

Multiple bricks allowed.

Restrict the view content for the listed view types.

Show only by ID

Show the content of give post/page/.. ID.


Show based on the status


  • Publish
  • draft
  • pending
  •  future
  • ….
  • any

Default WordPress post types are:

  • post
  • page
  • attachment
  • ..
  • any (retrieves any type except revisions and types with ‘exclude_from_search’ set to true.)


Multiple allowed

Name of the taxonomy

The nice name (slug) of the taxonomy. Again, the category is a taxonomy type.

Term IDs

ID of the terms. Separated by comma.


Set what logic has to be applied for terms.

  • AND – pass if one of the IDs match
  • IN – pass only if all IDs match
  • NOT IN – Do not pass if IDs match


  • AND – if multiple used the must both be true (default)
  • OR – if multiple used one or the other must match

Taxonomy match

This brick checks if the main loop* has any term under the defined taxonomy (category, post_tag, ..). The widget will find any post/page/custom type under found terms (or not, depends on the operator and relation).

If you use a taxonomy “category” the widget can get posts from the same category as the actual post** is (with operator IN indeed).

* – main loop – is the post shown in single view, or the most recent one in archive view.
** – actual post (post, page, custom type) 

Taxonomy name

The name of the desired taxonomy you would like match the widget against.


Set what logic has to be applied for terms.

  • AND – pass if one of the IDs match
  • IN – pass only if all IDs match
  • NOT IN – Do not pass if IDs match


  • AND – if multiple used the must both be true (default)
  • OR – if multiple used one or the other must match