Public Roadmaps, Reactions and Feature Requests

Feature ideas arrive from everywhere: a support ticket, a reply to a release email, a comment under a changelog. Nobody outside your team can see what is already planned, so the same idea comes in again and again, and the people who asked never find out whether it shipped.

Core Support Roadmaps puts that list on your own site. Each product gets a public roadmap with its items in four stages, at /roadmap/ unless you choose another address. Visitors give each item a thumbs up or down and comment on it, and the ideas they send wait for your review before anyone else sees them.

You plan on one board in wp-admin: readers’ suggestions in their own column, your items by stage beside them, and a drag to move anything.

Roadmaps are a module and start switched off. Turn them on under Settings → Modules, open Core Support → Roadmap, create a roadmap for each product, then add your own items and the feature requests people send.

Turn On Roadmaps

Roadmaps are off on a new install. While the module is off, Core Support registers none of it: no roadmap post type, no /roadmap/ addresses, no admin screens and no styles or scripts. A site that doesn’t use roadmaps pays nothing for them.

1. Go to Core Support → Settings → Modules.
2. Switch on Roadmaps.
3. Choose Save modules.

The Modules card then shows links to Roadmap board, Roadmaps, Roadmap settings and View roadmap. The admin menu gains Core Support → Roadmap, Settings gains a Roadmaps tab, and Settings → Header and footer gains a Roadmap pages card.

If a page on your site already uses the roadmap’s address, the Modules card warns you: while Roadmaps are on, that address shows the roadmap instead of the page. Change the page’s slug, or give the roadmap another address.

You can switch the module off again at any time. The roadmap pages and the admin screens go away, and your roadmaps, items, reactions and settings stay in the database for when you switch it back on. The privacy tools keep finding feature requests and reactions while it is off.

Choose the Roadmap’s Address

The roadmap lives at /roadmap/ until you change it. This guide uses /roadmap/ in its examples.

1. Go to Core Support → Settings → Roadmaps.
2. Change Roadmap address, such as feedback, ideas or product-roadmap. Use lowercase letters, numbers and hyphens, up to 40 characters.
3. Choose Save settings.

Every roadmap page moves with it: /feedback/, /feedback/{roadmap}/ and /feedback/{roadmap}/{item}/. Links to the old address keep working. They redirect permanently (301) to the same page at the new address, query strings included, so shared links and search results carry over. Core Support remembers your last five addresses.

Some addresses are taken and can’t be saved: WordPress’s own (such as wp-admin, wp-json, feed, page, search, category, tag and author), docs, changelogs and your support portal page’s slug.

The address needs pretty permalinks. With plain permalinks, roadmap pages use addresses such as ?csp_roadmap=stackless whatever you choose here.

Create a Roadmap for Each Product

A roadmap is a group of items, usually one per product. Visitors see every roadmap on /roadmap/ and open one to see its board.

The quickest way is the board. The first time you open Core Support → Roadmap, it asks for your first roadmap’s name and a one-line description. After that, New roadmap above the board adds another.

For every setting, use the full screen:

1. Go to Core Support → Roadmaps.
2. Enter the Name, such as the product’s name.
3. Check the Slug. It becomes the address, so a slug of stackless gives /roadmap/stackless/.
4. Add a Description. It shows under the name on /roadmap/ and at the top of the roadmap’s own page.
5. Optionally add a Product page address. It shows as a Product page button on the roadmap.
6. Set the Order. Lower numbers come first on /roadmap/, and roadmaps with the same number sort by name.
7. Choose Add roadmap.

Four slugs are reserved because they would clash with other addresses under /roadmap/: page, feed, search and general. Core Support adds -roadmap to any of them, when you create a roadmap or edit its slug, so general becomes general-roadmap.

Plan on the Board

Core Support → Roadmap is a board with five columns: Suggestions from readers, then the four stages. Each card shows the item’s title, the start of its text and its thumbs up and down; suggestion cards have no thumbs yet. In the all-roadmaps view, each card also names its roadmap, or says “No roadmap yet”. The Roadmap menu above the board shows one roadmap or all of them, and the board keeps your choice in its address, so you can bookmark a roadmap’s board.

To add an item:

1. Choose Add item at the bottom of a stage column.
2. Type a short title, such as “Export tickets to CSV”, and press Enter to move on to the description.
3. Optionally describe the item: what it does and why it matters. Leave a blank line between paragraphs. It becomes the item’s text, and its start is the summary on the card.
4. With more than one roadmap, check the Roadmap menu. It starts on the roadmap the board shows, and you can pick another one.
5. Choose Add, or press Ctrl+Enter (Cmd+Enter on a Mac). Escape closes the form.

The item is published on the roadmap at once. Someone who can’t publish roadmap items adds a draft instead, marked Draft on its card until someone with that permission chooses Publish.

For more than a few paragraphs, choose the item’s title on the card. It opens in the block editor, where images, lists and other blocks work. An Excerpt there becomes the summary on the public card; without one, the card shows the start of the text.

List view, above the board, opens the classic list of items with Stage, Reactions and Requested by columns. Filter it by stage, or sort by reactions to sort by thumbs up. The board loads the newest 300 items and the newest 300 suggestions; the list view has the rest.

An item needs a roadmap to show on a public board. An item with no roadmap, marked No roadmap yet on the board, is still published at /roadmap/general/{item}/, but no public board lists it.

Roadmap Stages

Every published item sits in one stage, and each stage is a column on the roadmap’s page:

• Under consideration: ideas you are weighing. New feature requests start here.
• Planned: work you have decided to do.
• In progress: work that has started.
• Shipped: work that has been released.

A password-protected item shows its title and reactions on the board, without its summary; its text stays behind the password on its own page.

To move an item, drag its card to another column on the board. Each card also has a Move to menu that does the same from the keyboard. Someone who can edit an item can move it the same way on the public roadmap page: their cards can be dragged between the stage columns and show a Move to menu, while visitors see the board as usual. On the item’s edit screen, the Roadmap box sets the stage too. Moving an item to another roadmap changes its address, and links to the old one redirect to the new one.

Inside a column, the items people like most come first: most thumbs up, then fewest thumbs down, then newest. The Shipped column works differently and shows the most recently updated items first, so the latest release stays at the top.

A roadmap shows up to 400 published items. Past that, the oldest ones are left off the board.

Developers can rename the stages with the core_support_roadmap_stages filter. The keys stay fixed because items store them: considering, planned, in_progress and shipped.

What Visitors See

Roadmap pages are standalone pages in your branding, like the docs and changelog pages. They load only Core Support’s own styles and scripts, plus your own HTML and CSS when the Custom code module is on. wp_head() still runs, so SEO plugins keep setting titles and canonical addresses. The WordPress admin bar doesn’t show on them unless you turn on Settings → Header and footer → Admin bar → Show the admin bar. Signed-in team members see an Edit link on an item’s own page either way.

There are three kinds of roadmap page:

• /roadmap/ lists every roadmap with how many items are in each stage. The Roadmap introduction from Settings → Roadmaps sits at the top, and the Suggest a feature form at the bottom lets the visitor pick a product. Until you add a roadmap, the page says “The roadmap is on its way.” and stays out of search engines.
• /roadmap/{roadmap}/ shows that roadmap’s items in the four stage columns. Each card has the title, a short summary, the reaction buttons and, once people have commented, how many comments it has. The page ends with the Suggest a feature form, which sends ideas to this roadmap unless the visitor picks another product.
• /roadmap/{roadmap}/{item}/ shows one item with its stage, the full text, a “Want this too?” reaction prompt, your share buttons and its comments. Buttons at the bottom lead back to the roadmap and to the form.

Comments

Published items take comments under their text, with the comment form below them. Settings → Roadmaps → Who can comment on roadmap items has three choices:

• Everyone: any visitor can comment. This is the default.
• Signed-in visitors: visitors who aren’t signed in see a Sign in to comment button instead of the form.
• Nobody: hide comments: the comments and the counts on cards disappear from every roadmap page.

Comments are ordinary WordPress comments. Settings → Discussion decides whether they wait for your approval, whether replies are threaded and whether avatars show, and you moderate them under Comments in wp-admin. A visitor whose comment waits for approval sees it marked as such on the item’s page. Pending feature requests and password-protected items show no comments, and a plugin that turns comments off across the site still turns them off here.

Reactions

Each published item takes one reaction per person: a thumbs up or a thumbs down. A visitor can switch to the other one, and a second click on the same button takes it back. Every change updates the item’s totals at once.

Settings → Roadmaps → Who can react with a thumbs up or down has three choices:

• Everyone: any visitor can react.
• Signed-in visitors: visitors who aren’t signed in see the totals, and a click asks them to sign in.
• Nobody: hide reactions: the buttons and totals disappear from every roadmap page.

Signed-in people are known by their account. Everyone else is known by a random token in a cookie named csp_roadmap_voter, which Core Support sets the first time they react and keeps for a year.

A reaction stores a keyed hash of the account or the token, plus the user ID of a signed-in person so the privacy eraser can find it. It never stores a name, an email address or an IP address.

Guest reactions are only as reliable as that cookie. Someone who clears their cookies or opens another browser can react again. If you plan your work from these counts, Signed-in visitors is the wise choice.

Reactions work with page caching. The totals are part of the page, and the fresh totals and the visitor’s own reactions load after the page opens. So a cached roadmap page still shows each visitor their own choice.

Each visitor can react up to 120 times an hour.

In wp-admin, the Reactions column shows the totals, and the Roadmap box on an item shows them once it has at least one reaction.

Feature Requests

The Suggest a feature form takes an idea from a visitor and turns it into a pending roadmap item that only your team can see.

The form asks for:

• Your idea: a short title, 4 to 120 characters. Required.
• Details: what the visitor is trying to do, up to 4,000 characters.
• Name and Email: only from visitors who aren’t signed in. The email address is required, and the form says it is used only to ask about the idea and is never shown on the roadmap. Signed-in visitors send with their account’s name and address.
• Product: the roadmap the idea is for, or “Not sure”. On a roadmap’s own page it starts on that roadmap, and the visitor can choose another one. With a single roadmap, a roadmap’s page sends ideas to it without asking.

While someone types a title on a roadmap’s page, up to 3 items from that page with similar words appear under the field. A prompt asks them to react to one of those instead. This keeps duplicates down without stopping anyone from sending.

After sending, the visitor sees “Thanks! We read every idea. If we plan it, it will appear on this roadmap.” The form needs JavaScript; without it, the form says so.

Two settings shape the form, both under Settings → Roadmaps:

• Who can suggest features: Everyone, Signed-in visitors, or Nobody: hide the form, which also hides the Suggest a feature buttons. With Signed-in visitors, guests see a Sign in to suggest a feature button instead of the form.
• Feature request introduction: the text above the form. Leave it blank to hide it.

Spam stays out in two ways. A hidden field catches bots, which get the same thank-you message while nothing is saved. Each visitor can also send up to 5 requests an hour.

Review and Publish Feature Requests

New requests wait in the Suggestions column on the board, with a count beside Core Support → Roadmap and Core Support in the admin menu. For people who can work tickets and edit roadmap items, the toolbar bell lists the 6 newest under Roadmap suggestions, with a link to the board.

To hear about each one as it arrives, turn on Settings → Team alerts → Alert on new feature requests. It uses the Telegram, Pushover, Discord, Slack or webhook channels you already set up for ticket alerts. To get them by email instead, turn on Email the team about roadmap suggestions and set Send suggestion emails to. Both are off by default.

Each suggestion’s card shows the idea, the start of the details, the sender’s name and email address, and when it arrived. From there:

• Add to roadmap publishes it under Under consideration.
• Drag it to any stage, or use its Add to stage menu, to publish it straight into that stage.
• Decline moves it to the trash.

A request sent with a product chosen already has its roadmap. One sent with “Not sure” has none. With a single roadmap, publishing it from the board puts it on that one. Publishing it from its edit screen keeps the roadmap chosen there. With several, a request with no roadmap shows on every roadmap’s board, and every suggestion’s card has a Roadmap menu: it starts on the roadmap the visitor chose, so you can move the idea to another product as you add it to a stage, and a card with no roadmap asks for one before it can go anywhere.

To tidy a request before it goes public, choose its title on the card to open it:

1. The Requested by box shows the sender’s name and email address, and a View account link for administrators when the sender was signed in.
2. Edit the title and text as needed. Fix a vague title, remove anything personal, or add your own notes for visitors.
3. In the Roadmap box, check the roadmap and choose a stage.
4. Choose Publish to put it on the roadmap.

Pending requests can’t collect reactions, so declining a duplicate loses nothing but its text. A declined request stays in the trash for the usual 30 days, in case you change your mind.

Core Support doesn’t tell the sender when you publish or decline their idea. If you want to follow up, the email address in the Requested by box opens a new message to them. Developers can also hook into the core_support_roadmap_requested action, which receives the new item’s ID.

Link to the Roadmap from Headers and Footers

Settings → Header and footer → Roadmap pages sets the header, footer and share buttons of every roadmap page. The header label starts as “Roadmap”, and the header links start with Docs, Changelog and a Contact support button.

The share buttons show under each item. The header and footer guide covers each field.

{roadmap} links to the roadmap home, at whatever address you chose, from any header or footer link, including the docs, changelog and support portal pages. A few examples:

• Roadmap | {roadmap} | link adds a Roadmap link to a header.
• Stackless roadmap | {roadmap}stackless/ | link goes straight to one roadmap.
• Suggest a feature | {roadmap}#csp-rm-suggest | button jumps to the form on /roadmap/.

While the module is off, every {roadmap} link is left out of the page, so you never show visitors a broken link.

Who Can Work on Roadmaps

Task	Who can do it
Switch the module on or off, change Settings → Roadmaps	Administrators and Support Managers
Work the board: add, move and edit items, add roadmaps, review feature requests	Administrators, editors, Support Agents and Support Managers
Move items on the public roadmap page	Anyone who can edit that item
React, comment and suggest features	Whoever Settings → Roadmaps allows

The roles guide explains the Support Agent and Support Manager roles.

Roadmaps and Privacy

Roadmaps keep personal data to the feature requests, and they work with the WordPress privacy tools:

• What a request stores: the idea, the details, the sender’s name and email address, and their user ID when they were signed in. The name and address show only to your team, and reach alert services only when Include a message preview is on. A signed-in sender is never made the item’s author, so publishing their idea never lists them on your site or in its author sitemap.
• Export: Tools → Export Personal Data includes the feature requests sent with that email address, with the idea, its details as they read now and when it was sent.
• Erase: Tools → Erase Personal Data removes the name, email address and account link from that person’s requests, including declined requests still in the trash. The ideas stay on the roadmap. It also removes the reactions of the account with that address and recounts the totals.
• Guest reactions: these are tied to a random cookie token, not to an email address, so the eraser can’t find them, and they don’t identify anyone.
• The cookie: csp_roadmap_voter holds only the random token. It is set only when a visitor who isn’t signed in reacts, it lasts a year and scripts on the page can’t read it. If your cookie policy lists functional cookies, add it there.
• Comments: these are WordPress comments, so the WordPress privacy tools and your Settings → Discussion rules cover them like comments anywhere else on your site.
• Deleting an item: an item deleted for good takes its reactions and comments with it.

Settings → Data → Delete all Core Support data when the plugin is deleted also removes roadmaps, their items with their comments, and every reaction. The data and privacy guide covers the rest.

Good to Know

• Only published items take reactions. A pending request or a draft shows no buttons.
• Similar ideas appear only on a roadmap’s own page, where its items are listed. On /roadmap/, the form has no items to compare with.
• The roadmap pages use your branding from Settings → Branding, the same as the docs and changelog pages.
• While the module is off, the roadmap addresses stop working. Links you shared start working again once you switch it back on.
• The board needs JavaScript. Without it, use List view.