Posts VS Pages

Understand the main differences between posts and pages, which one to use, when and why.

Posts or Pages?

Technical Differences

Relevant Examples

Should it be a Post or a Page?

Is organization of this content and its entries important?
Are you going to want to add more of the same kind of content in the future?

Will the entries have generally the same layout with different text or images?
Would you want entries of this content to be archivable or searchable?

Are you expecting to be able to categorize and sort through all the entries?
Are you expecting to be able to tag the entries and filter through them?

If even one of these questions were answered with a "yes" you need to use posts!

What Do you mean, "Posts" ... isn't that a blog?

When people hear the word "Posts," they think it means "Blog." This isn't necessarily true. Blogs are a kind of post.

All blogs are posts, but not all posts are blogs.

For Example:

Products are posts with extra fields
Job listings are posts
Property listings are posts
Events are posts

The similarities between blogs, products, job listings, property listings and events are:

There's a page that shows all of them - Every time you add a new one of them, it appends to the list on their archive once published
They are easily searchable and sortable
You can place them in categories and you can add tags to them
Each category and tag archive page lists all the posts that fit that category or tag by their publish date

Technical Differences

What sets "posts" apart from "pages"?

Static vs Dynamic Content –
By definition, pages are static one-off publications while posts are chronologically listed entries.
Taxonomy –
Only posts have categories and tags, pages don’t. You Can Categorize, organize and sort Posts, but Pages Are Hierarchical. You can't see an archive of pages and you cant sort or filter through them the same way you can with posts.
Hierarchy –
Only pages have a hierarchy. Pages, cannot use categories or tags. You can make one page a “parent” and another page a “child”. This helps you to group related pages together - it doesn't help you sort, categorize or tag them.

Pages	Posts
static, one-off publications	dynamic, chronologically-listed entries
no archive, no sorting, no filtering	has an archive, can be sorted and filtered
have hierarchy	have taxonomy
can be navigated from a menu	can be navigated via a feed

so... Keeping the above Differences In mind...

Posts do not equal pages - they take less effort to add to, they take less time to build, they are different.

When adding a new PAGE
Every time you add a new page, you must open the builder and build out its content, add modules and style items on that page.
When editing the layout of a PAGE or multiple pages
If you want to make a change to an item that's used in a page's layout or across multiple pages, you will have to individually edit each page and fix that item in all instances, one at a time.

When adding a new POST
A singular themer layout is created once. Posts are added by placing content in the editor and publishing. All posts will automatically assume the layout of the themer template.
When editing a POST's layout
If you want to make a change to a layout item across all posts, you only have to edit the themer layout, make the change once and it will apply to all posts.

Relevant Examples

Scenario: Team Members

The customer's request: "Place 4 team members on a page. Each team member should have an image, their designation and a link to their full biography. The team is growing with the intent to add more team members in the future." How would you tell the builder to set this up?

Add the team members using a teams module placed in 4 columns. Create a "page" for each team member's bio. Link the pages to the team member modules for each.

NO. That means every time they add a new team member, they'd have to add a new column with a module in it and create a new page for each team member, copy the layout from another team member and style it.

There will be a time when they have several team members and a separate page for each team member containing their bio. If they wanted to make a change to the way the bios are laid out, they'd have to make that change individually on every single team member's page, one at a time.

Create 4 columns on a page and place a team member in each. Add the team members using a modal popup module containing their bio.

NO. Popups are bad m'kay. Also that means every time they add a team member, they will have to add a new column with a popup module holding the bio.

There will be a time when they have 12 team members and will want to add another, but the page will refuse to load because of all the scripts running from all the popups and all the content within each popup. That’s a poor experience for everyone and will end up having to get rebuilt.

Add the team members in 4 columns on a page. Create rows below for each team member's bio and anchor-link them to the corresponding team members above.

NO. This means every time they add a new team member, they'd have to add a new column with a module in it and create a new row on the page to anchor it to.

There will be a time when they have several team members on the page with a row for each team member containing their bio, making the page extremely long, very slow to load and extremely difficult to add to. It will end up having to get rebuilt.

Create a posts category for "team members." Add each team member as a post. Use a posts module to show all team members on a page in 4 columns.

YES. This is the most efficient way to arrange the content requested and will result in the best experience for anyone adding team members in the future.

The builder will create a category for team members and add all team members as posts to the category. They can add custom fields to posts e.g. for the team member's designation. They can create a themer layout for all posts that are categorized under "team members." The builder can add a posts module to a page in however many columns needed, and tell the module to show only posts that are categorized as "team members."

Every time a team member needs to be added, they will be added as a post under the category "team members." Upon publish, it will automatically assume the layout used by all team members. It will also automatically append to the posts module added to the main page without any manual work.

Scenario: Testimonials

The customer's request: "I would like a testimonial slider on my homepage with about 10 testimonials to start. They are about a paragraph in length and i want them to all be the same height in the slider. I want the person's name under the testimonial. I plan to add more when I get them from my Facebook." How would you tell the builder to set this up?

Add the 10 testimonials into a testimonial slider module on the homepage.

NO. You'd think this is the right thing to do...but because of the details the customer gave you, a regular testimonial slider would probably not be a good idea. Here's why:

10 testimonials are kind of a lot to put in a testimonial slider already, and the customer plans to add more.
The testimonials are about a paragraph long each. People won't be able to read through them if they move on to the next one every 5 seconds.
The more testimonials you add to the slider module, the slower it will load and the harder it will be to add more in the future.
If the module breaks because of overload, all those testimonials are gone and will have to be rebuilt.

Add 5 testimonials into a testimonial slider on the homepage. Add a page with all the testimonials listed. Add a "view all" link by the slider and link to that page.

MAYBE (You're on the right track though). Its probably a good idea to put a few on the homepage in the slider, and put the rest on a new page for all testimonials. Considering the length of each testimonial and that too many of them will overload the module, this is best. BUT here are the issues this can bring:

Every time a new testimonial is added, the testimonials page must be edited, the layout of the previous testimonial must be manually copied and the new one must be entered.
The testimonial slider on the homepage does not connect to the page and will not automatically update. If the customer wishes to show the latest few, the slider will also have to be manually edited and updated with the new testimonial.
There will be a time when the page showing all testimonials will have so many that it may get hard to edit or add to.

Create a posts category for "testimonials" - add each as a post. Use a post carousel to show the latest few on the homepage. Link a button to "view all" testimonials.

YES. This is the most efficient way to arrange the content requested and will result in the best experience for anyone adding testimonials in the future. Here's how it will work:

The builder will create a category for testimonials and add all testimonials as posts to the category. They can add the testimonial itself to the post editor and the person's name as the title.
They can create a themer layout for all posts that are categorized under "testimonials." They can also create a themer layout for the category "testimonials" which can be linked to the "view all" button as it will show all testimonial posts categorized under it.
The builder can then add a posts carousel to the homepage and set it to chronologically show the latest 5 or 10 even, without bogging down the page.
Every time a testimonial needs to be added, they will be added as a post under the category "testimonials." Upon publish, it will automatically assume the layout used by all testimonials. It will also automatically append to the category page and to the front of the posts carousel module on the homepage without any manual work.