How to Give Metricfixer Safe WordPress and WooCommerce Access

Use this guide when Metricfixer needs access to a WordPress or WooCommerce website to diagnose an issue, review a theme or plugin, fix tracking, test checkout, inspect store settings, or deploy an approved change.

When to use this guide

This guide applies when the support task involves a WordPress or WooCommerce website.

Typical cases include:

• diagnosing broken pages, forms, checkout, product pages, cart behavior, coupons, shipping, taxes, or WooCommerce settings;
• fixing a custom theme, child theme, custom plugin, snippet, template override, or tracking script;
• reviewing plugin conflicts, PHP errors, WordPress debug logs, cron issues, failed webhooks, or slow admin behavior;
• checking ecommerce tracking, GA4, Google Tag Manager, Meta Pixel, TikTok Pixel, server-side events, consent behavior, or conversion tags;
• testing WooCommerce orders, payment gateway test mode, refunds, checkout events, and order status changes;
• preparing a staging environment or deploying an approved change from staging to production.

Preferred workflow

Metricfixer normally uses the following workflow for WordPress and WooCommerce work:

1. Confirm the issue, affected URL, expected result, and actual result in the ticket.
2. Use screenshots, logs, exports, and read-only information first when direct access is not required.
3. Work on a staging site whenever the issue can be reproduced outside production.
4. Use a temporary WordPress account created specifically for Metricfixer.
5. Use GitHub or limited SFTP access for custom theme/plugin code when code changes are required.
6. Test WooCommerce checkout with a test product, test coupon, sandbox payment method, or zero-value test flow where appropriate.
7. Deploy to production only after backup, approval, and verification.
8. Revoke temporary access after the ticket is completed.

Choose the minimum safe access level

1. No WordPress login

Use this for a first review when Metricfixer can diagnose the issue from the public website, screenshots, browser console output, network logs, plugin lists, WooCommerce status reports, or exported configuration files.

2. Staging WordPress access

Use this for most fixes. Create a temporary user on the staging site and give the role required for the task. Staging access is preferred for theme changes, plugin configuration, checkout testing, tracking changes, and troubleshooting.

3. Limited code or file access

Use this when the task requires editing a custom theme, child theme, custom plugin, template override, or deployment script. GitHub access is preferred. If GitHub is not available, provide SFTP/SSH access limited to the relevant WordPress project directory or specific wp-content paths.

4. WooCommerce store access

Use this when the task involves products, orders, coupons, taxes, shipping, reports, or store settings. A WooCommerce Shop Manager role may be enough for store operations. If the task requires plugins, themes, users, tracking code, or site-wide settings, an Administrator role may be required.

5. Production WordPress access

Use this only when the issue cannot be reproduced on staging or when Metricfixer must verify a production-specific setting. Production access should be temporary, limited, and approved in the ticket.

6. Hosting, database, or payment access

Use this only when WordPress admin access is not enough. Hosting, database, DNS, CDN, payment gateway, or cloud access should follow the separate Metricfixer access guides for those systems.

Before you provide access

Please add the following information to the ticket:

• website URL and staging URL, if available;
• whether the site is WordPress only, WooCommerce, WordPress multisite, WordPress.com, or self-hosted WordPress;
• WordPress version, WooCommerce version, PHP version, active theme, and whether a child theme is used;
• hosting provider and whether staging, backups, SFTP, SSH, file manager, or Git deployment are available;
• the affected URL, product, checkout step, form, plugin, theme template, or order flow;
• the exact expected result and actual result;
• screenshots, error messages, WooCommerce status report, debug log excerpts, or browser console errors where available;
• whether the issue affects production customers, payments, subscriptions, inventory, shipping, taxes, or email notifications;
• confirmation that a recent backup exists before any production code, plugin, database, or configuration change.

How to create the temporary WordPress user

Please create a separate temporary WordPress user for Metricfixer instead of sharing your personal account.

• Use a clear username such as metricfixer-support or metricfixer-ticket-1234.
• Use the role required for the task: Administrator, Shop Manager, Editor, or another limited role created by your site.
• Enable two-factor authentication if your site requires it and share access through the agreed secure method.
• Set an expiration date if your security plugin or user-management plugin supports temporary users.
• Do not send your own administrator password by email.

Recommended WordPress roles

• Administrator: use only when Metricfixer needs to manage plugins, themes, site settings, tracking plugins, snippets, cache settings, users, or debugging tools.
• Shop Manager: use for WooCommerce tasks related to products, orders, coupons, reports, taxes, shipping, and store operations when site-wide WordPress admin rights are not needed.
• Editor: use for content-only tasks such as pages, posts, media, and copy changes.
• Super Admin: use only for WordPress multisite tasks that require network-level access. Do not provide Super Admin for a normal single-site WordPress task.

WooCommerce-specific safety rules

WooCommerce stores contain order data, customer records, payment-related settings, inventory, taxes, shipping rules, and email notifications. Please keep access limited to the agreed task.

• Use a staging store for checkout, cart, payment, coupon, shipping, tax, and tracking tests whenever possible.
• Use test products, test coupons, test customers, and sandbox payment methods for checkout testing.
• Do not provide live payment gateway secret keys unless Metricfixer specifically confirms that the approved task requires them.
• Do not ask Metricfixer to place real paid orders, issue real refunds, cancel real customer orders, or change inventory on production unless this is explicitly approved in the ticket.
• If a production order must be reviewed, provide the order ID and the exact issue. Avoid exporting unrelated customers or full order history.
• If the site uses subscriptions or recurring payments, confirm whether the staging copy disables live renewals, customer emails, and live payment collection.

Staging site requirements

A safe WooCommerce staging site should be clearly separated from production.

• Use a staging domain or subdomain that is not indexed by search engines.
• Protect staging with a password or IP restriction when possible.
• Use sanitized or reduced customer/order data where possible.
• Disable or redirect customer-facing emails on staging unless email testing is part of the task.
• Use payment gateway test mode or sandbox credentials on staging.
• Disable live subscription renewals, real fulfillment, shipping labels, CRM automations, and marketing automations unless they are required for the task.
• Keep staging cache, CDN, and performance plugins aligned with production only when they are relevant to the issue.

SFTP, SSH, hosting, and file access

If file access is required, please provide the narrowest practical access.

• Prefer GitHub repository access for custom theme and plugin code.
• If SFTP is required, limit it to the WordPress project directory or the specific wp-content/themes, wp-content/plugins, or wp-content/uploads path needed for the task.
• Do not provide hosting master accounts, billing access, root SSH, unrestricted sudo, or access to unrelated websites.
• Do not send wp-config.php, database credentials, salts, or production .env-style secrets unless specifically requested for the approved scope.
• Avoid using the built-in WordPress theme/plugin file editor as the main development workflow.

Tracking, analytics, and pixels

If the task involves GA4, Google Tag Manager, Meta Pixel, TikTok Pixel, consent banners, or server-side tracking, WordPress access may not be enough. Metricfixer may also need limited access to the relevant analytics, tag manager, advertising, consent, or server-side tracking account. Please use the separate tracking and analytics access guide when those systems are involved.

Payment gateways and sensitive keys

Payment gateways such as Stripe, PayPal, WooPayments, Klarna, Mollie, Adyen, or local bank gateways should be handled carefully.

• Use sandbox or test credentials for staging.
• Let the customer account owner enter live credentials directly when possible.
• Do not send live secret keys, webhook signing secrets, private keys, or payment-provider owner credentials by email.
• Do not provide billing or payout access unless the approved task specifically requires it.
• Never send full payment card numbers, bank account credentials, or customer payment credentials to Metricfixer.

Backups before changes

Before production changes, confirm that a recent backup exists. A useful WordPress/WooCommerce backup usually includes:

• the database;
• themes, plugins, and custom code;
• uploads and media files if they are relevant to the task;
• wp-config.php or equivalent configuration files, kept securely;
• a known restore method or hosting snapshot.

What not to provide

Please do not provide the following unless Metricfixer explicitly confirms that it is necessary for the approved scope:

• your personal WordPress administrator account or password;
• WordPress Super Admin access for a normal single-site task;
• hosting master account, cPanel/Plesk owner account, billing access, or domain registrar owner access;
• root SSH, unrestricted sudo, or access to unrelated websites on the same hosting account;
• database root credentials or full production database dumps;
• live payment gateway secret keys, webhook secrets, payout settings, or payment-provider owner access;
• full payment card numbers, bank credentials, government IDs, health data, children’s data, or unrelated sensitive personal data;
• full customer/order exports when only one order ID or test order is needed.

If there is no staging site

If no staging site exists, Metricfixer may recommend creating one before implementation. If the issue is urgent and must be handled directly on production, the ticket should clearly confirm:

• why staging cannot be used;
• what will be changed;
• who approves the production change;
• that a recent backup exists;
• the preferred maintenance window, if the change may affect visitors, orders, checkout, payments, or email notifications;
• the rollback or restore approach where possible.

How to revoke access after completion

After the ticket is completed, please revoke or reduce all temporary access created for Metricfixer.

1. Delete or disable the temporary WordPress user.
2. Revoke WordPress Application Passwords, REST API keys, or plugin-specific tokens created for the task.
3. Remove temporary SFTP, SSH, hosting, or database users.
4. Remove temporary GitHub, analytics, tag manager, advertising, consent, CDN, or payment-provider access if it was granted.
5. Rotate any password, key, token, webhook secret, or credential that was shared temporarily.
6. Delete test users, test coupons, test products, or staging-only data that is no longer needed.
7. Keep the ticket notes, pull request, deployment log, and backup reference for your records.

Helpful official references

• WordPress roles and capabilities
• WooCommerce roles and capabilities
• WordPress Application Passwords
• WooCommerce email settings
• WooCommerce guide to backing up WordPress content