--- title: Preparing Information for VendorHearth Support description: "If you cannot resolve a VendorHearth Pro problem using the knowledge base and System Readiness tools, gathering the right information before requesting support can make troubleshooting much faster. You do not need to provide passwords or other sensitive credentials. ##…" url: "https://vendorhearth.com/docs/preparing-information-for-vendorhearth-support/" updated: "2026-09-23" category: Troubleshooting — System Information, email problems, payment issues, roles/access, common problems --- # Preparing Information for VendorHearth Support If you cannot resolve a VendorHearth Pro problem using the knowledge base and System Readiness tools, gathering the right information before requesting support can make troubleshooting much faster. You do not need to provide passwords or other sensitive credentials. ## Before Requesting Support Before reporting a problem: 1. Review the relevant VendorHearth documentation. 2. Check **VendorHearth → System Readiness**. 3. Confirm WordPress and PHP meet VendorHearth requirements. 4. Clear applicable website and browser caches. 5. Try to reproduce the problem. 6. Record any error messages. If the problem can be reproduced consistently, include the steps that cause it. ## Include Your VendorHearth Version Provide the version of VendorHearth Pro currently installed. Version information is important because features, fixes, and behavior can differ between releases. Do not simply state that you are using the "latest version." Include the actual version number shown by WordPress. ## Include Your WordPress and PHP Versions VendorHearth Pro requires: - **WordPress 6.2 or newer** - **PHP 8.1 or newer** Include both version numbers when reporting a technical problem. ## Describe What You Expected Explain what you were attempting to do. For example: "I approved a vendor application and expected the application to move to Awaiting Payment." This provides more useful context than simply saying: "Applications aren't working." ## Describe What Actually Happened Explain what occurred instead. Include: - What appeared on screen - Whether the page changed - Whether an email was generated - Whether a status changed - Whether an error appeared - Whether the action worked after refreshing Small details can help identify where the workflow failed. ## Provide Steps to Reproduce the Problem If possible, provide the exact steps that cause the issue. For example: 1. Open the event. 2. Open Applications. 3. Select a pending application. 4. Choose Approve. 5. The page displays an error. Clear reproduction steps make troubleshooting significantly easier. ## Identify the User Role If the problem involves access or permissions, include the affected WordPress role. For example: - Administrator/Organizer - Vendor Relations Manager - Event Staff - Vendor A feature that works for an Administrator but fails for a Vendor Relations Manager may indicate a permissions issue rather than a problem with the feature itself. ## Explain the Scope Indicate whether the problem affects: - One vendor - Multiple vendors - One event - Multiple events - One staff account - Every user - One browser or device - Every browser or device tested This helps narrow down the cause. ## Include System Readiness Results Check: **VendorHearth → System Readiness** Include any warnings or failed checks that appear relevant to the problem. System Readiness information can quickly identify problems involving portal pages, roles, uploads, scheduled tasks, payments, or configuration. ## Include Error Messages If WordPress displays an error, copy the exact message whenever possible. Do not summarize: "WordPress gave me an error." Instead, provide the actual error text. Screenshots are also useful when the error is visual. ## Screenshots Can Help Screenshots are particularly useful for: - Incorrect layouts - Missing buttons - Permission problems - Unexpected statuses - Mobile display problems - System Readiness warnings - WordPress errors Try to capture enough of the screen to show where the problem occurs. ## Remove Sensitive Information Before sending screenshots, check them for private information. Do not expose: - VendorHearth license keys - Square Access Tokens - Square Webhook Signature Keys - WordPress passwords - Hosting passwords - Database passwords - SMTP passwords - Private API credentials If sensitive information appears in a screenshot, remove or cover it before sharing. ## Payment Problems For Square-related issues, include: - Sandbox or Production - Payment status shown in VendorHearth - Payment status shown in Square - Whether one or multiple payments are affected - Whether `payment.updated` is configured - Whether the problem began after a domain or hosting change Do not send your Square Access Token or Webhook Signature Key. ## Email Problems For email issues, include: - Type of email - Whether a test email works - Whether manual VendorHearth emails work - Whether the communication appears in VendorHearth history - Whether the problem affects one or all vendors - Whether an SMTP or transactional mail service is being used Do not send email-account or SMTP passwords. ## Automation Problems For scheduled-task problems, include: - Feature that is not running - Expected schedule - WordPress timezone - Whether WordPress cron is functioning - Whether other automated VendorHearth features are working This can help determine whether the problem is specific to VendorHearth or the site's scheduled-task system. ## Problems After an Update If the problem started after an update, include: - Previous VendorHearth version if known - Current VendorHearth version - Whether WordPress was updated - Whether PHP changed - Whether other plugins were updated - Whether the theme was updated Do not assume VendorHearth caused the problem simply because several components were updated at the same time. ## Problems After a Migration If the problem began after moving the website, include whether you changed: - Domain - Hosting provider - WordPress installation - PHP version - Email configuration - Square webhook URL - WordPress timezone Also confirm whether the WordPress uploads directory and database were migrated. ## Plugin or Theme Conflicts If you suspect another WordPress plugin or theme is interfering with VendorHearth, identify the suspected software and its version. Do not disable critical plugins on a live production website without understanding the consequences. Whenever possible, perform conflict testing on a staging or development copy of the website. ## Back Up Before Advanced Troubleshooting Create a current backup before making significant changes to: - WordPress - VendorHearth - Plugins - Themes - Database - Server configuration A backup provides a recovery point if troubleshooting creates an unexpected problem. ## VendorHearth Support Checklist Before submitting a support request, gather: - VendorHearth Pro version - WordPress version - PHP version - Description of the problem - Expected behavior - Actual behavior - Steps to reproduce - User role affected - Event or workflow affected - Scope of the problem - System Readiness warnings - Exact error messages - Relevant screenshots - Recent website changes Providing this information with your initial request can significantly reduce the amount of back-and-forth needed to diagnose the issue. ## Protect Your Production Website Never provide unrestricted Administrator, hosting, database, or payment-processor credentials through an insecure or public support channel. If additional access is ever necessary for troubleshooting, follow the secure instructions provided through the appropriate VendorHearth support process. ## You're Ready to Use VendorHearth You have reached the end of the core VendorHearth Pro documentation. The knowledge base is designed to help you configure VendorHearth, manage your vendor program, operate your events, and troubleshoot common technical issues. As VendorHearth continues to evolve, additional documentation may be added for new features and major software updates.