Summary
LightStart template import can remain indefinitely in its loading state when the import request fails. The expected behavior is for a template either to import successfully or for the interface to report the failure and allow another attempt. Instead, the affected workflow continues showing an importing spinner with its import controls disabled, preventing users from completing template setup without leaving or reloading the page.
Customer context
- Product / area: LightStart template library and onboarding wizard
- Version: 2.6.22
- Environment: Thirteen independent WordPress sites reported the symptom during July 14–20, 2026; hosting, WordPress, PHP, and browser versions were not provided
- Integration / third party: The onboarding flow can install Otter Blocks, Optimole, and Super Page Cache; no single integration was identified in the submissions
- Reported error / symptom: Template import or preview keeps loading, does not import, or reports that the preview could not be loaded
- Impact: Affected users cannot complete template setup; most reports were submitted shortly after activation
Reproduction notes
Reported workflow:
- Open LightStart’s onboarding or template library on version 2.6.22.
- Select a design and start template import.
- Observe that import keeps spinning, does not complete, or the preview cannot load.
Repository-confirmed failure condition: if the insertion request returns the endpoint’s explicit error, fails at transport level, or cannot be parsed as JSON, the UI has no complete recovery path and can remain disabled/loading. No controlled runtime reproduction was performed. Missing evidence includes the affected sites’ network responses, console logs, WordPress/PHP versions, and whether each submission came from onboarding or settings.
Diagnosis
Conclusion
The tagged 2.6.22 source confirms a client-side failure-state defect consistent with the reports. Both import surfaces enter disabled/loading states before the request. The template insertion request is not returned to the surrounding promise chain, has no transport-failure callback, and its structured error branch does not restore the disabled controls. The server contains a reachable insertion-error response. Therefore, when one of these failure branches is reached, the current page remains blocked. The reports establish recurrence across 13 sites, although their individual underlying request failures were not captured.
Where this likely occurs
- Template settings UI:
assets/js/scripts-admin.js — fireImport() lines 255–283 disables every import button and marks the selected template as importing before calling the shared workflow.
- Onboarding UI:
assets/js/scripts-admin.js — importInProgress() lines 495–505 adds the loading indicator and disables import, skip, and template-selection controls.
- Shared import workflow:
assets/js/scripts-admin.js — importTemplate() lines 527–545 has cleanup in its rejection handler, but addToPage() lines 569–597 does not return the template-insertion jqXHR and only handles successful HTTP callbacks; its response.success === false branch does not restore the loading state.
- Server insertion endpoint:
includes/classes/wp-maintenance-mode-admin.php — WP_Maintenance_Mode_Admin::insert_template() lines 708–759 reads the bundled template, inserts or updates a page, and emits an explicit JSON error at lines 745–747 when insertion fails.
- Release context: commit
87727a0 in 2.6.22 added a default-selected Super Page Cache installation step before Otter in the onboarding promise chain. assets/js/scripts-admin.js — handlePlugins() lines 602–641 catches plugin installation or activation rejection and resolves the chain, so insertion can continue after an onboarding dependency failure. This is a plausible additional trigger for wizard reports, not a proven trigger for all 13 submissions.
Engineering notes
Template content is bundled locally, so the inspected insertion path does not depend on a remote template-catalog API. The workflow does depend on WordPress AJAX page insertion and, in onboarding, optional plugin installation and activation. assets/js/scripts-admin.js — installPlugin() lines 682–692 also treats a structured unsuccessful installation response as a fulfilled request, while handlePlugins() absorbs rejected installation/activation requests. The inspected evidence confirms the stuck state once an insertion request fails; it does not identify why each customer request failed or establish that all submissions share the 2.6.22 Super Page Cache trigger. No customer sites or customer-hosted links were accessed.
Test coverage status
The only discovered PHP suite is tests/generic-test.php; Test_Generic lines 9–39 covers constants, helper behavior, class loading, and banners. No relevant coverage was found during inspection for insert_template(), importTemplate(), addToPage(), plugin-installation failures, or restoration of wizard/settings loading states. No JavaScript or browser test suite covering template import was found.
What to verify or explore next
- Reproduction with 2.6.22 while forcing
wpmm_insert_template to return its existing JSON error response.
- Reproduction with 2.6.22 while forcing the
admin-ajax.php insertion request to fail at transport level or return invalid JSON.
- Separate checks through the settings template library and the fresh-install onboarding wizard.
- Onboarding checks with Super Page Cache installation or activation rejected before the Otter step.
- Browser assertions covering spinner removal and control availability after each failure type.
Unknowns / follow-up
- The WordPress, PHP, hosting, browser, and console/network details for the reporting sites are unavailable.
- It is unknown which reports used onboarding versus the settings template library.
- The precise server response behind each customer report is unavailable.
- The inspected repository contains plugin source but not WordPress core source, so environment-specific AJAX and installation behavior was not independently verified from core.
Confidence
Confidence: 92/100
Thirteen independent 2.6.22 reports describe the same import/preview loading symptom, and inspection of the tagged release confirms reachable request-failure branches that leave the import controls blocked with no recovery path.
Generated by bug-report-triage (ID: bug-report-triage_6a5f6176ee16a1.61074256)
Summary
LightStart template import can remain indefinitely in its loading state when the import request fails. The expected behavior is for a template either to import successfully or for the interface to report the failure and allow another attempt. Instead, the affected workflow continues showing an importing spinner with its import controls disabled, preventing users from completing template setup without leaving or reloading the page.
Customer context
Reproduction notes
Reported workflow:
Repository-confirmed failure condition: if the insertion request returns the endpoint’s explicit error, fails at transport level, or cannot be parsed as JSON, the UI has no complete recovery path and can remain disabled/loading. No controlled runtime reproduction was performed. Missing evidence includes the affected sites’ network responses, console logs, WordPress/PHP versions, and whether each submission came from onboarding or settings.
Diagnosis
Conclusion
The tagged 2.6.22 source confirms a client-side failure-state defect consistent with the reports. Both import surfaces enter disabled/loading states before the request. The template insertion request is not returned to the surrounding promise chain, has no transport-failure callback, and its structured error branch does not restore the disabled controls. The server contains a reachable insertion-error response. Therefore, when one of these failure branches is reached, the current page remains blocked. The reports establish recurrence across 13 sites, although their individual underlying request failures were not captured.
Where this likely occurs
assets/js/scripts-admin.js—fireImport()lines 255–283 disables every import button and marks the selected template as importing before calling the shared workflow.assets/js/scripts-admin.js—importInProgress()lines 495–505 adds the loading indicator and disables import, skip, and template-selection controls.assets/js/scripts-admin.js—importTemplate()lines 527–545 has cleanup in its rejection handler, butaddToPage()lines 569–597 does not return the template-insertion jqXHR and only handles successful HTTP callbacks; itsresponse.success === falsebranch does not restore the loading state.includes/classes/wp-maintenance-mode-admin.php—WP_Maintenance_Mode_Admin::insert_template()lines 708–759 reads the bundled template, inserts or updates a page, and emits an explicit JSON error at lines 745–747 when insertion fails.87727a0in 2.6.22 added a default-selected Super Page Cache installation step before Otter in the onboarding promise chain.assets/js/scripts-admin.js—handlePlugins()lines 602–641 catches plugin installation or activation rejection and resolves the chain, so insertion can continue after an onboarding dependency failure. This is a plausible additional trigger for wizard reports, not a proven trigger for all 13 submissions.Engineering notes
Template content is bundled locally, so the inspected insertion path does not depend on a remote template-catalog API. The workflow does depend on WordPress AJAX page insertion and, in onboarding, optional plugin installation and activation.
assets/js/scripts-admin.js—installPlugin()lines 682–692 also treats a structured unsuccessful installation response as a fulfilled request, whilehandlePlugins()absorbs rejected installation/activation requests. The inspected evidence confirms the stuck state once an insertion request fails; it does not identify why each customer request failed or establish that all submissions share the 2.6.22 Super Page Cache trigger. No customer sites or customer-hosted links were accessed.Test coverage status
The only discovered PHP suite is
tests/generic-test.php;Test_Genericlines 9–39 covers constants, helper behavior, class loading, and banners. No relevant coverage was found during inspection forinsert_template(),importTemplate(),addToPage(), plugin-installation failures, or restoration of wizard/settings loading states. No JavaScript or browser test suite covering template import was found.What to verify or explore next
wpmm_insert_templateto return its existing JSON error response.admin-ajax.phpinsertion request to fail at transport level or return invalid JSON.Unknowns / follow-up
Confidence
Confidence: 92/100
Thirteen independent 2.6.22 reports describe the same import/preview loading symptom, and inspection of the tagged release confirms reachable request-failure branches that leave the import controls blocked with no recovery path.
Generated by bug-report-triage (ID: bug-report-triage_6a5f6176ee16a1.61074256)