Feature : Toggle to prevent inline JS

[Vrishabhsk]

What?

• Closes Categories block - attribute to prevent inline javascript #73899

• This PR introduces a new disableInlineScript attribute to the Categories block that allows developers to prevent the injection of inline JavaScript when using the block in dropdown mode. This provides better control over the block's output, especially when using block variations or custom navigation implementations.

Why?

With the growing use of block variations and custom block implementations, developers often need to use the Categories block as a primitive building block. Currently, when displaying terms as a dropdown, the block automatically injects an inline script tag that handles client-side navigation. This can be problematic when:

• Developers want to implement custom navigation behavior (e.g., AJAX loading, custom routing)
• The inline script conflicts with existing JavaScript implementations
• Developers need cleaner HTML output without inline scripts

The current workaround of manually removing the inline script is cumbersome and unreliable. This PR provides a clean, supported way to disable the inline script injection.

How?

The implementation adds a new optional attribute disableInlineScript (boolean, defaults to false) to maintain backward compatibility:

1. Block Definition (block.json): Added the new disableInlineScript attribute with default value false
2. Editor UI (edit.js): Added a toggle control in the block inspector that appears when "Display as dropdown" is enabled, allowing users to disable inline scripts
3. Server-side Rendering (index.php): Modified the render function to check the disableInlineScript attribute before injecting the inline JavaScript. When the attribute is true, the script tag is omitted from the output

The changes are backward compatible - existing blocks will continue to work as before since the default value is false.

Testing Instructions

Basic Testing

1. Create a new post or page
2. Insert a Categories block
3. In the block settings panel, enable "Display as dropdown"
4. Observe that a new toggle "Disable inline script" appears
5. Enable the "Disable inline script" toggle
6. Save the post and view it on the frontend
7. Check the page source (Ctrl+U / Cmd+Option+U)
8. Search for inline JavaScript after the dropdown select element
9. Expected: No <script> tag should be present after the </select> tag

Control Test (Default Behavior)

1. Go back to the editor
2. Disable the "Disable inline script" toggle (or add a new Categories block without changing this setting)
3. Save and view the frontend source again
4. Expected: The inline JavaScript <script> tag should be present after the <select> element, enabling client-side navigation

Block Variation Testing (Developer Scenario)

1. Create a custom block variation in your theme's JavaScript:

   wp.blocks.registerBlockVariation( 'core/categories', {
   	name: 'custom-categories',
   	title: 'Custom Categories',
   	attributes: {
   		displayAsDropdown: true,
   		disableInlineScript: true,
   	},
   } );

2. Insert the custom variation in a post
3. Save and view frontend
4. Expected: The dropdown renders without inline JavaScript, allowing your custom navigation script to handle the interaction

Additional Notes

• Backward Compatibility: The default value false ensures existing blocks continue to work as before
• Use Case: Particularly useful for developers creating block variations with custom navigation implementations
• Scope: This setting only affects the frontend output when displayAsDropdown is enabled
• Accessibility: The new toggle in the editor is properly labeled and keyboard accessible

[github-actions]

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.

[github-actions]

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: mediaformat <mediaformat@git.wordpress.org>

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