FIX: set default units for range field

[ObitoTM]

https://github.com/Crocoblock/issues-tracker/issues/20281

[github-actions]

🤖 AI PR Review

Risk level: low

Review

Summary

• This PR sets a default 'unit' => 'px' for two range control defaults in includes/blocks/types/range-field.php (inside jsm_controls()). This prevents controls from ending up without a unit and avoids potential undefined-index notices or inconsistent rendering in the editor/front-end.

What I reviewed

• File: includes/blocks/types/range-field.php
• Function: jsm_controls() — two attribute default arrays were extended with 'unit' => 'px' (around the defaults for values 5 and 18).

Positive

• This is a small, focused fix that addresses the reported issue (missing default units for range field controls).
• Low risk change and improves robustness of block defaults (fewer JS/PHP notices and more predictable behaviour in the editor).

Potential issues / suggestions

1. Backward compatibility / saved forms

   • Adding a default unit for the block definition is safe for new forms, but older saved block attributes in post_content may still lack the 'unit' key. Ensure all code paths that read these attributes tolerate the absence of 'unit' (use fallback to 'px' when reading). Example defensive pattern where attributes are used:
     $unit = isset( $attr['unit'] ) ? $attr['unit'] : 'px';
   • If there are render-time or save-time routines that assume a numeric-only value (no unit), double-check they handle the unit properly to avoid changing previously saved values' appearance.

2. Sanitization / validation

   • Although this is a default value for block controls, the plugin should validate/sanitize unit values when saving/using them (i.e. only allow a whitelist like ['px','em','%','rem'] etc.). Ensure wherever units are read from attributes or form submissions they are validated against an allowed list.

3. Coverage: searches/consistency

   • Search the repo for other range control defaults that only provide a numeric default (value only). If there are other similar controls, consider adding a consistent default unit or ensure consistent fallbacks.
   • Also search for places that access $attribute['unit'] without checks — adding defaults reduces occurrences but defensive checks are still recommended.

4. Tests / manual verification

   • There are no unit tests added. For a low-risk change this may be acceptable, but please add or at least run manual checks for:
     • Existing saved forms (pre-PR) rendering unchanged.
     • New forms/blocks in Gutenberg: editor UI shows the correct unit UI and value.
     • Front-end submission/rendering where the range value is used — verify no change in output.

5. Coding standards

   • The added lines follow WPCS style and use single quotes; no changes needed.

Conclusion / recommended next steps

• This PR is fine to merge as-is from a safety/performance point of view, provided you ensure the code that consumes these attributes uses a safe fallback for older saved blocks and that unit values are validated when used. Consider searching for other range defaults and adding consistent default unit handling where applicable. Add a short unit test or document a manual QA checklist (editor, saved forms, front-end) if you maintain release QA procedures.

Suggested changelog entry

- FIX: set default units for range field controls to px to avoid missing unit issues