CodeCanyon Material WP - WordPress Plugin

Guide to Setting Up CodeCanyon Material WP for the WordPress Admin Area

CodeCanyon Material WP is not meant to change the public-facing side of your site. Its job is different: to make the WordPress admin panel cleaner, easier to manage, and easier to understand. In this guide, we will walk through how to prepare the site, install the plugin, enable the new styling, configure menus, roles, the login page, custom CSS, import and export settings, and then verify that the redesigned admin area does not interfere with editors, stores, forms, or other working plugins.

This guide is intended for a site owner, webmaster, or agency handing WordPress off to a client and wanting to remove unnecessary clutter from the dashboard. We are not going to repeat the product's marketing copy. Instead, we will follow a practical workflow: what to check before installation, where to find the settings after activation, which toggles to enable carefully, how to tailor the interface for a client, and what to do if the styling conflicts with another plugin.

Because Material WP evolved as an admin theme and appears in different builds, the exact set of tabs may vary. The sources confirm the core tabs Styling Settings, Functionality, Custom CSS, Import / Export, and Activate Material WP, while newer changelog descriptions mention styling presets, dark mode, and expanded menu editing. That is why the guide below separates the essential setup logic from the settings you should verify against your own version.

What Actually Changes in the Admin Area After Installation

Material WP belongs to the class of plugins that restyle and partially reorganize the WordPress admin area. Its purpose is not to add a new post type, form, gallery, or editor block. It changes the visual shell: menus, the top bar, panels, buttons, the login page, some system elements, and the behavior of certain administrative screens.

This is important to understand before installation. The plugin works in an area where other extensions are already active: WooCommerce adds orders and reports, SEO plugins add metaboxes, form plugins open their own builders, and page builders load their own panels. Any admin theme should do more than look good - it must coexist properly with those screens. That is why Material WP is best treated as a working interface configuration tool, not just a design swap for looks alone.

Based on confirmed sources, the product can handle several practical tasks:

• Restyle the WordPress admin area in a Material Design style.
• Provide settings for colors, sizing, the top bar, and the sidebar menu.
• Allow menu reordering and, in some versions, menu hiding and role- or user-based control.
• Customize the login page, logo, logo link, and individual elements of the authentication screen.
• Add a custom CSS field and, in older descriptions, support SCSS syntax.
• Save and transfer settings through import and export.
• Work in WordPress Multisite so that global settings can be managed at the network level when the plugin is activated by the network administrator.

The plugin delivers the most value when multiple people actually use the admin area. If the site is maintained by a single developer who is already comfortable with the default WordPress interface, the benefit will be modest. If the admin area is used by a client, editor, store manager, or content team, a cleaner menu and clearer visual structure can save support time.

Who This Admin Theme Works Well For, and When It May Get in the Way

Material WP fits well into projects where WordPress is used as a managed system for a client. An agency can configure colors, a logo, menus, and the login page so the dashboard feels like part of the project rather than a technical zone full of extra links. This is especially noticeable in multisite setups: one network may serve several client sites, and the administrator may want to maintain a consistent structure everywhere.

Good Use Cases for Implementation

This plugin is worth considering if you need to make the admin area calmer and more predictable. For example, a client usually does not need dozens of menu items related to development, migration, or SEO auditing. An editor is better served by seeing posts, pages, media, forms, and store tools than by accidentally opening cache settings or system utilities. In that scenario, Material WP helps not only with color styling but also with interface organization.

Another good fit is a site with multiple user roles. If your version of the plugin supports applying the styling to specific roles or users, you can enable the new interface first for a test administrator, then for editors, and only after that for everyone else. That gradual rollout reduces risk: if a form screen, store screen, or page builder panel renders oddly, you can catch the issue before handing the site over to the client.

When a Different Tool Is the Better Choice

Material WP may be unnecessary if you do not need styling, but a full client dashboard with custom widgets, instructions, document links, and a more advanced access model. In that case, client dashboard and white-label plugins may be a better fit, since they are specifically designed to build a separate working start page for the client. Material WP is strongest as a visual admin theme and menu organizer.

You should also be more cautious on sites where the admin area is crowded with complex interfaces: form builders, CRM systems, LMS platforms, WooCommerce reports, spreadsheet editors, and visual page builders. The Material WP changelog includes many compatibility fixes for plugins like these. That is a positive sign of ongoing development, but also a reminder: any admin theme can affect third-party CSS and JavaScript inside the dashboard. A live site should always be tested before rollout.

What to Check Before Installing on a Live Site

Before installing Material WP, you do not need to change the site's architecture, but you do need a safe rollback point. The plugin affects the admin area, so a problem may not break the public side of the site, but it can interfere with site management, post saving, or other plugins. It is better to do this check during a calm maintenance window, not the night before a project handoff, when you still have access to hosting and a backup.

Minimum Preparation

1. Create a backup of the files and database, or confirm that your hosting provider has already created a recent restore point.
2. Make sure you have access not only to the WordPress admin area, but also to the file manager, hosting panel, or SFTP. That will help if you need to disable the plugin outside WordPress.
3. Check who is currently working in the admin area. Do not change the interface while someone is doing bulk edits to products, orders, forms, or pages.
4. Prepare a list of critical screens: the post editor, product page, orders, forms, SEO settings, page builder, media library, menus, and users.
5. If the site uses multisite, decide in advance whether the plugin will be enabled at the network level or only on a single site.

A practical checkpoint: if after installation you can open your critical screens, save a test post, open the plugin settings, and disable it again within five minutes, the rollout is already under control.

Special Considerations for Multisite

In WordPress Multisite, a network administrator can activate the plugin for the entire network. Material WP documentation describes a scenario where, after network activation, the settings menu appears in the network admin area and the configuration is applied across network sites. That is convenient for a platform with a unified look, but it is not always the right choice if each site has its own owner and its own style.

Before enabling it network-wide, answer two questions. First, do all sites really need the same settings? Second, are there plugins used only on individual sites that may introduce their own unusual admin screens? If the answer is unclear, it is safer to start with a staging subdomain or a site copy rather than changing the whole network at once.

Installation and Initial Verification Without Putting the Admin Area at Risk

Material WP is installed like a standard WordPress plugin from a ZIP archive. In the default admin area, the path usually looks like this: Plugins, then Add New, the Upload Plugin button, select the archive, then Install Now and Activate. If you are working with a site network, the action may be called Network Activate and be performed from the network admin area.

After activation, do not rush to enable every feature right away. First, check whether a Material WP item appears in the left menu, whether the settings page opens, and whether standard WordPress elements are still visible. If the interface changes sharply, that is expected, but a more important question is this: do the save buttons work, do dropdowns open correctly, and does the top bar overlap elements from other plugins?

First Walkthrough Check

Do a quick walkthrough of the admin area in one browser and then again in a private window. This helps separate a real issue from browser cache or stale styles. Open these screens:

• Dashboard - make sure the panels do not overlap.
• Posts or Pages - check the list table, filters, and bulk actions.
• The post editor - save a draft and confirm that the editor sidebar is available.
• Appearance and Menus - if you work with menus, make sure menu items expand properly.
• The project's key plugins - WooCommerce, forms, SEO, LMS, or the page builder.

If everything opens correctly, move on to configuration. If the settings screen does not load or elements overlap each other, do not start picking colors. First, check for admin-side cache conflicts, disable minification for the admin area, hard refresh the page, and temporarily disable other plugins that modify the admin menu or top bar.

Material WP Settings Map After Activation

The Material WP documentation describes a layout with several tabs. In your version, the names may differ slightly, but the logic is usually the same: style first, then functionality, then custom CSS, then settings transfer, and finally a separate theme activation step. That order is the most practical. If you start with CSS and then change the core colors and dimensions later, some of your manual tweaks may need to be redone.

Styling Settings: colors, sizing, and the overall look

Start by adjusting the appearance without making radical changes. Choose a base palette, check text contrast on buttons and panels, and evaluate the sidebar width. Older descriptions of Material WP mention menu width and height settings, top bar height, and a parallax block. The changelog also notes that the plugin accounted for text contrast based on selected colors, but that does not remove the need for manual review.

For a typical client site, it is best to begin with a neutral scheme: a dark or calm sidebar menu, a single accent color for active elements, and no overly bright backgrounds. If your version includes presets, do not pick the most dramatic one just because it stands out. The admin area is a working tool. An aggressive palette becomes tiring quickly, especially if an editor spends several hours a day in it.

How to Check the Color Setup

Open the posts list, the post editor, and the settings page of one large plugin. Check not only the attractive main screen, but also smaller elements: checkboxes, tabs, notices, Save Changes buttons, bulk action links, and dropdowns. If text on buttons becomes hard to read, go back to the palette and tone down the contrast experiments.

Functionality: what to enable carefully

The functionality tab matters more than it may seem. It may contain options that hide interface elements, change menu behavior, disable the Help and Screen Options tabs, control icons, the top bar, menu position, or how the theme is applied to users. The approach is simple: enable only what solves a clear problem.

For example, hiding Help and Screen Options can make the admin area cleaner for a client, but a developer or experienced editor may still need those tabs for table configuration and display troubleshooting. If you are unsure, leave them enabled for administrators and restrict them only for client-facing roles if your version allows it.

Custom CSS: targeted fixes instead of rewriting the admin area

Custom CSS is useful when you need to fix one small visual detail: spacing, logo height, note color, or the behavior of a specific panel. Do not use it as a way to rewrite half the interface. The more manual CSS you add, the greater the risk that selectors will stop matching after a WordPress or plugin update.

A safe workflow looks like this: first configure what you can through the Material WP interface, then review the standard screens, then add one targeted CSS tweak, then test again. If the tweak is not needed for all users, it is usually better to skip it or scope it to a specific page class rather than a broad selector affecting the entire admin area.

Import / Export: a settings backup before experiments

Import and export are useful for more than just moving settings between sites. They are also a simple way to preserve a working configuration before you experiment. Once you have configured the palette, menu, and login page, export the settings. Then you can test new colors, menu positions, or hidden elements knowing that the working version can be restored.

Settings export is especially useful for agencies and multisite setups. A configuration prepared once can become a starting profile for similar projects. But do not transfer settings blindly: another site may have a different mix of plugins, roles, and menu items.

Activate Material WP: enabling the theme as a separate step

The documentation mentions a separate activation tab for Material WP. That is convenient: you can prepare the settings first and only then turn the theme on. If your version works this way, use that to your advantage. Configure the base style first, export the settings, and then activate the theme for a test user or role if that level of granularity is available.

If your version activates the theme immediately when the plugin is enabled, the order changes: after installation, first review the critical screens, then adjust the settings gradually. In either case, the goal is the same - do not lose control of the admin area for the sake of a visual effect.

Menus, Roles, and Multisite: Where Material WP Requires Discipline

One of the most useful parts of Material WP is its menu handling. The sources confirm drag-and-drop menu items, per-user ordering, menu hiding, and, in the newer changelog, editing for top-level and nested menu items. But this is also the easiest place to cause problems: hiding a menu item does not remove the feature itself, but it can make users think it is gone.

How to Organize the Menu for a Client

Start with the user's real workflow. A client usually needs posts, pages, media, forms, products, orders, users, and settings that actually relate to day-to-day work. System tools, migration features, file editors, cache controls, SEO auditing, and security settings should remain available to the administrator, but they do not need to occupy the top positions.

A practical order for a client site may look like this: Dashboard, content, media, forms or store tools, appearance, users, and then the rest of the settings. If Material WP allows you to hide menu items by role, do not hide them for everyone right away. Test first with a dedicated editor role or a separate test user.

Why You Should Not Confuse Menu Hiding with Access Control

Hiding a menu item is an interface improvement, not a full security model. If a user should not be allowed to perform an action, that should be enforced through WordPress roles and capabilities, not only by removing a link from the sidebar. Use roles, capabilities, and trusted access-control plugins for security. Use Material WP as the visual layer that makes an already sound access model easier to understand.

How to Roll It Out on Multisite

On multisite, you should not immediately enable the styling across every site in the network unless you already have a staging copy. Start by testing one site with a typical set of plugins. Then test a site with a different plugin mix: for example, one using WooCommerce, another using an LMS, and a third using forms and a page builder. If the menu and key screens render correctly everywhere, you can move the settings up to the network level.

If the plugin is activated by the network administrator, individual sites may see it as a global setting. That is convenient for a platform, but it requires internal team documentation: who is allowed to change the global palette, who is responsible for exporting settings, where the working profile is stored, and how to roll back an unsuccessful change.

The Login Page, Top Bar, and Parallax Block

The login page is the most visible element for a client. They see it before entering the admin area, so the logo, background, and links need to look polished. The sources mention login page styling, the ability to change the logo link, show or hide the Back to Blog link, and a separate option not to load styles on the login page. If those settings are not available in your version, use only the options you actually have and do not try to recreate missing features through heavy-handed CSS.

Configuring the Login Page

Start with the logo and background. The logo should remain readable against the chosen background, and the background should not compete with the login form. If the background is too contrast-heavy, the form can look like a random layer placed over an image. For a working admin area, calmer colors, a subtle gradient, or a solid background usually work better.

Do not hide password recovery links without a clear reason. A beautiful login screen is useless if an editor cannot regain access. If you hide Back to Blog, make sure that does not stop users from quickly returning to the site after a failed login attempt. On client projects, it is often better to leave a minimal path back than to create a fully closed-off storefront experience.

The Top Bar and the Front End

The Material WP changelog mentions the behavior of the top bar and style loading on the front end several times. This matters. The plugin can affect the WordPress top bar that logged-in users see while browsing the site. If a setting touches the public-facing side, test it separately: open the site as an administrator, as an editor, and as a regular visitor who is not logged in.

On the front end, admin styling should be as unobtrusive as possible. If enabling the top bar breaks spacing, overlaps the header, changes theme styles, or loads extra CSS for regular visitors, disable the problematic setting and keep the styling limited to the admin area.

The Parallax Block and Visual Effects

Older descriptions of Material WP mention a parallax block and settings for its height. This is a decorative area that can make the admin interface feel more distinctive, but it should be used with restraint. A very tall block takes space away from working data, especially on smaller screens. If editors spend every day in order lists or post lists, compactness matters more than a dramatic first impression.

The best approach is to enable the visual block, set a moderate height, check the Dashboard screen, and then see whether it gets in the way on pages from other plugins. If you notice horizontal scrolling, layout shifts, or overlapping buttons, reduce the height or replace the parallax block with a simple color section if that option exists.

Practical Scenario: Build a Clean Admin Area for a Client

Let us look at a concrete scenario. You have a WordPress site for a company. The client will publish news, update pages, review form submissions, and occasionally update products or services. The developer needs to keep the admin area understandable without losing access to technical settings.

Goal

Create a clean admin panel where the client sees only the working areas they need while the developer retains full access. The interface should match the project, the login page should be branded, but WordPress functionality should not be disguised to the point where the client becomes confused.

Preparation

Before configuring anything, create a test user with the same role the client will have. If the client will be an editor, create an editor. If they will be a store manager, create a role with the required WooCommerce capabilities. Do not configure the interface only for a super admin: that account sees more menu items and does not reflect the real client experience.

Configuration Steps

1. Install and activate Material WP on a staging site or during a quiet work period.
2. Open Material WP and set the base palette in Styling Settings: a calm menu background, readable text color, and one accent color.
3. Check the sidebar width. If menu labels are being cut off, increase the width or shorten the labels through a safe menu editor if that feature exists in your version.
4. Move on to the functionality settings. Keep Help and Screen Options available for the administrator, but decide whether they should be hidden for the client.
5. Reorder the menu: put content and submissions higher, technical items lower. Do not hide system sections from the administrator.
6. Configure the login page: logo, background, logo link, and basic form readability.
7. Add custom CSS only if a specific small issue remains after the standard settings are in place.
8. Export the settings in Import / Export to preserve the working profile.
9. Log in as the test user and repeat the client's main workflow.

Verifying the Result

Verification does not end with a nice-looking Dashboard. Create a test post, upload an image, open the submissions form, check the products or services list, edit a page, and save a draft. If the client will work with the site's menus, open Appearance and confirm that menu item drag-and-drop still works. If the site uses forms or a page builder, test those panels separately.

A good result is not just a new design, but preserved usability for familiar day-to-day actions. If the editor cannot find a submission or save a page, the interface should be simplified.

A Detail People Often Forget

After configuration, create a short instruction for the client: where to create posts, where to review submissions, where to manage media, and which areas they should avoid unless coordinated with you. Material WP can bring visual order to the dashboard, but it does not replace training. The less the client depends on verbal reminders, the less likely they are to change technical settings by accident.

Checking Performance, Security, and Compatibility

An admin theme should not be judged only by its appearance. You should test it in three areas: whether it slows down administrative screens, whether it hides important notices, and whether it breaks other plugins' interfaces. The Material WP changelog shows that the developers repeatedly fixed conflicts with third-party plugins, dynamic styles, the top bar, Gutenberg, WooCommerce Admin, Fluent Forms, Ninja Forms, WPBakery, Elementor Pro, LearnDash, and other tools. That is not a reason to panic, but it is a reason to test with purpose.

Admin Area Performance

Open several heavy screens before and after installation: the order list, reports, forms, media library, and a page editor. Evaluate not just the first load, but repeated visits as well. The changelog mentions caching for dynamic CSS and moving generated files into uploads to reduce permission issues. In practice, that means if styles are not being applied or load slowly, you should check write permissions in the uploads directory and clear cache.

Do not enable CSS/JS minification and combination for the admin area at the cache-plugin level without testing. Many optimization plugins let you exclude administrative pages. That may be useful for the front end, but the admin area often relies on scripts from different plugins, and aggressive optimization can create a conflict even when Material WP itself is not at fault.

Security and Access

Hiding interface elements is not the same as protecting them. If a user should not be able to change plugin settings, do not give them an administrator role just because the menu item is hidden. Use WordPress roles and trusted capability management tools. Material WP can make the menu cleaner, but access decisions should be made at the permissions level.

You should also avoid hiding update and security notices unless there is a strong reason to do so. The client may not need every bit of noise, but the administrator must still see system warnings. If important messages disappear after configuration, roll back that notice-hiding option or leave it enabled only for non-administrative roles.

Compatibility with the Block Editor and Major Plugins

Test the block editor separately. Saving a post, opening the sidebar, switching between document and block tabs, and uploading media are mandatory checks. The changelog includes fixes related to Gutenberg and post saving, so do not limit your review to the post list screen. If the site uses an older visual builder or a complex form editor, test it just as carefully.

For WooCommerce, review the orders list, an individual order, products, attributes, and reports. For forms, check the forms list, the builder, a test submission, and the entries page. For an LMS, test lessons, courses, users, and progress. The more deeply a plugin integrates into the admin interface, the more important it is to verify after enabling Material WP.

Safe, Targeted Improvements Through Custom CSS

The Custom CSS field in Material WP is useful, but it can easily become a source of future problems. A good CSS tweak solves one specific issue: aligning a logo, improving the readability of a label, hiding a decorative element that gets in the way on a small screen, or fixing spacing in a custom client block. A bad tweak tries to rewrite the whole admin area, changes global WordPress classes, and accidentally affects third-party plugin interfaces.

Before making any CSS change, save an export of your Material WP settings. Then add the adjustment in small steps. If you need to change an element on the login page, test the login page specifically. If you need to adjust the menu, test the posts list, the editor, and the screen of another major plugin. Do not use custom CSS as a substitute for role settings, security, or menu structure. CSS can hide an element from view, but it does not revoke a user's ability to access the action through a direct link.

Example of a Careful Login Logo Tweak

Suppose that after uploading a brand logo, it appears too large and pushes the login form down. If the plugin interface does not include a dedicated size setting, you can add a small CSS snippet. The selector below is only an example: before using it, inspect the element class in your own version with your browser's developer tools.

.login h1 a {
  max-width: 220px;
  background-size: contain;
}

After saving, open the login page in a private window. Check the logo, the form, the password recovery link, and the error message for an incorrect password. If everything remains readable, you can keep the tweak. If the logo disappears or the background starts behaving oddly, remove the snippet from Custom CSS and go back to the plugin's interface settings.

How to Document Tweaks for Future Maintenance

It is helpful to leave a short comment inside Custom CSS, but avoid long instructions and any personal data. The comment should explain why the tweak exists. That makes it easier a few months later to understand whether it can be removed after a plugin update.

/* Login logo size for client branding */
.login h1 a {
  max-width: 220px;
  background-size: contain;
}

If your tweaks grow beyond three or four rules, stop and reconsider the approach. You may be trying to solve a problem with an admin theme that actually calls for a dedicated branding plugin, more detailed role configuration, or a small custom plugin for the client dashboard. The fewer manual CSS exceptions you have in the admin area, the easier it is to update WordPress and third-party plugins.

What You Must Check After Adding CSS

• The login page displays the logo, form, login error, and password recovery link without overlap.
• The sidebar menu does not truncate labels, and nested items expand correctly in both normal and collapsed states.
• The block editor saves posts, opens the document panel, and keeps its publish buttons visible.
• The interfaces for forms, the store, the SEO plugin, and the page builder have not gained unexpected spacing or hidden buttons.
• On multisite, the tweak does not break sites that use a different plugin stack or a different set of menu items.

A proper rollback should be just as simple as enabling the change. Remove the added CSS, save the settings, clear the browser cache, and reopen the problematic screen. If rolling it back does not restore the previous appearance, the cause was not Material WP alone: check the cache plugin, browser styling, another admin customizer, or an update in a third-party extension.

Troubleshooting Issues After Enabling Material WP

Problems with an admin theme are usually visible right away: buttons overlap, the menu does not expand, styles are not applied, the login page looks wrong, the editor cannot save a post, or the top bar overlaps the site. Below is a practical troubleshooting sequence that avoids risky actions and does not require editing plugin files.

Styles Did Not Apply or Applied Only Partially

Symptom: part of the admin area looks updated, while part still looks standard; buttons use mixed styles; saving the settings changes nothing. Possible causes include browser cache, admin-side caching, a dynamic CSS generation issue, or write permission problems in the directory where the plugin stores compiled styles.

What to check: open the page in a private window, hard refresh it, temporarily disable CSS/JS optimization for the admin area, and verify write permissions in wp-content/uploads if your version generates styles there. Then save the Material WP settings again. If the problem disappears, export the working configuration.

Menu Items Disappeared for the User Who Needs Them

Symptom: the administrator sees everything, but an editor or manager does not see a required section. The possible cause may be menu hiding inside Material WP, a role without the required capabilities, or network settings that apply more broadly than expected.

What to check: log in as the test user, compare their role and capabilities, then temporarily disable menu hiding in Material WP. If the menu item comes back, the configuration was too strict. If it does not, the issue belongs to WordPress roles or another access-management plugin.

The Block Editor, Form, or Builder Opens with Visual Defects

Symptom: the editor sidebar is cut off, modal windows open behind the overlay, form fields overlap, or drag and drop no longer works. The likely cause is a CSS or JavaScript conflict between Material WP and a plugin that builds its own interface inside the admin area.

What to check: disable Material WP custom CSS and test the screen again. If that does not help, temporarily disable features that modify the top bar, menu width, panels, and utility tabs. If the defect disappears, re-enable those settings one by one. If it does not, check the browser console and the WordPress error log on a staging copy.

The Login Page Became Uncomfortable or Hard to Read

Symptom: the logo is too large, the form blends into the background, the password recovery link is hard to see, or the background loads slowly. The cause is usually overly decorative styling. The fix is simple: reduce the logo size, replace the background with a calmer one, restore the standard links, and review the screen on a regular laptop, not only on a large monitor.

On Multisite, the Settings Applied Somewhere Unexpected

Symptom: the styling appeared on multiple network sites or, on the contrary, did not appear on the site where you expected it. Check the activation method: standard site activation and Network Activate behave differently. If the settings were made at the network level, change them only after exporting the current profile. If one site needs its own style, do not use the network setting as a quick workaround.

Quick Troubleshooting Table

Symptom	Likely Area	First Safe Action
Colors did not apply	Cache, dynamic CSS, write permissions	Clear cache, save settings again, check uploads
A menu item disappeared	Menu hiding, role, network	Check with a test user and temporarily disable hiding
A modal window is covered	CSS conflict with another plugin	Disable custom CSS and any questionable visual features
The front end picked up extra styles	Top bar and style loading	Keep the styling limited to the admin area or disable its effect on the top bar

When CodeCanyon Material WP Is a Strong Choice

Material WP is worth using if you need a cleaner WordPress admin area, a more understandable menu for the client, login page customization, and the ability to move a visual configuration between projects. This is especially useful for agencies, multisite networks, and sites where the dashboard is used by people without technical experience.

Do not expect it to be a full permissions system, training center, CRM, or client portal builder. If that is your goal, look at the alternatives listed above. But if you need an admin theme that makes the WordPress working environment feel more modern and easier to manage, Material WP covers that class of tasks well.

Before rolling it out, save a backup, test your critical screens, export the working settings, and only then hand the admin area over to the client. Once the checks are complete and you understand why you are enabling this visual layer, you can get the CodeCanyon Material WP file and test it on your own project without unnecessary risk.