ThemeForest Pepper - WordPress Theme

ThemeForest Pepper Guide: installation, demo import, settings, and site review

ThemeForest Pepper is a premium WordPress theme for sites that need a strong hero section, ready-made demos, portfolio layouts, a blog, a store, and fine-grained control over the visual design without constant code edits. This guide does not repeat the product listing. Instead, it shows how to approach Pepper as a practical working tool: what to check before installation, how to import demo content safely, where to find the key settings, how to build the homepage, and how to tell when the site is ready to publish.

The main strength of Pepper is the combination of ready-made visual demos with a system of global and local settings. In practice, that means a site owner can quickly launch a foundation that looks close to the demo project, then replace the content, menus, colors, typography, portfolio items, and sections to fit a specific goal. But that flexibility also requires a careful rollout: demo import is best done on a staging copy, settings should be reviewed by level, and any code changes should live in a child theme.

This article covers more than just "how to install it." It also explains "how to use ThemeForest Pepper after installation": which plugins you will need, how Theme Options, Preset, and Page Settings work together, where prebuilt WPBakery templates make sense, how to organize the menu and footer, what to review in WooCommerce and the portfolio area, which issues are most common with themes in this class, and when a similar alternative may be a better fit.

The workflow is straightforward: first prepare WordPress and create a backup, then install the theme and the required plugins, import only the demo that actually fits your project, configure the global settings, build the homepage, review the live-facing side of the site, and only then move the changes to the main domain.

Where Pepper is genuinely useful

Pepper is a multi-purpose WordPress theme. It is not limited to a single type of website and is designed for different visual scenarios. The official product page lists ready-made homepages, header variations, blog and portfolio layouts, WooCommerce support, WPBakery Page Builder, Revolution Slider, Contact Form 7, a WPML-ready approach, and separate settings for color, typography, background, footer, and page layouts. What matters to the user is not the feature list by itself, but the fact that one theme can cover several common use cases for a small or mid-sized website.

The most natural use cases for Pepper are a creative studio, designer portfolio, agency site, app showcase, freelancer website, architecture studio, visually driven blog, small store, service landing page, and a corporate site with several sections. When choosing it, focus less on the number of demos and more on how closely one of them matches your future site. The closer the starting demo is, the less rework you will need on grids, spacing, typography, and section logic.

Pepper's biggest advantage is a fast start with a polished visual style. Based on the included visual reference, the theme clearly leans into contrasting dark and light sections, vivid purple and pink accents, oversized typography, decorative wave shapes, full-screen hero sections, and tiled demo homepages. That works well for creative and presentation-driven sites, but it may feel excessive for a formal legal, medical, or B2B documentation-focused website.

The theme is also useful if you want to work with a visual page builder instead of going fully all-in on the block editor. The product listing states that Pepper is built around WPBakery Page Builder and a set of prebuilt element templates. In practice, page editing will feel closer to the classic Visual Composer/WPBakery workflow: sections, rows, columns, elements, templates, saved blocks, and page-level settings. If your team already works in a Gutenberg-first or Full Site Editing workflow, that should be evaluated up front.

Who it fits best

Pepper is worth considering if you need a site with a strong visual identity but do not want to build a theme from scratch. It works well for a site owner who is prepared to replace demo content, go through the settings carefully, test responsiveness, and maintain the theme together with its dependent plugins. For a studio, it can be a convenient starter kit: one demo layout becomes the foundation, while the other demos serve as an idea library for individual pages.

Pepper is a strong candidate for a site that includes several page types: homepage, services, projects, blog, contacts, and possibly a store or catalog. On projects like that, the homepage is only part of the picture. Consistency matters too: the header, footer, cards, portfolio items, page titles, sidebars, post listings, and forms should all feel like parts of one system.

Who it may not suit

If you are building a very lightweight blog without a visual page builder, Pepper may be more theme than you need. Multi-purpose themes often require more attention to optimization, disabling unused sections, tuning image handling, and checking plugin compatibility. If the site needs to be built entirely with native WordPress blocks and edited only through the Site Editor, note in advance that Pepper's listing explicitly says Gutenberg Optimized: No.

The theme is also not the best choice if you need highly specialized functionality that is not built into the design layer: bookings, a complex CRM form, an education platform, a marketplace, or a multi-level customer dashboard. Pepper can style the pages for a project like that, but the business logic will still depend on separate plugins, which increases the risk of conflicts and makes long-term maintenance harder.

What to check before installation

The preparation work you do before installing the theme will save more time than trying to fix issues after a demo import. Pepper is not a small theme with a single page template. It is a large package with demo materials, dependent plugins, sliders, portfolio features, header and footer settings, and typography controls. That is why the first installation is best done on a staging copy or a separate test WordPress site, not on your live production site.

Rule number one: do not import demo content over important live content without a backup. Demo import usually creates pages, posts, menus, media files, widgets, homepage settings, and sometimes plugin settings as well. Even if the theme imports the data correctly, you will still have to separate your real content from the demo placeholders. That is manageable on a fresh staging site. On a live site with an existing publishing history, it is risky.

Checking WordPress and the environment

The ThemeForest listing shows Pepper as compatible with current WordPress and WooCommerce branches, as well as WPBakery Page Builder and Bootstrap. Use that information as a reference point, but verify it in your own environment. If your hosting runs an outdated PHP version, aggressive caching, nonstandard memory limits, or blocks long-running import processes, the demo may not load completely.

Before installation, check the following:

• Whether you have a current backup of both files and the database.
• Whether the site is running a supported WordPress version and a compatible PHP version.
• Whether memory and execution time limits are high enough for demo content import.
• Whether any active plugins are changing the editor, post types, menus, CSS/JS optimization, or caching behavior.
• Whether you have access to the hosting error log or at least wp-content/debug.log on the staging copy.
• Whether you already know which demo layout you want to import first.

If the site is already live and getting traffic, create a staging copy first. There you can install Pepper, import the demo, and review the header, menus, forms, store, and performance. After that, move only the approved changes: pages, theme settings, media library assets, and any extra CSS tweaks. This reduces the risk of a public site suddenly showing demo text, extra menus, or a broken homepage layout.

Theme archive and child theme

When you buy a theme from a marketplace, you usually get several archive files: the full package with documentation, license files, demo materials, and the installable ZIP for the theme itself. In WordPress, you need to upload the installable theme archive, not the full package. The official WordPress documentation describes the process through Appearance - Themes - Add New - Upload Theme. If you upload the wrong ZIP, WordPress may report that the stylesheet is missing or that the package does not contain a valid theme.

A child theme is not always necessary on day one, but it is useful for Pepper. The product listing states that a child theme is included. That matters if you plan to add CSS, edit template files, include small custom functions, or change the output of specific elements. The WordPress Theme Handbook explains the basic idea: a child theme keeps your changes separate from the parent theme, so you can update the parent without losing your own edits.

Practical recommendation: if you only plan to replace the logo, colors, fonts, and text through the settings, the child theme can wait. If you are adding CSS, PHP, or template overrides, enable the child theme before you start making edits, not after.

Content and images

Pepper's visual character depends on large images, bold hero sections, portfolio previews, and high-contrast background sections. Before importing the demo, prepare at least a rough set of your own assets: logo, 3 to 5 key images, a list of services, 3 to 6 projects, contact details, social links, and menu labels. Without that, setup turns into endless switching between the demo and empty pages.

Pay special attention to images. If you replace the polished demo screenshots with small or blurry files, the theme will lose quality immediately. Hero sections need wide images, portfolio pages need consistently processed thumbnails, and store pages need product images with a unified style. Before publishing, make sure the images are not uploaded at excessive sizes and that they have proper alt text.

Installing the theme and running the first demo import

Installing Pepper starts like any other premium WordPress theme: upload the ZIP, activate it, install the required plugins, and import the demo. The difference is that with a multi-purpose theme, you cannot treat the job as finished right after activation. You need to check which plugins are actually required for the chosen demo, whether unnecessary content is being pulled in, whether the menu and homepage were assigned correctly, and whether the site's older plugins conflict with WPBakery or the slider.

Installation order

1. Open your staging WordPress site and go to Appearance - Themes.
2. Click Add New, then Upload Theme, and upload the installable Pepper ZIP.
3. After installation, activate the theme or, if you plan to edit code, activate the child theme.
4. Open the theme's recommended plugins screen and install only the plugins required for your chosen demo and actual project needs.
5. Confirm that WPBakery Page Builder and the other required components are active.
6. Run the demo import on a clean or staging copy of the site.
7. After import, assign the homepage, configure the menus, and review the front end in a new browser window.

Do not enable everything "just in case." If the site does not use a store, WooCommerce does not need to be activated until there is a real need for it. If you do not need complex forms, Contact Form 7 can be added later. The fewer active plugins you have at the start, the easier it is to identify the cause when something breaks.

Demo import: how to choose your starting point

The official Pepper listing talks about many prebuilt homepages and the ability to import demo data. When choosing a demo, do not judge it only by the top section screenshot. Evaluate the structure: does it include the sections you need, a menu style similar to yours, a suitable portfolio or blog layout, a service grid that fits your offer, space for a form, and store pages if those matter? A good demo saves more than one screen. It saves the entire user journey.

For a creative studio, a demo with a large hero section, a services block, portfolio, and contact section may be a good fit. For a freelancer, an "about me" page, case studies, testimonials, and a simple form are usually more important. For a store, review not just the homepage, but also the product page, shop archive, cart, and checkout. Pepper claims WooCommerce compatibility, but the final store experience still depends on your products, payment plugins, shipping setup, and WooCommerce settings.

Post-import review

After import, do not start by changing colors right away. First make sure the site structure came together correctly. Open the homepage, several inner pages, the portfolio, the blog, store pages, the contact form, and the mobile view. If the import did not finish properly, the signs are usually obvious: images are missing, the menu was not assigned, the slider is empty, buttons still point to demo URLs, footer widgets are missing, or WPBakery shows raw shortcodes instead of styled sections.

Quick result check: the admin area should show the imported demo pages, the public homepage should match the selected layout, the menu should point to real pages, and the browser console should not be full of CSS and JS loading errors. If something is off, do not import a second demo over the first one until you understand why.

Settings map: Theme Options, Preset, and Page Settings

With Pepper, installation is only part of the story. You also need to understand the control layers. The product listing describes Theme Options, Preset, and Page Settings separately. These are not three random screens. They form a hierarchy: global settings define site-wide behavior, presets create reusable parameter sets for groups of pages, and page-level settings override the behavior of a specific page or post.

This approach is convenient as long as you do not use it chaotically. A common beginner mistake is editing every screen manually in Page Settings, then wondering why a global setting does not apply. A more stable order is this: first define the overall visual system, then create one or more presets for different page types, and only after that add targeted overrides for exceptions.

Theme Options as the global foundation

Theme Options should be treated as the site's base layer. This is where it makes sense to review the logo, primary color, typography, background, header, footer, blog, portfolio, WooCommerce elements, and general display settings. If you want the entire site to share one accent color, a consistent button style, and recognizable page headings, the global level is where you should start.

Pepper advertises extended settings for color, typography, background, header, and footer. That gives you flexibility, but it also requires discipline. Choose a base palette of 2 to 3 colors, configure fonts and sizes, save the changes, then review 4 or 5 different page types. Do not change dozens of parameters at once. If something looks wrong after saving, it is much easier to roll back one settings group than to hunt through twenty different places for the problem.

Preset as a design layer for page groups

Preset in Pepper is useful when part of the site needs to look different from the global design. For example, the homepage and portfolio may use a dark header, while the blog and contact pages use a light one. Or a product landing page may need its own page title background, while the rest of the site uses the default background. The theme listing says presets can override Theme Options for the pages and posts they are applied to.

A practical approach is to create as few presets as possible. One default preset can remain for normal inner pages, a second can be used for the homepage or promo pages, and a third for the portfolio if it needs a different header and background. If you create too many presets, the site becomes harder to maintain. Editors will forget why one page looks different, and global style changes will stop producing predictable results.

Page Settings for targeted exceptions

Page Settings are useful when you need to change one specific page: hide the title, choose a different background, disable the footer, make the header transparent, change the navigation type, or define a custom page area. It is a powerful tool for landing pages and portfolio case studies, but it should not be used as a substitute for proper global setup.

Diagnostic rule: if a change in Theme Options is not visible on a specific page, check whether a Preset is assigned to that page and whether there is a local override in Page Settings. In themes with multiple settings layers, this is the most common reason a parameter appears to be "not working."

Colors, typography, and background

Based on Pepper's visual reference, it works especially well with large high-contrast sections, rich purple backgrounds, pink and blue accents, light content areas, and noticeable decorative graphics. But there is no reason to copy the demo palette literally if the brand is different. Start with the main brand color, then define a secondary accent for buttons and hover states, then choose neutral text and background colors. After that, test the contrast carefully, especially on buttons and headings placed over images.

Typography should support the content structure, not compete with the design. The theme listing mentions advanced font controls, including Google Fonts and custom font uploads. But every extra font adds page weight. For a production site, one primary type family and one expressive accent for headings is often enough. If the demo uses bold display fonts, test readability and character support on mobile screens.

Homepage: demos, WPBakery templates, and Content Block

In Pepper, the homepage is usually built not as a plain page, but as a composition of sections: hero area, value proposition, portfolio, services, testimonials, call to action, blog, form, or store block. WPBakery Page Builder helps manage that through rows, columns, and content elements. On top of that, the Pepper listing mentions prebuilt element templates and Smart Content Block, which make it possible to save reusable sections and place them in different parts of the site.

The official WPBakery knowledge base includes sections on templates, responsive settings, drag and drop, full-width rows, image galleries, parallax backgrounds, and other elements. That matters for Pepper because the theme extends WPBakery with its own templates and visual system. Still, page setup should begin with content strategy: which sections users actually need, which ones can be removed, where the main call to action belongs, and how many projects should appear on the homepage.

How not to drown in demo blocks

After a demo import, it is easy to leave too many sections in place. The homepage may look impressive, but also overloaded: multiple hero animations, carousels, galleries, sliders, icon blocks, video backgrounds, and repeated calls to action. For a real website, it is better to review the page from top to bottom and ask one question about each block: does it help the visitor understand the offer or make a decision?

For a first working version, the following is usually enough:

• A hero section with a clear promise, one button, and a strong visual anchor.
• A short services or focus-areas section.
• A portfolio or results section, if the site sells expertise.
• A trust block: clients, testimonials, proof points, certifications, or case studies.
• A contact block or form.
• A short blog feed, if the blog will actually be maintained.

If a block looks beautiful but does not serve a purpose, remove it or move it to an inner page. Pepper gives you plenty of visual material, but the editor's job is to turn that material into a user journey, not a showroom of everything the theme can do.

Element templates and reusable sections

Prebuilt WPBakery templates are convenient for a fast start: you can add a section, replace the text and images, then adjust spacing and colors. But they work best as a foundation, not as the final design. Check for extra elements inside them, hidden columns, demo links, animations, and oversized images. After adding a section, open the page on a mobile screen and confirm that the columns reflow correctly.

Smart Content Block is useful for repeated areas such as the footer, top bar, page title area, promo block, or CTA. For example, if you have several service landing pages with the same bottom section inviting visitors to discuss a project, it is better to create one reusable block than to copy the same section manually across every page. When the text or phone number changes, that saves time and reduces the risk of inconsistencies.

Hero section and slider

Pepper demos tend to feature large hero sections, sometimes with saturated backgrounds and dynamic graphics. If Revolution Slider or a similar slider is used, test it separately: the text should remain readable, buttons should lead to real pages, images should be optimized, and the mobile version should not crop out the main message. A slider often looks great in a demo, but becomes heavy on a real site if you upload large images and leave in unnecessary animations.

For most websites, one strong hero block is better than several slides the visitor will never fully view. If you really need a slider, keep it to 2 or 3 slides with distinct purposes: service, case study, contact. Every slide should communicate something different, not just swap the background.

Header, Mega Menu, footer, and widgets

Pepper includes multiple header layouts, a built-in mega menu, and settings for the top bar, mobile header, footer, and sidebars. These elements form the site's navigation framework. If the homepage looks polished but the menu is confusing, the footer is empty, or the mobile header covers the content, users will not make it to the page they need.

Start with menu structure, not visual effects. WordPress lets you build menus through Appearance - Menus in the classic workflow, or through navigation blocks in newer setups. With a theme in this class, it is important to understand which mechanism the specific installation uses: classic menus, theme settings, WPBakery blocks, or a combination of those.

Navigation without unnecessary depth

A mega menu is useful when the site truly has many sections: services grouped by category, a portfolio split into categories, a store with collections, or a blog with multiple topic clusters. But if you only have 5 to 7 main pages, a standard menu is enough. An overly complex mega menu on a small site creates a sense of artificial bulk and makes the mobile version harder to use.

Review the menu in three states: desktop, tablet width, and mobile. Make sure the active items are clear, submenus open predictably, external links are indicated logically, and the contact or order button does not disappear. If the menu is built through Pepper's settings, avoid duplicating the same links in multiple places unless there is a real reason.

The footer as working navigation

In a multi-purpose theme, the footer is often imported as an attractive demo block, but on a real website it should solve concrete tasks: contact details, short navigation, links to important pages, social profiles, privacy policy, business details, a signup form, or a call to action. In Pepper, the footer can be configured through theme settings and reusable blocks, so define the content first and style it second.

If the footer is built through Smart Content Block or WPBakery, check where it is attached: globally through the theme, through a preset, or on an individual page. A common mistake is editing the footer in one place but not seeing the change on some pages because another preset or a local override is taking precedence.

Widgets and sidebars

The Pepper listing says the theme is widget ready and includes custom widgets. WordPress documentation also reminds us that widget areas depend on the theme and may appear in the sidebar, footer, or other locations. After importing the demo, review Appearance - Widgets or the relevant customization screen to see which areas are actually active.

For a blog, the usual widgets are search, categories, recent posts, and possibly email signup. For a portfolio, a sidebar is often unnecessary because a clean project grid works better. For a store, review filter widgets and WooCommerce blocks separately, since they depend on the products, attributes, and store plugins you are using.

Portfolio, blog, and WooCommerce store

One of Pepper's strongest practical advantages appears in its content types. The theme listing highlights a portfolio panel, a dedicated Portfolio item in the admin area, multiple portfolio layouts, blog settings, and WooCommerce compatibility. That means the theme is built not only for static landing pages, but for a site that can be regularly expanded with projects, articles, and products.

Portfolio as proof of expertise

In Pepper, the portfolio works best not as a gallery of random images, but as a system of case studies. For each project, prepare a title, a short project goal, 2 to 4 images, the result, a category, and a link if one makes sense. If the theme lets you choose the layout for an individual project, use it intentionally: a visual case study needs a large media-focused layout, while a corporate project may need more text about the challenge, process, and outcome.

Do not create too many categories at the beginning. Three to five clear directions are better than a dozen empty filters. After setting up the portfolio, review the archive page, the individual project page, the filters, breadcrumbs, the SEO title, and image behavior on mobile.

Blog layouts and information architecture

Pepper includes multiple blog layouts and settings for listing, search, and single post pages. For an agency or studio site, a blog can add real value if it answers client questions, demonstrates expertise, and supports internal linking. But the blog should not look like a demo section full of empty categories. Create a few real categories, configure the posts archive page, and review the preview cards, date, author, excerpt, featured image, and related-post area.

If the site is small, do not overload the blog listing with heavy animation and excessive metadata. Visitors care more about understanding the topic quickly and clicking through. From an SEO perspective, make sure each post has one primary site heading, clear subheadings, a readable URL, an optimized image, and an internal link to a service or case study.

WooCommerce: when to enable the store

Pepper's WooCommerce compatibility is useful for a small catalog, digital products, merch, or studio services that can be paid for online. But the store should only be enabled when you are ready to configure not just the visual layer, but the actual business flow: products, variants, cart, checkout, emails, shipping, taxes, payment methods, and a test order.

After activating WooCommerce, do not review only the storefront homepage. Open the product archive, product page, cart, checkout, account area, and email templates. The theme may style the core elements nicely, but the final experience depends on WooCommerce settings and payment plugins. If you do not need the store immediately, do not leave demo products on the public site. They undermine trust and may get indexed.

Practical scenario: a creative studio website in one working cycle

Below is a concrete example of how to use Pepper for a clear task rather than in the abstract: building a creative studio website with a homepage, portfolio, blog, and inquiry form. The same scenario can be adapted for a freelancer, agency, architecture studio, or app showcase, but the logic stays the same: choose the closest demo, remove the excess, configure the structural framework, replace the content, and review the result.

Goal

The goal is a site where a visitor immediately understands the studio's specialty from the hero section, sees 3 to 6 strong projects, can move to the services area, read 1 or 2 expert articles, and submit an inquiry. The design should preserve Pepper's bold style without looking like an unchanged demo import.

Preparation

On the staging WordPress site, Pepper is installed, the required plugins are active, and a demo with a suitable structure has already been imported. The logo, brand palette, service list, 4 case studies, 2 articles, contact email, social links, and homepage copy are prepared. A backup has been created before editing begins.

Steps

1. Set the imported demo page as the homepage through WordPress reading settings.
2. Open the page in WPBakery and remove the sections that do not support your goal: extra sliders, demo logos, empty carousels, and unused promo blocks.
3. In the hero section, replace the heading, subheading, button, and image. The button should lead to the contact section, a service page, or the portfolio, not to a demo link.
4. Create a services block with 3 or 4 focus areas. For each one, add a short explanation of the result, not just generic wording.
5. Populate the portfolio: categories, images, project descriptions, links, and display order.
6. Configure Theme Options: logo, main color, typography, default header, and footer.
7. Create or review a Preset for the homepage if it needs to differ from the inner pages.
8. Build the menu: Home, Services, Projects, Blog, Contact. If you use a mega menu, keep it only for sections that truly need nesting.
9. Set up the form with Contact Form 7 or another chosen plugin, submit a test inquiry, and verify the email.
10. Open the site in a private browser window and review the visitor journey from the hero section to the inquiry form.

Review

The result can be considered working if the homepage loads without visible errors, there is no leftover demo text, all buttons lead to the correct sections, the portfolio opens correctly, the form sends email, the menu is clear on both desktop and mobile, and the footer shows real contact information. Separately, make sure it is obvious in the admin area where each major block is edited.

Important nuance

If the header or footer does not change after editing the homepage, first check the settings hierarchy: Page Settings, then the applied Preset, then Theme Options. If WPBakery shows the section correctly in the editor but the public page does not update, clear the site cache and browser cache. If styles are missing, temporarily disable CSS/JS minification and test again.

Reviewing the result before launch

Once Pepper is configured, review the site not just as a designer, but also as an editor, administrator, and visitor. A beautiful screen is not enough. The site needs to load quickly, display the menu correctly, guide visitors along a clear path, avoid leftover demo links, work properly on mobile, and stay compatible with your plugins.

Front end

Check the homepage, an inner page, the portfolio, a blog post, the contact page, and store pages if WooCommerce is active. On each page, review the header, title area, spacing, images, buttons, breadcrumbs, footer, and form. If one page suddenly shows a different style, the reason is often a preset or local page settings.

Pay attention to media files. Pepper demos rely on striking images and large visual compositions, so the real assets must be prepared properly: correct dimensions, compression, consistent editing, and meaningful alt text. You cannot simply upload 6000px source photos and expect the theme to solve performance on its own.

Responsiveness

Do not check only whether the site "fits on the screen." Check whether the meaning survives. The hero section should still show the main message and button, the menu should open without overlapping, portfolio filters should remain accessible, forms should stay usable, and WPBakery columns should not collapse into an overly long and repetitive single-column flow. If a block looks good only on a large desktop monitor, simplify it: fewer columns, fewer animations, more breathing room between sections.

SEO and indexation

The theme does not replace an SEO plugin or editorial work. Make sure unused demo pages are deleted or blocked from indexation, page titles are clear, URLs do not contain leftover demo wording, images have alt text, and important pages are connected through internal links. If the site uses a portfolio, add actual descriptions to projects instead of relying on images alone.

Performance and caching

Multi-purpose themes with page builders can produce heavy pages if you leave all demo effects enabled. After the final design is in place, enable optimization gradually: first image compression, then page caching, then CSS/JS minification, then deferred loading for individual scripts if it does not break sliders and forms. After each step, test the homepage, menu, form, and portfolio. If something breaks, roll back only the last step instead of undoing everything at once.

Safe improvements through a child theme

If the visual setup is almost done but you still need a few small refinements, do not edit the Pepper parent theme files. WordPress documentation on child themes explains directly that changes like these should be kept separate so parent theme updates do not wipe out your work. That is especially important with Pepper: the theme is updated over time, depends on plugins, and includes a set of templates, so edits inside the parent folder quickly turn into technical debt.

The safest type of enhancement is a small CSS adjustment in the child theme or in the built-in Additional CSS field if the theme provides one. Below is an example for a situation where you want to make hero section buttons slightly more readable over a saturated background. The selectors are intentionally generic, so verify the actual classes on your page with your browser inspector before applying them.

/* Child theme or Additional CSS field.
   Goal: improve button readability in the hero section without editing Pepper files. */
.home .hero-section .btn-primary,
.home .wpb_wrapper .btn-primary {
  border-radius: 4px;
  font-weight: 700;
  letter-spacing: 0;
  box-shadow: 0 10px 24px rgba(89, 38, 185, 0.24);
}

.home .hero-section .btn-primary:focus,
.home .wpb_wrapper .btn-primary:focus {
  outline: 2px solid #ffffff;
  outline-offset: 3px;
}

After adding the CSS, review the homepage, inner pages with buttons, the mobile layout, and keyboard focus states. If the change affects extra buttons you did not intend to style, narrow the selector to a specific section or add your own CSS class to the WPBakery row. Rolling back is simple: remove the CSS snippet and clear the cache.

Do not add PHP snippets without confirmed hooks from the specific theme. If you need to change the output of the portfolio, header, or footer, first look for a native Pepper setting, then a child theme solution, and only then consider targeted code. Editing parent theme files should be treated as a last resort for temporary diagnostics, not as a permanent solution.

Common Pepper setup issues and how to diagnose them

Most Pepper issues are caused not by one "broken" file, but by a combination of demo import behavior, dependent plugins, caching, local page settings, and expectations around WPBakery. The list below is not a universal catalog of every possible WordPress error. It is a practical troubleshooting guide specifically for a multi-purpose theme with demos, presets, and a page builder.

The demo import finished only partially

Symptom: some pages were created, but images are missing, the slider is empty, the menu was not assigned, or the homepage does not resemble the selected demo. Possible causes include hosting limits, import timeout, a required plugin not being active, blocked external image downloads, or a repeated import over old data.

Start by checking whether the demo-required plugins are active. Then open the media library, the pages, and the menus. If the content was created only partially, do not run the import again without a backup. You may end up with duplicate pages and duplicate menus. On a staging site, it is usually easier to reset the installation and repeat the import with higher hosting limits or choose a different demo package.

A setting in Theme Options does not affect one specific page

Symptom: you changed a color, header, or background in the global settings, but one page still looks the same. The likely cause is an assigned Preset or a local override in Page Settings. Pepper intentionally supports that hierarchy, so this is not always a bug.

Open the page editor and check the local settings first, then check the preset. Temporarily disable the override or apply the default preset. If the change appears, you have found the cause. If not, clear the cache and make sure you are editing the published page rather than a draft or duplicate.

WPBakery shows shortcodes or will not open the editor

Symptom: you see shortcodes instead of sections, the editor keeps spinning, or some elements are unavailable. Possible causes include WPBakery being disabled, a conflict with another editor, a JavaScript error, an incompatible optimization plugin, blocked REST/AJAX requests, or a problem introduced by an update.

Check whether WPBakery is active and allowed for the relevant post types. Temporarily disable JS minification and admin caching. Then inspect the browser console and the error log. If the issue appeared after a theme or plugin update, review the changelog and test a rollback on a staging copy, not on the live site.

The mobile menu or sticky header covers the content

Symptom: on mobile, the menu covers the first section, buttons cannot be tapped, or the sticky header takes up too much space. The cause is often a combination of header layout, top bar, logo height, mega menu behavior, and local page settings.

Check the mobile header settings in the theme, reduce the logo size, disable an unnecessary top bar on mobile, and test several pages. If the issue happens only on one page, look for a local header setting or an overly small top margin on the first WPBakery block.

Animations, the slider, or the form stop working after optimization

Symptom: everything worked before caching was enabled, but after JS minification or deferred loading, the menus, slider, or form stopped working. The cause is that the optimizer changed the script loading order or merged files that need to remain separate.

Disable the last optimization option you enabled and test again. Then add exclusions for the slider scripts, WPBakery, Contact Form 7, or specific theme files if needed. Do not disable all performance improvements forever. Find the smallest exception set that restores the interface.

WooCommerce pages do not look like the demo

Symptom: the product page, cart, or checkout looks different from the polished store view in the demo. Possible causes include different WooCommerce versions, active payment and shipping plugins, missing product images, undefined attributes, a third-party checkout template, or a CSS conflict.

Start by testing the core WooCommerce pages without extra checkout-related plugins. Add one test product with a proper image, price, description, and attributes. Then enable payment and shipping plugins one by one. If only the checkout is broken, do not assume the theme is at fault immediately. In many cases, the payment, shipping, or checkout plugin is what is changing the page.

Official video on demo import

The Pepper listing includes a link to an official video from the G5Theme playlist about One Click Install Demo Data. It is useful specifically as a visual companion to the installation section because it shows where to find the demo import tool and what the starter site setup process looks like. The video does not replace a backup or a proper result review, but it helps you understand which screens to expect after installing the theme.

After watching it, return to your own site and check three things: whether you imported the correct demo layout, whether the homepage is assigned, and whether any demo menus are still in place. If the video shows a different screen flow, follow the current theme admin interface and official documentation, since interfaces can change over time.

When ThemeForest Pepper is a good choice

Pepper is worth using if you need a visually expressive multi-purpose WordPress theme with ready-made demos, WPBakery editing, portfolio support, a blog, WooCommerce styling, and a flexible settings system. It is especially well suited to creative studios, agencies, freelancers, showcase websites, portfolios, and small stores where visual presentation matters almost as much as the content itself.

Before publishing, do not stop at installation and a logo swap. Go through the full cycle: staging setup, backup, importing one suitable demo, configuring Theme Options, applying presets carefully, checking Page Settings, building the homepage, configuring the menu and footer, testing the form, reviewing responsiveness and performance, and cleaning up demo content. That is the workflow that turns a beautiful marketplace theme into a working website.

If you are ready to test the theme on a staging copy and continue setup on your own project, you can download the latest version of ThemeForest Pepper and follow the installation steps from this guide. As soon as you download the archive, separate the installable theme ZIP from the full package, prepare the child theme for edits, and do not import demo content onto a live site without a backup.

The main selection criterion is not the number of demos or how flashy the cover image looks. Pepper is a good solution only if its structure, editor, and visual language match the goals of your site. If they do, the theme can give you a fast start and a clear setup system. If they do not, it is better to choose an alternative early than to spend time forcing the template against its own design logic.