Help4 I.G.O.R. Feedback and Diagnostic Reports
Before changing settings
Confirm the site, user state, current version, and recovery path.
Open the exact site and feature named in the request, record its current behavior, and keep a bounded recovery option. Change one setting group at a time so the verification can identify what actually changed.
Target
Record the domain, URL or admin screen, user role, viewport, and specific outcome before changing configuration.
Current state
Capture the relevant version, enabled module, existing value, and a fresh public or runtime check.
Recovery
Keep the previous immutable package, WordPress revision, export, or narrow data snapshot needed for this feature.
Privacy
Keep credentials, private customer data, payment secrets, nonces, and protected files out of screenshots and support reports.
Visual orientation
Match the screen before following the steps.
Open each image at full size. The numbered notes explain what the screen controls and what to confirm before changing customer content.
Screen 1
Page Settings and recovery
Confirm page-level layout, history, preview, and recovery controls before a larger edit.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 2
Settings and launch center
Choose a launch plan, confirm modules, download Help4 Blank, review readiness, and keep the site configuration in one place.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 3
Current Studio workspace
See the element library, device controls, live page frame, inspector, performance guidance, and save state together.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 4
Builder Studio
Use the live page frame, element library, template library, inspector, responsive controls, performance guidance, and save state in one workspace.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Watch the real workflow
Watch the clicks before making the change.
Use the narrated walkthrough first, then follow the written steps and verification checks on this page.
Lesson 24
Insights, Logs, and I.G.O.R. Diagnostics
Turn a vague Builder problem into a privacy-safe report with one reproducible action, fresh evidence, and a clear expected result.
Read the complete transcript
- Stop and Define the Failure
When an edit starts removing content, losing styles, or returning an error, stop repeated changes. Record one affected URL or admin screen, page or template ID, selected element, user role, viewport, exact action, expected result, actual result, and the time of the attempt.
- Gather Fresh Evidence
Use Insights and fresh browser or PHP logs from the same reproduction. Capture the response status, one relevant console message, active versions, enabled modules, theme, and a screenshot showing the complete control and result. Old errors from another request can send diagnosis in the wrong direction.
- Protect Private Information
Review what I.G.O.R. will send before submission. Remove passwords, nonces, license keys, payment secrets, application passwords, private messages, database content, raw customer records, and tracking details. Include only the smallest environment and reproduction evidence needed to understand the issue.
- Submit One Connected Report
Send one complete report, keep follow-up evidence on the same support record, and use History or the known recovery path when appropriate. After a fix, repeat the original action and verify Studio, public output, desktop, mobile, and fresh logs before closing the issue.
Useful reports
Describe the smallest action that changes a working state into a failing state.
A support report is strongest when it contains one affected route, one user state, one viewport, one failing action, and fresh evidence from the same attempt.
Exact target
Include the public or admin URL, page or template ID, and feature name.
Reproduction
List the smallest ordered steps and whether the failure happens every time.
Safe evidence
Include versions, viewport, status, console or PHP message, and screenshot while removing secrets and customer data.
Expected outcome
State what should have remained visible, saved, interactive, or unchanged after the action.
Guided walkthrough
Make one verified change at a time.
Each step includes the action, why it belongs in this order, and the checkpoint to verify before moving forward.
-
Stop repeated edits
When the page begins losing content or style, stop and preserve the current state instead of trying more controls.
Why nowStarting from a confirmed target prevents a correct edit from being applied to the wrong page, template, product, or responsive view.
Done whenThe stop repeated edits result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Record the target
Copy the URL, page or template ID, selected element, user role, viewport, and current Builder version.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe record the target result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Reproduce once
Start from a known state and perform only the smallest action that causes the failure.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe reproduce once result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Capture fresh evidence
Save the exact error text, response status, console line, PHP log timestamp, and a screenshot showing the selected control and result.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe capture fresh evidence result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Remove sensitive data
Redact passwords, nonces, license keys, payment details, private messages, customer records, and server credentials.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe remove sensitive data result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Submit through I.G.O.R.
Enable feedback, confirm the destination, review the payload, and send one complete report instead of several partial reports.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe submit through i.g.o.r. result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Keep the ticket connected
Reply on the same support record with new evidence and confirm the public result before considering the issue complete.
Why nowThe final verification separates an editor preview from a result that is actually saved, responsive, interactive, and ready for visitors.
Done whenThe keep the ticket connected result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
Release check
Test the real public or member outcome, not only the settings screen.
Reopen the saved setting, run the intended workflow in the correct visitor state, test desktop and phone behavior where a frontend surface exists, and inspect fresh browser or PHP errors from the same attempt.
Persistence
The saved values remain correct after reload and do not overwrite newer settings from another session.
Public behavior
The intended visitor can complete the workflow and an unintended visitor cannot access protected output.
Responsive behavior
Controls, text, tables, media, dialogs, and focus stay visible and usable at 768px, 390px, and 360px.
Fresh evidence
The final request has the expected status, output, cache state, and no new related console or PHP error.
Common questions
Answers for the decisions that block this setup most often.
What does I.G.O.R. stand for?
I.G.O.R. stands for Integrated Graphical Organized Response, the Help4 issue-reporting path for reproducible diagnostics.
Should passwords or private keys be included?
No. Never include credentials, nonces, payment secrets, license keys, or private customer data in a feedback report.
What makes a screenshot useful?
Show the full relevant control, selected element, page context, and visible result while keeping private data out of the image.
Continue learning
Use the next guide that matches the work in front of you.
The full tutorial hub remains available without repeating dozens of unrelated cards on this page.
Start here
Install and setup
Download the ZIP, activate Builder Suite, understand the blank-theme path, and run the first clean check.
First page
Build a page safely
Open Builder Pages, launch Studio, build structure first, check mobile, then publish or hand it to Help4.
Editor controls
Know which tab changes what
Use Content for information, Design for appearance and responsive values, and Advanced for identity, attributes, visibility, and motion.
Recovery
Edit without losing work
Replace media safely, recognize stale drafts, and restore a known-good page snapshot from Page Settings History.
Responsive
Control every viewport
Set spacing, widths, columns, alignment, and typography independently for desktop, tablet, and mobile.
Templates
Choose a starter
Pick a starter spec by page job: service, product, support, recent work, local SEO, launch, or checkout recovery.
Need a second set of eyes?
Send one complete, privacy-safe support record.
Include the affected URL or admin screen, current Builder version, user state, exact steps, expected result, actual result, and one screenshot or fresh error when available.