How to design the “Easy” output

Here is another tutorial focusing on the work with Easy plugin.

Once you learn few tricks how to show the content of your website on the front-end (the publicly visible side of your website) you might wonder how to design it.
Yes if you play with the Easy it somehow follows the rules of the webdesign automatically but not always, indeed.
How comes that it matches the actual template and why sometimes not? How can you bend the Easy output to follow your design rules?

Will look on to that.

The basics (following the WP standards)

Easy is solely based on WordPress template tags and functions. No extra “hocus pokus” . What makes the the Easy unique is its approach.
The idea behind the Easy plugin is to make stable UI (User interface) for common work we do when making (programming) websites repeatedly with each new project.
Like you have to make the loop, show the titles, images, sort them out, fix the common fix the common problems with pagination and all other routine work. All that is the everyday bread of all of us who program the WordPress webs.
Why we should do it again and again when we have done it already?

No we shouldn’t.

As I mentioned Easy is based on the WordPress standards. One of the standards is the WordPress body, post, widget and other classes generated automatically when you create the template. These classes are generated automatically for each common object.

For example, when you iterate through the last ten posts on your blog each div surrounding the post has class filled with something like:

post-247 post type-post status-publish format-standard hentry category-easy content

Lets translate it in to human readable language.
The class says; this is post with ID 247, the post type is post, the post is published no extra format defined. The “hentry” is common WordPress class used in that place, each post content is wrapped by that. The post is in category “easy”  and it is the content of the post.
This structure is to be found on all templates that uses the WP standad class functions.

That’s why the output made by Easy widget follows the template rules.

And because Easy is widget, it follows the widget classes and also the structure you define when you register the widget in the functions.php or where ever you do it.

Advance (your own rules)

You might notice that each Easy widget has some input boxes in its top area and each View brick has its own field for its class.

Will skip the General part first and will start with the easier part, with the class input in the brick.
As you can see on the picture on its left bottom side the brick has a field with the grayed text “custom class” Yep that’s the place where you write the name of your custom class.
Let say we want to have the post title generated by this widget red for example. I know it is a stupid example but clear.
You can easily type there

my_red_title

and in the CSS, most likely in the style.css in your template write

.my_red_title{color:red}

Once you  save the widget and have that declaration in your CSS or you make one. Refresh the page. Done.
You should see the title(s) red. If not, you did something wrong or there is something in the CSS that beats your custom class.

If you want to make it more specific, because you want to differentiate this title(s) from the other titles made by another widget write there additional classes and separate them by spaces as you would normally do when programming the HTML.

my_red_title widget_1

You see no extra tricks needed.
This way you can wrap each View brick in your own class and design the output to your needs.
That is all for bricks.

 

Here comes the “confusing part”. It might be confusing, but not because of me, but because of the nature of the task.

In the General part you can see 3 fields.
Select box, input box with gray text “row” and input box named “column”.

If you let it as is “the default scaffolding” the widget will obediently follow the scaffolding rule you or the designer set up when registered the widget (function.php or else).
The “row” and “column” input can be left empty.
If you check the structure by the Firebug or Chrome Inspector, you’ll see that the whole output is wrapped in some divs with some class, and if you do not need your own class there, just skin those.

If you want your very own classes for your own purposes you have to use one of the other options.
Second option is “One per row“. What that means?
It means that the whole widget output will be wrapped in the two divs at once. You can add your own class to the top most of them in the “row” input and the inner div will be enhanced by the class from the “column” input.
Why do we need the output to be wrapped in two divs at once? Well there are situations when you need it. If you don’t we still have another scaffolding chance.

Next option is “Many per row“. This is probably the most used scaffolding structure.
In this case the whole widget will be wrapped in one div “row” and each iterated post (or what ever you iterate) will be wrapped by extra div with class from “column” input.
Remember each View brick has its own class, so you can really design every aspect of each output as you like.

note: The “main” div in the widget structure is always filled with the default WordPress classes, so we are standardized no matter what.

These pictures might help you to understand the aforementioned structure options.

Default

One per row

Many per row