Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce proper user-facing names for check categories #373

Closed
felixarntz opened this issue Jan 4, 2024 · 0 comments · Fixed by #375
Closed

Introduce proper user-facing names for check categories #373

felixarntz opened this issue Jan 4, 2024 · 0 comments · Fixed by #375
Labels
Infrastructure Issues for the overall plugin infrastructure [Type] Bug An existing feature is broken

Comments

@felixarntz
Copy link
Member

The available check categories are currently only defined as a slug, via class constants on Check_Categories. While those slugs are the key to the functionality, the categories are also displayed to end users. Right now this is accomplished via ucfirst( str_replace( '_', ' ', $category ) ), which really isn't right. We need to use a proper i18n string for each category.

In other words, each available category should also have a label. Here's what I'd suggest:

  • Introduce a new method Check_Categories::get_category_labels().
  • The method should return an associative array of the category slugs and their respective labels.
  • The slugs should be the ones from the class constants, and the labels should be new i18n friendly strings.
  • The Admin_Page class should then call the new method to have both the category slugs and labels, and the admin-page.php template should be adjusted accordingly.
  • In case the PR Add Categories and Checks CLI commands #339 has already been merged, there's another reference to the categories in there that would need to be updated in the same way as well.

Another related observation is that the Check_Categories::get_categories() method is unnecessarily complex, using ReflectionClass to dynamically get the class constants. I think that's a bit "too smart" and more importantly inefficient, so I think it would be better to simply return a "hard-coded" array including the class constants in there. I think it would be worth making that change here too, while we're enhancing that class anyway.

cc @mukeshpanchal27 @swissspidy @ernilambar

@felixarntz felixarntz added [Type] Bug An existing feature is broken Infrastructure Issues for the overall plugin infrastructure labels Jan 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Infrastructure Issues for the overall plugin infrastructure [Type] Bug An existing feature is broken
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant