Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Settings action link is missing from the Plugins screen

Cerrado
  • ¿Algo no está bien?
#571 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@Alexia-Soare ya está trabajando en esto.

Desde el 28/9/2026.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php, wordpress
Área
backend, testing-qa

Línea de trabajo

Start in includes/classes/wp-maintenance-mode-admin.php, tracing __construct(), load_default_settings(), and add_settings_link(); check the bootstrap in wp-maintenance-mode.php and compare v2.6.15 with v2.6.16. Run the relevant admin tests, including single-site and network-admin contexts; done means the Settings action appears on both Plugins screens and coverage verifies registration timing.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug-report bug-report-triage regression

Summary

The LightStart row on the WordPress Plugins screen does not expose its expected Settings action in the inspected release path. The plugin is expected to provide a direct configuration link alongside its plugin-row actions, but version 2.6.23 registers that action ineffectively. This makes the settings page harder to discover, although administrators can still access it from the separate LightStart sidebar menu.

Customer context

  • Product / area: LightStart / Plugins screen action links
  • Version: 2.6.23
  • Environment: WordPress administration; role, WordPress version, PHP version, and multisite status not provided
  • Integration / third party: Not provided
  • Reported error / symptom: No settings button was available for configuration
  • Impact: The reporter could not find a direct route to configure the plugin and deactivated it after nine minutes.

Reproduction notes

  1. Install and activate LightStart 2.6.23.
  2. Open the WordPress Plugins screen as an administrator.
  3. Inspect the action links under the LightStart plugin row.
  4. Expected: a Settings action opens the LightStart configuration page.
  5. Source-confirmed result: registration uses the plugin basename before that property is initialized, so the plugin-specific callback is not attached. Runtime reproduction was not performed during triage.

Diagnosis

Conclusion

The plugin-row Settings action is registered before the dynamic hook's plugin basename has been initialized. At construction time, the resulting filter name lacks the basename used by the Plugins screen, while no later registration occurs after initialization. Git history shows that initialization moved from the constructor to init in commit c4b35add6226e0bb36c7e96eea6bdac3c0fbc7ca; the commit first appears in v2.6.16, while v2.6.15 retains constructor-time initialization. The defect remains in the reported v2.6.23 source.

Where this likely occurs
  • wp-maintenance-mode.php — plugin bootstrap approx. lines 68–74 registers WP_Maintenance_Mode_Admin::get_instance() on plugins_loaded for admin requests.
  • includes/classes/wp-maintenance-mode-admin.php — WP_Maintenance_Mode_Admin::__construct() lines 25–46 defers property initialization to init but immediately constructs the plugin_action_links_{$plugin_basename} or network equivalent filter name.
  • includes/classes/wp-maintenance-mode-admin.php — WP_Maintenance_Mode_Admin::load_default_settings() lines 100–107 assigns plugin_basename only when init later runs.
  • includes/classes/wp-maintenance-mode-admin.php — WP_Maintenance_Mode_Admin::add_settings_link() lines 1085–1099 defines the expected Settings link callback, but the inspected registration path does not attach it to the plugin-specific hook.
  • Commit c4b35add6226e0bb36c7e96eea6bdac3c0fbc7ca moved basename initialization out of the constructor. Tags containing the change begin at v2.6.16; v2.6.23 still contains it.
Engineering notes

The same ordering affects both the ordinary and network-admin plugin-row filter selection because the network-activation condition also receives the not-yet-initialized basename. The callback itself builds its URL after init, so the inspected failure is in registration timing rather than URL generation. The separate top-level LightStart admin menu is registered later and is outside this defect's scope.

Test coverage status

No relevant coverage was found during inspection for plugin-row action-link registration on either single-site or network-admin Plugins screens. Existing tests/e2e specs navigate directly to the settings URL and do not assert the plugin-row action. tests/helpers-test.php covers settings capabilities but not dynamic plugin action hooks.

What to verify or explore next
  • Reproduce on v2.6.23 by activating LightStart and inspecting its row on the single-site Plugins screen.
  • Repeat with network activation and inspect the Network Admin Plugins screen.
  • Compare the registered dynamic action-link hooks on v2.6.15 and v2.6.16.
  • Exercise the relevant admin test suites under administrator and network-administrator contexts.
Unknowns / follow-up
  • The feedback does not identify whether the site was single-site or multisite.
  • Local browser-based reproduction was not performed; confirmation is based on the reachable initialization and hook-registration sequence in tagged source.
  • No matching open GitHub issue was found after reading the repository's open issue inventory.

Confidence

Confidence: 96/100

Version 2.6.23 source confirms that the plugin-row action link is attached using an uninitialized dynamic hook name, and git history identifies a v2.6.16 regression boundary. The sidebar report is not confirmed because the inspected code registers a top-level LightStart menu for users with the required capability, while the feedback omits role and runtime details.

Source: automated uninstall feedback — wp-maintenance-mode, 2026-09-26
Generated by bug-report-triage (ID: bug-report-triage_6ab8a3106d6f99.06487082)

Lenguaje dominante
PHP
Estrellas
163
Forks
82
Merge medio
5 d 21 h
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Codeinwp/wp-maintenance-mode

Todos los issues de Codeinwp/wp-maintenance-mode

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.