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 …
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 )
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
Category IDs separated by comma.
cat1, birds, cats, potatos
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.
- 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
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.
Name of the custom field
What value you are checking.
On what logic the value should be approached .. as like string, or number, or date etc.
- .. (default CHAR)
Here you set if the meta have to be same as defined key, or not. If the value should exists etc.
- IS LIKE
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.
Show / hide on ID
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.)
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) ..you 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.
If you want to look up or down the structure… look for child pages, or parent pages.
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.
Set the order
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.
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.
This is one of the most important control brick!
Here you set what post type you want to see.
Show based on the status
Default WordPress post types are:
- any (retrieves any type except revisions and types with ‘exclude_from_search’ set to true.)
Name of the taxonomy
The nice name (slug) of the taxonomy. Again, the category is a taxonomy type.
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
This brick checks if the main loop* if it has any term under the defined taxonomy. 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 last one in archive view.
** – actual post (post, page, custom type)
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