Point a button at WordPress content and MAM Suite asks you to choose a content type. Four of those types read from your WordPress site:

• WordPress Page Content
• WordPress Post Content
• WordPress Post Category
• WordPress Post Category URLs

They sit right next to each other in the dropdown, and all four end up rendering WordPress content inside the app — so it’s easy to grab the wrong one. What actually sets them apart is what you select when you configure the button and what shape of data it hands to the app. Get the mismatch wrong and you’ll end up with a single article where you wanted a scrollable list, a plain wall of text where you wanted a styled feed, or a button that kicks users out to the web when you wanted everything to stay native.

This article walks through all four side by side so you can pick the right one on purpose, not by guessing.

The mental model: one item vs. a list of items

The easiest way to keep these four straight is to ask yourself one question before anything else:

Does this button show one piece of content, or a list the user scrolls and taps into?

That single question splits the four types into two neat pairs.

Single-item buttons render exactly one thing. You pick the specific page or post yourself when you build the app, and that’s what every user sees — no matter what else gets published later.

• WordPress Page Content — one WordPress Page.
• WordPress Post Content — one WordPress Post.

List buttons render a feed of posts drawn from a category. Users see a scrollable list and tap into whichever row catches their eye.

• WordPress Post Category — a list of posts from a category, with full content delivered to the app.
• WordPress Post Category URLs — a list of posts from a category, with each post’s web URL (and richer per-post metadata) delivered to the app.

Once you know whether you’re after one item or a list, you’ve already cut your decision down from four options to two.

WordPress Page vs. WordPress Post (the single-item pair)

Both of these render a single item natively in the app, and both bring along the item’s featured image when it has one. Where they’re identical is scope — one page, one post. Where they part ways is how each one handles the body text:

• WordPress Page Content runs the page body through WordPress’s normal the_content filter, so shortcodes, embeds, and content filters all process as they would on the website, then hands the resulting HTML to the app.
• WordPress Post Content sends the post’s raw body text instead, normalized toward plain ASCII — it does not run the body through the_content, so shortcodes and embeds are not expanded (see the note below).

The other difference is which WordPress content type you can pick from:

In practice, this choice mirrors how you already think about Pages vs. Posts in WordPress:

• Use WordPress Page Content for evergreen, standalone screens — About Us, Terms, a Welcome page, store hours, an FAQ you maintain as a Page.
• Use WordPress Post Content when the single screen you want to surface happens to be a Post rather than a Page — for example, pinning one specific announcement or article to a button.

Whichever you pick, the button stays locked to that single page or post (plus its featured image, when it has one). Neither type produces a list, and neither updates on its own — publish a newer Post and a WordPress Post Content button keeps pointing at the original item you chose, until you go back and change it.

Worth knowing: WordPress Post Content sends the post’s raw body, transliterated toward plain ASCII (smart quotes and similar characters get converted), and skips the_content entirely — so shortcode- or embed-driven content won’t render, and special typographic characters may look a little different in the app than they do on the web. WordPress Page Content instead delivers the fully the_content-filtered HTML. If a screen needs shortcodes, embeds, or exact typography, build it as a Page.

WordPress Post Category vs. WordPress Post Category URLs (the list pair)

Both of these turn a category into a scrollable list of posts in the app. You pick the category when you configure the button, and MAM Suite fills the list with the most recent published posts in that category, newest first. For every post in the list, both types deliver the title, the featured image, the post’s subcategories, and the full rendered content.

So why have two types at all? Because they package each row differently — and that difference decides what the app can actually do when someone taps a post.

WordPress Post Category — content-first list

Each row carries the post’s content right along with it. The list and the article text travel together to the app, so tapping a row renders the full post natively — no extra trip back to your site needed. Reach for this type when you want a self-contained, native reading experience: a news feed, a blog, a “Latest Articles” tab where people browse and read without ever leaving the app.

WordPress Post Category URLs — link-and-metadata-rich list

This type delivers everything the plain Category type does, plus a per-post web URL and additional metadata for each row:

• A url for each post (its WordPress permalink, tagged so the site knows the request came from the app).
• The post author’s display name.
• The post’s last-modified date, formatted for display.
• Featured-image dimensions (width and height) for image files, so the app can lay out thumbnails precisely.
• Richer subcategory info, including category images when your theme provides them.
• A fallback placeholder image when a post has no featured image, if you have configured one.

Because each row includes a real URL, this type is the one to reach for when a tapped post should open its web page in an in-app browser, when you want author and date bylines showing in the list, or when precise image layout and category artwork matter. Think of it as the plain Category type’s heavier, more presentation-rich cousin.

One thing to keep in mind: both list types fetch a bounded number of posts per request — the most recent posts in the category — rather than the entire archive. A category with thousands of posts will surface its newest items, not all of them, so plan for that if one of your categories is especially large.

A quick decision guide

Work top to bottom and stop at the first match:

1. Do you want a list of posts the user scrolls and taps into?

   • No, just one screen → go to step 2.
   • Yes → go to step 3.

2. Single item — is it a WordPress Page or a Post?

   • A Page (About, Terms, FAQ, Welcome) → WordPress Page Content.
   • A Post (one specific article or announcement) → WordPress Post Content.

3. List — do you need per-post web URLs, author bylines, dates, or precise image/category artwork?

   • No, just a clean native feed of articles → WordPress Post Category.
   • Yes, you need URLs / author / date / image dimensions / category images → WordPress Post Category URLs.

How this connects to the rest of the app

• These four types are part of a larger family of content types you can assign to a button — others point at products, forms, web URLs, and custom screens instead of WordPress pages and posts.
• All four respect WordPress’s publishing state: only published pages, posts, and categories show up, so unpublished or draft items stay out of the app the way you’d expect.
• The Page type and both Category types run post bodies through WordPress’s standard the_content filter, so anything that depends on a plugin or shortcode running on the website behaves the same way in the app — failure modes included. (WordPress Post Content is the one exception: it sends the raw post body, so shortcodes and embeds don’t get expanded.) Shortcodes that emit web-only markup — complex iframes, JavaScript-heavy embeds — can end up looking broken on a device even when they render just fine in a browser.
• The two list types pair naturally with a detail screen: the category list shows rows, and tapping one opens the full post. Post Category can render that detail natively straight from the content it already carries; Post Category URLs gives you that same option, plus the choice to open the post’s web page instead.

Note on terminology

You may run across older reference material, or the underlying code, that lumps the page/post single-item type together as one “WP Content” idea. In today’s app builder they’re two distinct dropdown choices — WordPress Page Content (Pages only) and WordPress Post Content (Posts only) — and that’s the distinction that actually matters when you’re choosing a button type. This article sticks with the builder’s labels throughout.

Related

• Content classes overview
• Content class: WordPress Page Content
• Content class: WordPress Post Content
• Content class: WordPress Post Category
• Content class: WordPress Post Category URL