When you add a button to your app and point it at WordPress content, 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 look similar in the dropdown, and all four ultimately render WordPress content inside the app. But they differ in two ways that decide which one is correct for a given button: what you select when you configure it, and what shape of data the button hands to the app. Pick the wrong one and you will get a single article where you wanted a list, an unstyled wall of text where you wanted a browsable feed, or a button that links out to the web when you wanted content rendered natively.

This article explains the four types side by side so you can choose deliberately.

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

The cleanest way to keep these straight is to ask one question first:

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

That splits the four types into two pairs.

Single-item buttons render exactly one thing. You pick the specific page or post when you build the app, and that is what every user sees.

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

List buttons render a feed of posts drawn from a category. The user sees a scrollable list and taps a row to read the full item.

• 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 want one item or a list, you only have to choose between two options instead of four.

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

Both of these render a single item natively in the app, and both deliver the item’s featured image when it has one. What they share is scope — one page or one post. Under the hood, though, they treat the body text differently:

• 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 the 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.

Each is bound to the single page or post you selected, plus its featured image (when present). Neither one produces a list, and neither one updates “by itself.” If you publish a newer Post, a WordPress Post Content button still points at the original item you chose until you change it.

One technical difference worth knowing: WordPress Post Content sends the post’s raw body, transliterated toward plain ASCII (smart quotes and similar characters are converted), and does not run it through the_content — so shortcode- or embed-driven content will not render, and special typographic characters may look different in the app than 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 pulls the most recent published posts in that category (newest first) to build the list. For each post in the list, both types deliver the title, the featured image, the post’s subcategories, and the full rendered content.

So why two types? Because they package each row differently, and that changes what the app can do when a user taps a post.

WordPress Post Category — content-first list

Each row carries the post’s content along with it. The list and the article text travel together to the app, so tapping a row can render the full post natively without another round-trip. This is the type to reach for when you want a self-contained, native reading experience: a news feed, a blog, a “Latest Articles” tab where users browse and read entirely inside 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 suits flows where a tapped post may open its web page (in an in-app browser), where you want author/date bylines shown in the list, or where precise image layout and category artwork matter. It is the heavier, more presentation-rich cousin of the plain Category type.

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 — keep that in mind for very large categories.

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

• The four types above are part of the larger family of content types you can assign to a button. Others point at products, forms, web URLs, and custom screens rather than WordPress pages and posts.
• All four respect WordPress publishing state — only published pages, posts, and categories appear, and unpublished or draft items will not show in the app.
• 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 — including the failure modes. (The WordPress Post Content type is the exception: it sends the raw post body, so shortcodes and embeds are not expanded.) Shortcodes that emit web-only markup (complex iframes, JavaScript-heavy embeds) can look broken on a device even though they render fine in a browser.
• The two list types pair naturally with a detail screen: a category list shows rows, and tapping a row opens the full post. The Post Category type can render that detail natively from the content it already carries; the Post Category URLs type additionally gives you the option of opening the post’s web page.

Note on terminology

In some older reference material and in the underlying code, the page/post single-item type is sometimes described together as one “WP Content” idea. In the app builder today they are two distinct dropdown choices — WordPress Page Content (Pages only) and WordPress Post Content (Posts only) — and that is the distinction that matters when you are choosing a button type. This article follows the builder’s labels.

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