Strong Testimonials Properties - WordPress Plugin

How to Configure Strong Testimonials Properties for WordPress

Strong Testimonials Properties is not meant to help you collect testimonials from scratch. Its purpose is to fine-tune how Strong Testimonials is labeled and presented inside WordPress and on the public-facing site. This guide walks through the practical process: what to check before installation, where to enable the extension, which settings to change first, how to rename the testimonials section for your niche, how to configure links, categories, editor permissions, and how to make sure the final setup does not break pages that are already live.

The extension is most valuable on sites where the word "testimonial" does not match the real use case. For an online store, these may be customer reviews; for a studio, client stories; for a clinic, patient feedback; for an educational project, student opinions. If you leave the default labels and standard slug unchanged, the admin interface may only make sense to a developer, while URLs like /testimonial/... can feel out of place on a Russian-language or industry-specific site.

This guide does not cover purchasing or bypassing activation. It assumes the core Strong Testimonials plugin is already installed on the site, and that the Pro component and the available Properties extension are enabled normally through the WordPress admin area. It also covers common issues separately: permalink resets, legacy slug conflicts, missing star icons, unusual view behavior after Ajax navigation, theme limitations, and the security side of editor permissions.

What the Extension Changes and What It Does Not Replace in the Core Plugin

Strong Testimonials Properties is best understood as a control layer for the existing Strong Testimonials post type. The core plugin handles testimonial entries, submission forms, views, the [testimonial_view] shortcode, the widget, and front-end output. The Properties extension, which is also described in the current documentation as Advanced Controls, does not turn testimonials into a standalone CRM and does not replace the form editor. Its narrower role is to change system labels, post behavior, permalink structure, category settings, admin visibility, and which fields editors are allowed to access.

This distinction helps prevent two common mistakes. The first is expecting Properties to add new designs, Google imports, or extra forms. Those needs are handled by other Strong Testimonials extensions or by the core view settings. The second is changing post properties before you understand how the site already uses testimonials. If the site already has published pages, menus, ad links, internal links, or indexed pages in search engines, changing the slug can affect the URLs of single testimonials and archives. That is why Properties should be configured after a quick inventory, not just "in case."

In practical terms, the extension answers one question: how do you make the testimonial entity in WordPress look and behave the way your project expects. For example, an agency site may replace "Testimonials" with "Client Stories," while a Russian-language site may use "Reviews." A site focused on expert evaluations may choose "Reviews." In the admin area, this reduces confusion for editors: they see a familiar section, understand what kind of entries they are editing, and do not perceive testimonials as some foreign technical module.

If you look at Properties as part of the overall Strong Testimonials system, the workflow becomes clear: a testimonial is created manually, submitted through a form, or imported; a view decides which testimonials to display and how to render them; a shortcode or block inserts that view into a page; and Properties configures the system around those testimonials. It does not change the testimonial text itself. It changes how WordPress labels, routes, and grants editing access to that content type.

Who This Extension Is Best For

The extension is especially useful for sites where testimonials are not just a random block at the bottom of a page but a distinct content type. That includes service businesses, agencies, online schools, medical and legal projects, B2B sites, local businesses, and stores where testimonials need to appear across multiple sections. If an editor regularly adds new entries, organizes them into categories, and checks public URLs, consistent labels and a clear slug save time and reduce mistakes.

Strong Testimonials Properties also fits teams where content is handled by editors rather than administrators. In that case, it matters that people do not get unnecessary access to technical metaboxes and do not have to work through English labels when the rest of the site is managed in Russian. The Editor Permissions section is designed specifically to control which fields and blocks an editor will see while working with testimonials.

When Not to Start with Properties

If you do not yet have a single published testimonial and the task is simply "put a carousel on the homepage," start with the core Strong Testimonials plugin first: create a few testimonials, build a view, test the form, and verify the shortcode output. Properties makes sense once it is clear what you want to call this content and what kind of URLs the site actually needs.

You should also avoid using the extension as a quick fix for all localization needs. It changes labels and some post properties, but full multilingual support for testimonials, fields, and categories usually requires separate configuration in a translation plugin. Strong Testimonials documentation for WPML specifically covers translation of post types, taxonomies, and custom fields. So if the site runs in multiple languages, the label changes in Properties need to be coordinated with translations rather than treated as a replacement for the site’s entire language architecture.

What to Check Before Installing and Enabling It

Before installing the extension, you need to prepare not only the technical environment but also the content plan behind it. Properties affects how testimonials are presented in the admin area and in URLs. That is why it helps to answer a few questions first: what do you call testimonials in public-facing copy, do you need a dedicated testimonial archive, should single testimonial pages be indexed, which categories already exist, and is there another plugin or theme on the site that already defines its own testimonial post type.

The core Strong Testimonials plugin is installed like any standard free WordPress plugin: through Plugins - Add New or by uploading a ZIP file via Upload Plugin. Once activated, a Testimonials section appears in the WordPress menu. To access premium extensions, Strong Testimonials documentation points to the Pro component: it must be installed and activated first, and the available extensions are enabled through Testimonials - Extensions. In this article, those steps are treated as setup verification, not as purchasing instructions.

The technical pre-check before enabling Properties has five parts. First, make sure the core plugin is actually working: at least one testimonial and one view should already exist, and the shortcode should render correctly on a test page. Second, open the current permalink settings in Settings - Permalinks and note the selected structure. Third, check whether an older testimonial plugin or a theme feature is already using the testimonial slug. Strong Testimonials documentation explicitly warns that conflicts over this part of the URL can lead to odd redirects and 404 errors.

Fourth, review which pages already link to single testimonials. If single testimonial pages are not being used, changing the slug is less risky. But if they are linked from menus, service pages, search results, or ad campaigns, prepare redirects or keep the current structure until you can review the SEO impact separately. Fifth, assess user roles. If testimonials will be edited by managers, authors, or editors, decide in advance which fields they actually need to see.

Safe order of operations: first verify the core view and current URLs, then enable Properties, change one logical group of settings at a time, and open a test page in incognito mode after each change.

Quick Decision Map Before You Start

Installing, Enabling, and Running the First Check

Once the core plugin and the Pro component are installed, open Testimonials - Extensions. In the extensions table, find Properties or, if the interface uses the newer label, Advanced Control. Strong Testimonials documentation describes enabling it with the status toggle in that table. After you enable it, go to Testimonials - Settings - Advanced Controls. That is where the tabs Admin Options, Labels, Posts, Categories, and Editor Permissions should appear.

Do not start by changing everything across all tabs. A better first step is a basic access check: open each tab, make sure settings can be saved, and then return to the testimonials list. If a tab behaves oddly after saving, stop there and rule out cache or extension conflicts before you touch permalinks or labels. The Strong Testimonials core changelog includes a fix related to Properties settings being saved in a way that could reset other tabs. That does not mean the issue is present on your site, but it does explain why a small save test is worth doing after an update.

Your first change should be fully reversible. For example, you can temporarily change only the menu icon or the menu position in the admin area, save it, refresh the page, and switch it back. That confirms the extension is active, the settings screen is accessible, and saving does not conflict with your user permissions. Only after that should you move on to labels and the slug, because those changes are more visible and require closer validation.

Checklist After Enabling It

1. Open Testimonials - Extensions and make sure the required extension is enabled with its toggle.
2. Go to Testimonials - Settings - Advanced Controls and verify that all five settings groups are present.
3. Make one small change in Admin Options, save it, and refresh the admin page.
4. Open a page where [testimonial_view] is already embedded and confirm that the view still displays correctly.
5. Check the browser console if the carousel, pagination, or form behaves differently after the extension is enabled.

If the basic check passes, you can move on to the main configuration. If it does not, temporarily disable the extension, keep the core Strong Testimonials plugin active, and test the views without Properties. That will tell you whether the problem is in the extension, the Pro component, the theme, caching, or another plugin.

How to Rename Testimonials to Reviews, Feedback, or Client Stories

The Labels section is the most visible one for your team. It lets you change the main labels, post labels, and category labels. In practice, this is not cosmetic. It is how you align the workflow with the language of the project. If the site sells services, editors will find it easier to work with a section called "Client Stories" than one labeled "Testimonials." If the site collects product feedback, "Reviews" may be more accurate. If the project is aimed at expert evaluations, "Reviews" can also work, but in a Russian-language admin area there is usually no reason to mix English and Russian labels.

Before you change the labels, create a short terminology list. It should include the singular form, the plural form, the menu label, the category label, and action text such as "Add Review" or "Edit Review." A common mistake is changing only the main menu label. That leaves you with an interface containing a mix like "Reviews," "Add New Testimonial," "Testimonial Categories," and "Search Testimonials." Editors will still figure it out, but the interface will feel unfinished.

For a Russian-language site, simpler wording is usually better. "Reviews" works well for most stores and service businesses. "Client Stories" feels softer and fits B2B use cases where the testimonial is closer to a case-based story than a quick rating. "Ratings" makes sense for a star-rating-driven setup, but it can be too narrow if the testimonials include long-form text, job titles, company names, and client website links.

A Practical Renaming Workflow

1. Open Testimonials - Settings - Advanced Controls - Labels.
2. Start with the primary labels: the name of the content type in menus and lists.
3. Then go through the post labels: add, edit, search, view, and empty states.
4. After that, update the category labels if you use testimonial categories.
5. Save the settings, refresh the admin area, and check the menu, posts list, add-new screen, and categories list.

After saving, do not stop at checking a single menu item. Open the add-new testimonial screen, the full testimonials list, quick search, categories, and the view page. If an old label is still showing somewhere, it may not be a Properties issue at all. The text may be coming from the theme template, a WordPress translation, a view setting, the form text, or a string managed through WPML or Polylang. The key is to separate the layers: Properties changes system-level labels, while public form text and testimonial field text are configured in the form editor and in views.

How to Keep the Public Copy Consistent

Your renaming should be consistent, but not mechanical. If you choose "Reviews," that does not mean every public phrase has to use the exact same word. On a service page, you may prefer "Client Reviews." On a product page, "Customer Reviews" may be better. In the admin area, a short label like "Reviews" is usually enough. That keeps the interface clean while allowing the public copy to sound natural. Just remember that URLs and schema settings, if you use a separate markup extension, still need to be reviewed independently.

Be especially careful when changing labels on a multilingual site. Strong Testimonials documentation notes that WPML and Polylang use string translation for domains related to form fields, form messages, emails, and the Read more text. That means if your site runs in Russian and English, one label change in Properties is not full localization. Set the base language first, then check which strings have been passed into the translation plugin, and only publish the changes after that review.

Permalinks and Slugs: How to Change URLs Without Losing Pages

The Posts section matters more than it seems at first glance. Properties documentation explains that this is where you can change viewable behavior, permalink settings, the slug, the archive page, and whether testimonials are excluded from public search. These are not just labels. They directly affect which URLs are available to visitors and search engines.

By default, Strong Testimonials expects URLs like /testimonial/example-slug. If you change the singular label to "review" or "otzyv," it is tempting to change the slug immediately as well. That is perfectly reasonable on a new site, but risky on an established one. Those URLs may already be referenced in menus, sitemaps, ads, emails, internal links, and search results. So permalink changes should be treated like a small migration, even if the actual update takes only five minutes.

The first rule is simple: do not change the slug on a live site unless you have a list of the existing URLs. The second rule is not to use an overly generic slug. A path like /reviews/ may conflict with WooCommerce reviews, a reviews page, a custom post type in the theme, or another plugin. The third rule is that after changing the slug, you should always refresh permalinks through Settings - Permalinks - Save Changes without altering the main permalink structure. Strong Testimonials documentation repeats this step for cases where permalink behavior breaks.

How to Choose a Slug

On a Russian-language site, you can technically use Cyrillic in URLs, but for testimonials, Latin characters are usually more practical: otzyvy, client-stories, customer-reviews. The best choice depends on the site. If the public-facing site is fully Russian and your URLs already follow transliteration, otzyvy is a logical option. If the site is bilingual and the English version matters, it is usually better not to tie the shared slug only to a Russian term. If testimonials function more as detailed client case stories, client-stories may be more precise than reviews.

Do not make the slug too long. It should explain the content type, not repeat an entire page title. A good slug helps people understand what they are opening without turning the URL into an SEO phrase. If the site already uses /reviews/ as a normal page containing a view, do not reuse that same slug for single testimonials. A conflict between a page, an archive, and a post type can produce unpredictable 404 behavior.

Step-by-Step Permalink Update

1. Create a backup or at least save a list of the current single-testimonial URLs.
2. Open Testimonials - Settings - Advanced Controls - Posts.
3. Change the slug only for the level you actually need: posts, archive, or categories.
4. Save the Properties settings.
5. Open Settings - Permalinks and click Save Changes without changing the overall structure.
6. Check the old URL, the new URL, the page with the view, and the site search results.

If the old URL returns a 404 but the new one works, the rewrite rules have been refreshed and the remaining issue is redirects. If neither the old nor the new URL works, revert the slug, save permalinks again, and check whether another plugin is using the same content type. If the view works on a normal page but the single testimonial page does not, the problem is usually in the permalink or single template layer, not in the core testimonial output.

Admin Options: Menu Icon, Menu Position, and Testimonial Export

The Admin Options tab controls how the testimonials section behaves inside WordPress. Strong Testimonials documentation for Advanced Control lists settings for the menu icon, menu position, visibility in the top New menu, and export availability. These options do not change testimonial content, but they do affect editorial workflow and how quickly the team can find the section they need.

A menu icon is useful when the admin area contains many custom post types. If the site has products, portfolio items, case studies, jobs, events, and testimonials, identical gray menu entries start to blend together. A suitable Dashicon makes the section easier to spot. But do not choose an icon based only on appearance. It should signal the function: a star for ratings, a speech bubble for feedback, a document for client stories. If the icon visually overlaps with comments or forms, editors are more likely to click the wrong section.

The menu position determines where the section appears in the left sidebar. On a site where testimonials are updated once a month, the section can sit below the main content types. On a site where a manager approves new testimonials every day, it makes sense to place it closer to posts, pages, or WooCommerce sections. But higher is not always better: if testimonials are rarely touched, the menu item can become a distraction.

When to Add It to the Top "New" Menu

The visibility option for the New menu is useful when editors regularly create testimonials manually. In that case, they can add a new testimonial directly from the WordPress toolbar. But if most testimonials arrive through a form and go through moderation, that shortcut may add little value. The manager will still go to the pending submissions list instead of creating an entry from scratch.

The practical rule is simple: enable the New item when manual entry is a normal task. Disable it when testimonials mostly come from a form, an import, or an external workflow. That keeps the admin area cleaner and avoids giving the team multiple paths to the same task for no good reason.

Export and Responsibility for Data

Exporting testimonials can be useful for backup transfers, content audits, and migrations between sites. But testimonials may contain personal data: name, email, company, URL, address, photo, message text. The Strong Testimonials page on WordPress.org explicitly notes that when the form is used, the submitted data is stored in the database and notification emails may include selected form data. That means export should be enabled deliberately and only for roles that truly need it.

If your site handles client testimonials, do not enable export just because the option exists. Decide who is responsible for exports, where exported files are stored, and how they are deleted. Editors who only revise text and publish testimonials usually do not need export access. For an administrator or content manager who moves testimonials between a staging site and production, export may be helpful, but it should be backed by a clear storage policy.

Posts and Categories: Visibility, Archives, Search, and Hierarchy

The distinct value of Properties becomes especially clear in the Posts and Categories tabs. This is where you decide whether testimonial entries and categories are publicly viewable, which slug they use, whether the archive page is enabled, and whether testimonials should be excluded from public search. On a small site, these settings may feel optional, but on a project with dozens of testimonials they determine whether the testimonial section becomes a real content system or remains just a page block.

Public single-testimonial pages are not always necessary. If each testimonial is short and only intended to appear as a card in a slider, the standalone page may be weak and duplicative. If a testimonial is long and includes a case story, photo, company, link, and service category, a single page may be genuinely useful. It gives the full story room to breathe, can participate in internal linking, and gives a manager a clean way to send a specific testimonial to a client.

A testimonial archive page only makes sense if visitors are likely to browse it. For example, an agency site may present all client stories in one place and let users filter them by service. But if the main use case is embedding specific views on service pages, a global archive may be unnecessary. In that case, it is usually better to keep display control inside views and avoid creating another public entry point that now has to be designed, indexed, and maintained.

Excluding Testimonials from Search

The option to exclude testimonials from public search is useful when they interfere with more important search results. Imagine a site with a knowledge base: a user searches for "shipping," and the search results return dozens of testimonials in which customers casually mentioned shipping instead of showing the actual help articles. In that case, it makes sense to remove testimonials from search and display them through dedicated views. On a service site, by contrast, searching across testimonials may be valuable if visitors want to find experience related to a similar company or project.

After changing this setting, test search with several different queries. Do not stop at the word "testimonial." Use service names, the brand name, the city, the product name, and common phrases taken from testimonial text. The expected test outcome is that search shows or hides testimonials exactly the way you intended, while the site’s normal pages continue to appear correctly.

Category Hierarchy

The Categories tab lets you configure category visibility, the category slug, and hierarchical URL structure for child categories. A hierarchy is useful when testimonials are genuinely organized into levels: services and sub-services, regions and cities, products and product lines. But if you only have three equal categories, nesting them will only complicate the URLs and the editorial workflow.

Do not create categories just for SEO. A testimonial category should help either the visitor or the editor. A strong example would be categories like "CRM Implementation," "Website Support," and "SEO Audit" for an agency. A weak example would be "Best Reviews," "Client Reviews," or "Real Reviews" because those labels do not actually organize anything. If categories are going to be public, each one should serve a clear purpose and contain enough meaningful content.

Editor Permissions: What Editors Should See and What Should Stay with the Administrator

The Editor Permissions tab helps make the testimonial editing screen both clearer and safer. The documentation describes it as the place where certain fields and meta boxes can be made available to editors. That matters most when testimonials move through an editorial workflow: a manager reviews the text, corrects the client name, adds the company, and publishes the entry, but should not accidentally change technical settings, the template, or fields that affect the output.

In WordPress, the Editor role usually has broad content permissions, but it should not be managing plugin-wide system settings. Properties helps align the testimonial editing screen with the editor’s real job. Instead of a set of technical panels, the editor sees only the fields related to content, client information, and publishing. That reduces the risk of accidental changes and makes onboarding faster for the team.

Permission settings are best approached by describing the workflow first. Who approves a testimonial? Who fixes spelling? Who verifies that the client agreed to the publication of their name, photo, and link? Who decides whether a testimonial should be published immediately or left pending? The answers to those questions matter more than a raw list of metaboxes. If the roles are not clearly defined, you may accidentally hide a field the editor needs every day or expose a block that should be visible only to an administrator.

Recommended Minimum for Editors

• The testimonial text and title, if titles are used in the view.
• The main client details: name, company, website, job title, or any other fields that are actually displayed.
• The rating, if the site uses star ratings.
• Testimonial categories, if views display testimonials by service, product, or topic.
• The client photo, if the site’s policy allows published images.

Any debatable technical settings are better left to the administrator. That includes system-level properties, fields that affect the template, export, permalinks, global labels, and compatibility settings. If an editor occasionally needs to change something beyond text and categories, it is usually safer to document the step and have an administrator handle it once than to permanently widen permissions.

How to Test Permissions Without Risking the Live Site

Create a test user with the editor role, or use an existing editor account on a staging copy. Open a testimonial edit screen and check which panels are visible. Then create a test testimonial, save it as a draft or pending item, open the public page with the view, and confirm that the front-end output has not changed. If the editor cannot see a field they need, restore it. If they can see an unnecessary technical block, hide it and run the check again.

Pay special attention to the publication status. Core Strong Testimonials allows you to define the status of new testimonials submitted through the form: pending or published. For most sites, moderation is the safer choice. If testimonials are published automatically, editor permissions should be even tighter, and the form should have proper spam protection through a Strong Testimonials mechanism or a third-party solution, because public text would otherwise go live without manual review.

Practical Use Case: Rename Testimonials and Display Them on a Service Page

Let’s walk through a real example. There is a studio website where the section used to be called Testimonials, but the team wants to manage it as "Client Stories." On a service page, they want to display three relevant testimonials, keep a clean URL structure for single entries, and prevent editors from changing technical settings. This is a good example of why Properties works alongside core views rather than replacing them.

Goal

The goal is a clean workflow: in the admin area, the editor sees a section called "Client Stories," adds entries with a name, company, and service category, and a view on the service page displays the correct category. Single pages use a meaningful slug such as client-stories, while search behavior is handled separately: if the stories are long, they can participate in search; if they are short, they stay inside page blocks only.

Preparation

1. Make sure Strong Testimonials is installed and that Testimonials appears in the menu.
2. Check that the Pro component is active and that Properties or Advanced Control is enabled under Testimonials - Extensions.
3. Create a testimonial category for the target service, for example "WordPress Support."
4. Add three test testimonials and assign that category to all of them.
5. Create or open a view in display mode and configure it to pull testimonials from that category.

Configuration Steps

Start in Advanced Controls - Labels. Change the main labels to "Client Stories." For the singular form, use "Client Story." In the post labels, review add, search, and edit actions so the old and new terms are not mixed together. In the category labels, use "Story Categories" or a shorter term such as "Services" if the categories match service areas.

Then move to the Posts tab. If single pages are needed, set the slug to client-stories. If the project is fully Russian-language and the URLs already use transliteration, istorii-klientov may also be appropriate. After saving, make sure you open Settings - Permalinks and click Save Changes. That refreshes the WordPress rewrite rules and helps avoid a false 404.

Next, configure Categories. If categories will be useful to visitors, assign a clear slug and decide whether hierarchy is needed. For a studio with service-based categories, a flat structure is usually enough. If there are broader categories with subcategories underneath them, hierarchy may help, but only if the team is willing to maintain it consistently.

The last step is Editor Permissions. Let editors access the text, title, client fields, rating, and categories. Keep global properties, permalinks, and export under administrator control. That makes the workflow predictable: the editor works with content, and the administrator remains responsible for structure.

Result Check

1. Open the admin area and confirm that the section is labeled "Client Stories" both in the menu and on the list screens.
2. Open one test testimonial and check the new URL.
3. Visit the service page where the view shortcode is embedded and make sure only testimonials from the correct category are displayed.
4. Open the page in incognito mode to eliminate the influence of the admin bar and cache.
5. Check the mobile layout: the cards, rating, client name, and Read more button should all remain aligned.

If the service page works but the single testimonial returns a 404, go back to permalinks and refresh the rules again. If styling disappears or the slider stops working, check theme compatibility and whether wp_footer is being called. If the editor cannot see a required field, open Editor Permissions and restore access to the appropriate metabox.

How to Verify the Final Setup on the Site: Admin Area, View, Form, and SEO Signals

After configuring Properties, it is important to check more than just the settings page. The extension interacts with several WordPress layers, so the result should be reviewed as a full chain: admin area, URLs, view, form, search, mobile layout, and cache behavior. If you only check the menu, you might miss 404 errors on single pages. If you only check a single testimonial page, you may not notice that the view on a service page is still showing old form labels.

Start in the admin area. Check the left-hand menu, the top New menu, the testimonials list, the add-new screen, categories, and editor permissions. Then move to the front end. Open a page with a view, a single testimonial page, the archive if it is enabled, and a category page if categories are public. After that, test search. If you excluded testimonials from public search, they should not appear for phrases taken from testimonial text. If you left them in search, the results should lead to the correct pages.

Views remain the core display layer in Strong Testimonials. The plugin page on WordPress.org explains that a view holds the display settings and is inserted into a page through a shortcode or widget. That means every Properties change should be checked against the view: labels and slugs may update, but the layout, fields, order, quantity, and template are still controlled by the view. If you renamed the entity to "Reviews" but the view still shows an old button label or an English-language form, look for the setting in the form or the view, not only in Properties.

Verification Checklist

• The WordPress menu uses the chosen name and does not duplicate old labels.
• The single testimonial page opens under the new slug, or single-page visibility has been intentionally disabled.
• The page with [testimonial_view] shows the correct set of testimonials.
• The submission form uses clear labels, error messages, and success messages.
• Categories are public only where visitors actually need them.
• Public search shows or hides testimonials according to your decision.
• Cache has been cleared after changing the slug, labels, and view.
• The mobile layout does not break the heading, quote icon, stars, or read-more button.

SEO and Indexing Without Overpromising

Properties can help make URLs and labels clearer, but it does not guarantee ranking improvements on its own. For SEO, what matters more is that testimonial pages are genuinely useful, do not duplicate each other, have a clear structure, and do not create unnecessary thin archives. If single testimonials are short, disabling public visibility or blocking indexing may be better than publishing dozens of weak pages. If testimonials are long and tied to specific services, they can work well as supporting content, but only with sound internal linking and careful category management.

For rich snippets and aggregate rating, Strong Testimonials has separate mechanisms and extensions, so do not attribute those features to Properties. If you need review markup, refer to the documentation for Review Markup and the aggregate rating shortcode. Properties controls labels, permalinks, and post-type behavior, not the entire testimonial SEO layer.

Safe Front-End Tweaks Without Editing Plugin Files

Once the naming and URL setup are in place, there is often one last task: slightly adjusting the testimonial cards so they fit the theme better. That can be done safely as long as you do not edit plugin or theme files directly. The official Strong Testimonials documentation on custom CSS clearly explains that changes made inside plugin files will be overwritten during updates, and that extra styles should instead be added through Additional CSS in the Customizer, the theme’s CSS area, a dedicated CSS plugin, or a child theme.

Properties can change the quote icon, but it does not control every presentational detail of a testimonial card. That is why a small CSS adjustment is reasonable when, after renaming labels or switching templates, the heading, client name, or company block does not look quite right. The example below does not depend on plugin files and uses the documented container classes .strong-view and element classes .testimonial and .testimonial-client described in Strong Testimonials documentation.

Subtle Emphasis for Testimonial Cards

Goal: make cards in the default view slightly easier to read on a light service page. You can paste the code into Appearance - Customize - Additional CSS or into the theme’s CSS section. If a specific view already uses its own additional CSS class name, it is better to include that class in the selector so you do not change every view site-wide.

/* Strong Testimonials: subtle emphasis for cards in the default view */
.strong-view.default .testimonial {
  border: 1px solid rgba(35, 64, 92, 0.14);
  border-radius: 10px;
  background: #ffffff;
  box-shadow: 0 8px 24px rgba(35, 64, 92, 0.08);
}

.strong-view.default .testimonial-client {
  font-style: normal;
  font-weight: 600;
}

The check is simple: open the page with the view on a normal desktop resolution and on mobile. The card should stand out more clearly, but it should not break the grid, hide the photo, or turn every testimonial into a different-height block. If the result looks worse, remove the added CSS or temporarily comment out the rules. Do not edit plugin files: it will only make updates harder and will not give you a stable outcome.

If the quote image is being cropped in the heading, the official knowledge base includes a separate CSS technique that adjusts the line-height for .strong-view h3.testimonial-heading. Use it only if you have that specific symptom, not as a default tweak. First check which template and heading level your view actually uses, because an overly broad fix can make larger headings look worse.

How to Connect Properties with the Submission Form and Views

Properties does not exist in isolation from the form and the views. If you change the labels but do not review the form and the view, visitors may still see the old wording while editors see a newly renamed menu section. That is why, after configuring Properties, it helps to follow the full chain from testimonial submission to front-end output. That process shows where post-type settings end and where the core Strong Testimonials configuration begins.

The form in Strong Testimonials is configured under Testimonials - Form. The documentation separately covers fields, labels and messages, post-submission actions, the status of new entries, and email notifications. That means you can rename "Testimonials" in the admin menu through Properties, but the submit button text, error message, and success message still need to be changed in the form settings. It may seem like a longer route, but it keeps system labels separate from user-facing copy.

What to Check in the Form After Renaming

Open the fields tab and review which fields are actually needed. If you renamed the section to "Client Stories," the form may need more than just a name and text. You may also want company, job title, website link, or service category. If you are using short product-style reviews, some of those fields can be removed to keep submission friction low. Strong Testimonials documentation notes one important detail: removing a field from the form does not remove the data that has already been saved. That is useful for testing, but you should still review older testimonials before changing the public form.

Then open the form’s labels and messages. This is where the text for required fields, the submit button, error messages, and success messaging should be refined. If the new terminology in Properties is "Client Stories," a button labeled "Add Testimonial" will break the sense of consistency. A shorter phrase such as "Submit Your Story" or "Leave a Review" will usually work better, depending on the vocabulary you chose. Do not turn the button into a marketing slogan. The form should feel clear and fast.

Check the post-submit action separately. Strong Testimonials can show a message, redirect to a page, or redirect to a URL. For most sites, an inline confirmation or a dedicated thank-you page is the safer option. If the new testimonial is saved with pending status, say that clearly in the message so the user understands that their submission was received and will appear after review. If publication is immediate, check the form protection and editorial policy carefully, because accidental or low-quality text may otherwise go live without moderation.

Views as the Final Verification Point

A view determines which testimonials to show, in what order, using which template, and with which fields. That is why after configuring Properties, you should open the view used on an important page: the homepage, a service page, a product page, or a dedicated testimonial section. Review the query settings: categories, order, quantity, and select. If you changed public categories through Properties, the view should still pull the right category. If a category was renamed, check not only its label but also its slug, especially if the shortcode uses a category attribute.

The fields in the view should match the form. If the form collects the client’s company and website but the view does not display them, editors will be filling in data that never appears publicly. If the view exposes email addresses or other unnecessary fields, you should fix the output immediately. The Strong Testimonials page on WordPress.org specifically notes that the plugin prevents email addresses from being displayed publicly by default, but any custom settings and templates still need to be checked manually. Never assume a private field is safe until you have opened the public page as a normal visitor.

A solid test looks like this: submit a test testimonial through the form, confirm it appears with the expected status, open it in the admin area, verify the labels and fields, assign a category, publish it, and then open the page with the view. If every part lines up, Properties has been configured inside a real workflow rather than in isolation. If one part breaks, do not start changing everything at once. Identify the layer first: form, post, category, view, shortcode, theme, or cache.

Updates, Cache, and Staging: How to Make Changes Safely

Properties affects system-level testimonial settings, so it should be tested as carefully as permalink changes for any custom post type. That does not mean the extension is dangerous. It means WordPress stores URL rules, roles, labels, and cached states across different layers, and some issues show up only when a visitor opens a page rather than when you click Save. This is especially true on sites that use caching, CSS/JS optimization, staging copies, and multiple user roles.

If the site is live, start on a staging copy. There you can safely test a new slug, archive visibility, search exclusion, and editor permissions. After you deploy the changes to production, repeat only the steps that have already been validated. Do not import everything blindly if the page structure is different. For example, the staging site may not have an old /reviews/ page, while the live site does, creating a conflict with the new slug. Staging helps catch many issues, but you still need a final check on the production domain.

Cache and Optimization

After changing labels, cache usually does not interfere with the admin area, but it can affect the front end: old views, old styles, old card HTML, or outdated search results may still be served from cache. After changing the slug, clear the page cache, object cache, CDN cache, and browser cache if they are in use. After changing CSS for Strong Testimonials, temporarily disable caching during the adjustment process, as recommended in the official custom CSS documentation, otherwise you may end up evaluating an outdated version of the styles.

Check CSS and JS optimization separately. If the stars disappear, start by excluding font-awesome.min.css from CSS optimization, as recommended in the Strong Testimonials knowledge base for Autoptimize. If the view loads without slider or pagination behavior, temporarily disable JS combining and deferred loading. Once you find the conflict, re-enable optimization one setting at a time. Do not leave all cache disabled permanently without a reason, but do not try to diagnose a dynamic view while aggressive optimization is still active either.

Extension Updates

For Strong Testimonials premium components, the official documentation lists several reasons why updates may be unavailable: license status, active domain, or a staging/live mismatch. This article does not cover purchasing or access activation, but from an operations perspective one point matters: if the Pro component or extension is not updating, you may be dealing with an issue that has already been fixed. That is especially relevant for Properties because of its history of fixes related to saving settings and preventing resets in other tabs.

Before updating, create a backup and note the current labels, slug, visibility settings, and editor permissions. After the update, open Advanced Controls and verify that the tabs still contain the expected values. Then repeat a short public test: the page with the view, a single testimonial, a category page, and search. If something changed, check the core plugin changelog and the extension changelog first, then clear cache, and only after that suspect a theme conflict.

Rollback Plan

Your rollback plan should be simpler than the setup itself. For labels, just restore the previous values and save. For the slug, switch back to the original slug, save Properties, and then save permalinks. For archive or category visibility, restore the earlier mode and clear cache. For CSS, remove the added rules from Additional CSS or comment them out. For editor permissions, restore visibility for the required fields and test with the editor account again.

Do not roll back the entire plugin if the problem is a single slug or one CSS rule. A full rollback only makes sense after a serious post-update conflict where the core Strong Testimonials plugin, the Pro component, or the theme stop working together. In all other cases, a targeted fix is faster and safer. Keep a simple change log: what was changed, where, why, and how to verify it. That is especially useful with Properties because a month later the team may not remember why testimonials were excluded from search or why editors cannot access export.

Common Strong Testimonials Properties Issues and How to Diagnose Them

Problems after enabling Properties are usually tied not to label text itself but to the fact that the extension changes system-level settings: permalinks, visibility, categories, roles, cache, and theme compatibility. The best way to troubleshoot is from simple to complex. First check whether settings are saving correctly. Then open the public page with the view. After that, test single URLs, search, the browser console, and conflicts. That order is usually faster than disabling every plugin immediately.

After Changing the Slug, a Single Testimonial Returns 404

Symptom: the testimonials list and the view still work, but the single testimonial page under the new URL does not open. In some cases, the old URL stops working too.

Possible cause: WordPress has not refreshed rewrite rules yet, the new slug conflicts with a page, theme, or another testimonial plugin, or public visibility has been enabled where it was not before.

What to check: open Settings - Permalinks and click Save Changes. Then check whether a page already uses the same slug. If the site previously used another testimonial plugin, temporarily disable it or change the conflicting slug on a staging copy. If the new slug is not critical, restore the old value and save permalinks again.

Labels Changed in Some Places but Not Others

Symptom: the menu is already labeled "Reviews," but the form, button, email, or view still shows the old English wording.

Possible cause: Properties changes the system labels for the post type, but form text, success messages, fields, notifications, and Read more may be controlled elsewhere in Strong Testimonials or in a translation plugin.

What to check: open Testimonials - Form for labels and messages, then inspect the specific view displayed on the page. If the site is multilingual, also check WPML or Polylang string translation. Do not try to solve everything through one label in Properties, because that will always result in an incomplete translation.

Properties Settings Save, but Another Tab Gets Reset

Symptom: after saving one settings block, part of a neighboring tab looks like it has reverted to an older value.

Possible cause: similar issues have appeared in past Strong Testimonials updates, where fixes were made specifically for saving Properties settings. Admin caching, an outdated Pro component, or extension conflicts may also be involved.

What to check: update the core Strong Testimonials plugin and the Pro component using the standard process, clear cache, and repeat the change on one small setting. If the problem remains, do not change permalinks and labels in bulk. Document the steps, take a screenshot, and contact the developer’s support team.

The View Loads Without Styling, the Slider Does Not Start, or Pagination Is Missing

Symptom: after configuring the testimonials section, the front-end block loads incorrectly: styles are missing, the slider does not initialize, pagination disappears, or it only works after a page refresh.

Possible cause: Strong Testimonials documentation connects this behavior with Ajax page loading and with themes that fail to call wp_footer. If the theme replaces page transitions or an optimizer defers scripts, the view may initialize too early or too late.

What to check: in Testimonials - Settings - Compatibility, try the Ajax Page Loading option set to General if it is available. Check the theme using standard diagnostic methods and confirm that wp_footer is called in the template. During testing, temporarily disable aggressive JS optimization.

Star Icons Are Not Displaying

Symptom: the testimonial text is visible, but the rating icons are missing or replaced with empty characters.

Possible cause: the official Strong Testimonials knowledge base points to a CSS optimization conflict when font-awesome.min.css is processed by Autoptimize. The changelog also includes fixes related to invisible star rating icons when inline SVG support is unavailable.

What to check: temporarily disable CSS optimization, then exclude font-awesome.min.css from processing. If you are using a recent plugin version, verify that the theme CSS is not hiding the icons. Remove the exclusion again if it has no effect on the symptom.

The Editor Cannot See a Required Field or Sees Too Much

Symptom: a user with the editor role cannot fill in the client field, rating, or category, or can see technical metaboxes they should not be changing.

Possible cause: the Editor Permissions settings do not match the real workflow. Another possibility is that the field belongs not to Properties, but to custom fields or view configuration.

What to check: sign in as an administrator, open Advanced Controls - Editor Permissions, and compare field visibility to the editor’s actual tasks. Then log in as a test editor and create a draft testimonial. If the field affects front-end output, make sure the view is actually configured to display it.

The Button for Adding a Custom Field Does Not Work

Symptom: when you try to add a new field, you see a message such as Are you sure you want to do this? Please try again, or nothing happens at all.

Possible cause: the official knowledge base documents a conflict between Strong Testimonials and older versions of WooCommerce Helper. Even if your site has a different root cause, the symptom itself points to the need for conflict isolation.

What to check: update the related helper plugin if it exists, then use Health Check & Troubleshooting to run Strong Testimonials and the Pro component in a clean session. If everything works in that clean session, re-enable the other plugins one by one and identify the source of the conflict.

When Strong Testimonials Properties Is the Right Choice

Strong Testimonials Properties is worth using when you already have, or plan to build, a serious testimonial system on top of Strong Testimonials and need more than just attractive cards. The extension helps align labels with the language of the business, configure the slug and public visibility, define category behavior, remove unnecessary elements from the editor interface, and make testimonial management feel less technical for the team.

Its strongest use case is a site where testimonials are organized by service, product, or category, displayed through views, and updated regularly by an editor. In that kind of project, Properties solves an important administrative problem: the testimonials section stops feeling like a borrowed English-language post type and becomes a clear, integrated part of the site’s content system.

Do not begin with aggressive reconfiguration. First verify the core Strong Testimonials setup, create a test view, define your label vocabulary, choose a slug, and decide whether you need single testimonial pages. Then enable Properties, change settings one group at a time, and check the public-facing result after each step. If the product fits your workflow after that, you can download the installation file and test the extension on a site copy or in another safe environment.

The simplest selection rule is this: if you need control over what testimonials are called, where they live, which URLs they use, and who can edit their properties, this extension is a good fit. If instead you need external review imports, a new form, filters, schema markup, or more polished templates, review the neighboring Strong Testimonials extensions or alternative plugins. That way, you will not expect Properties to solve problems it was never built for, and you will get exactly the value it is actually designed to provide.