Feature : allow controls with `DataForm` to be set as `disabled` by Vrishabhsk · Pull Request #74262 · WordPress/gutenberg

Vrishabhsk · 2025-12-29T12:28:53Z

What?

Closes

Closes : DataForm: allow controls to be set as disabled #73673
PR allows adding disabled attribute within fields Edit config used by DataForm component

Why?

Ability to show controls in a disabled manner is not possible currently in DataForm component
This PR adds the ability to disable the controls by passing disabled attribute as true within respective Edit config

How?

Modified the types and controls to accept the disabled attribute in Edit config

Testing Instructions

Run npm run storybook:dev
Visit http://localhost:50240/?path=/story/dataviews-dataform--disabled-fields
Test out the disabled controls if they are working as expected.
Create your own variations for test cases and verify functionality

Testing Instructions for Keyboard

NA

Screenshots or screencast

NA

github-actions · 2025-12-29T12:29:02Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Vrishabhsk <vrishabhsk@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

github-actions · 2025-12-29T12:29:03Z

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

Required label: Any label starting with [Type].
Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

oandregal · 2026-01-02T11:50:05Z

packages/block-editor/src/hooks/utils.js

 import { getValueFromObjectPath, setImmutably } from '../utils/object';
 import { store as blockEditorStore } from '../store';
 import { unlock } from '../lock-unlock';
-/**


Is this change necessary? Perhaps this PR needs a rebase from trunk?

oandregal · 2026-01-02T11:50:15Z

packages/react-native-editor/sass-transformer.js

 const fs = require( 'fs' );
 const path = require( 'path' );

-// eslint-disable-next-line import/no-extraneous-dependencies


Is this change necessary?

oandregal · 2026-01-02T12:03:20Z

packages/dataviews/src/dataform/stories/disabled.tsx

@@ -0,0 +1,280 @@
+/**


Thanks for thinking of creating a story.

I'm thinking that it'll be best for maintainability to add a "disabled" control to the existing "Layout Regular" story. That way, every new control that is added (that should be present in the LayoutRegular story) will have to demonstrate its disabled state.

Hi @oandregal I have added a control for disabled and removed the disabled layout entirely.

Preview

oandregal · 2026-01-02T12:10:39Z

Im still a bit confused about the points mentioned in Considerations for implementation in the issue description. If you can add more context and a brief explanation, it would help quite a bit. Thanks
#73673 (comment)

In your PR, make the text field in the Field Types story and then open the filters. This is what happens:

Screen.Recording.2026-01-02.at.13.05.13.mov

That's what we need to solve and what I've mentioned in the issue description as implementation considerations (note the links there). We reuse the Edit component in filters (see). However, in filters, the Edit component should never be disabled.

ntsekouras · 2026-01-05T14:14:37Z

packages/dataviews/src/components/dataform-controls/date.tsx

 									isPressed={ isSelected }
 									size="small"
+									disabled={ disabled }
+									accessibleWhenDisabled={ false }


I was very surprised by this value for accessibleWhenDisabled. I think this should always be set to true. I noticed that we have the same prop set to false (in trunk) too in a couple of places in DataViews package.

@jorgefilipecosta it seems all 3 occurrences are from you. Was that intentional for some reason?

Yah it was intentional, if the custom button is disabled I don't see any value in including in on the tab sequence/ screen readers tree, it seems better to not have accessible, it does not adds any value.
On the range control we also disable the reset button packages/components/src/range-control/index.tsx if it is disable we are not very consistent on using accessibleWhenDisabled=false, there are other cases where we could use it but given that we almost never use it I can also understand removing it in this case.

Hm.. For date control I think:

We use button in a non-interactive element which is already kind of wrong semantically for HTML. Additionally screen readers announce it as a button, but it doesn't do anything.

We should either use another element (span, div, etc..) styles as we want, although maybe we could remove it entirely, since not having selected a preset indicates we are in 'custom', no?

For this PR, maybe it's similar to the range-control example you shared.

Vrishabhsk · 2026-01-07T14:33:52Z

Hi @oandregal I have also implemented the feature for ignoring disabled config for fields when used in Filters. I have intentionally made the Text filter disabled but from the preview you can see its still accessible.

Preview

oandregal · 2026-01-07T17:36:12Z

packages/dataviews/src/components/dataviews-filters/input-widget.tsx

 	const field = useMemo( () => {
 		const currentField = fields.find( ( f ) => f.id === filter.field );
 		if ( currentField ) {
+			// For filters, we need to ensure the Edit control is never disabled.


This approach is not sustainable. It's replicating the logic available in getControl (see) and it also misses some things (EditConfig).

Can you think of alternatives?

We could explore any of the two I already shared under "Considerations for implementation" in the issue description.

Hi @oandregal I felt the first point to be more robust since it segregates the Edit for filter. I have implemented the same.

Changes

Added NormalizedField.filter so filters have a dedicated control that’s derived from Edit but cannot be disabled via EditConfig.disabled:
packages/dataviews/src/types/field-api.ts

Created field.filter during normalization (strip disabled from EditConfig before it becomes a closure-captured component):
packages/dataviews/src/field-types/index.tsx

Updated filters UI to use field.filter (instead of re-deriving a base control via getControlByType, which could drop other EditConfig options like prefix/suffix/rows):
packages/dataviews/src/components/dataviews-filters/input-widget.tsx

ntsekouras · 2026-01-22T08:25:46Z

packages/dataviews/src/field-types/index.tsx

 			type: fieldType.type,
 			render: field.render ?? fieldType.render,
 			Edit: getControl( field, fieldType.Edit ),
+			filter: getFilterControl( field, fieldType.Edit ),


Since #74733 filter prop is used similarly to sort and contains implementations of filtering logic for operators. Besides that, it doesn't feel semantically correct to me, to name it filter here.

Said that, I find the disabled prop very similar to the readOnly field and maybe a simpler approach would be to add disabled as a top-level field prop. That way we can update the controls by extracting the value from the field.disabled and for filters where we need to recreate the field we would set disabled: false, // Filters should never be disabled. here.

What do you think @oandregal ?

Vrishabhsk added 3 commits December 29, 2025 16:18

Update types

dad0c81

Update dataform controls

c083633

Update dataform storybook

0aad89e

Vrishabhsk requested review from gigitux, ntsekouras and oandregal as code owners December 29, 2025 12:28

github-actions bot added the [Package] DataViews /packages/dataviews label Dec 29, 2025

Merge branch 'trunk' into add/dataform-disabled-controls

6e410b2

Vrishabhsk requested a review from tellthemachines as a code owner December 29, 2025 13:49

github-actions bot added the [Package] Block editor /packages/block-editor label Dec 29, 2025

Vrishabhsk mentioned this pull request Dec 29, 2025

DataForm: allow controls to be set as disabled #73673

Open

oandregal added [Type] Feature New feature to highlight in changelogs. [Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond labels Jan 2, 2026

oandregal reviewed Jan 2, 2026

View reviewed changes

ntsekouras reviewed Jan 5, 2026

View reviewed changes

Vrishabhsk added 3 commits January 7, 2026 17:59

Add disabled control for direct manipulation

bb10b21

Prevent filters from ever being disabled

6fb11f1

Merge branch 'trunk' into add/dataform-disabled-controls

c2023a8

Fix duplicate import

f80dbf2

github-actions bot removed the [Package] Block editor /packages/block-editor label Jan 7, 2026

oandregal reviewed Jan 7, 2026

View reviewed changes

Implement sustainable logic

49772ce

ntsekouras reviewed Jan 22, 2026

View reviewed changes

Conversation

Vrishabhsk commented Dec 29, 2025

What?

Why?

How?

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

Uh oh!

github-actions bot commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Dec 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oandregal Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Preview

Uh oh!

oandregal commented Jan 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vrishabhsk commented Jan 7, 2026

Preview

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Changes

Uh oh!

ntsekouras Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Dec 29, 2025 •

edited

Loading

oandregal Jan 2, 2026 •

edited

Loading

ntsekouras Jan 22, 2026 •

edited

Loading