Feature: Added InnerBlock Support for Download Button & Add Support for download attribute

[Mayank-Tripathi32]

attempt solution for #57314, #57871

What?

Converting the File block's download button from a RichText component to an InnerBlocks implementation utilizing the core Button block.

Why?

The current RichText implementation limits styling options and creates inconsistency with WordPress's block ecosystem. Users cannot access standard button customization features, and developers face challenges maintaining consistent theme styling. This change improves the user experience while reducing technical complexity.
The migration to InnerBlocks addresses longstanding issues with button customization and brings the File block in line with WordPress's modern block architecture. It enables seamless theme integration and provides users with familiar button controls they expect from the block editor.

How?

The implementation replaces the existing RichText-based button with an InnerBlocks area that specifically allows the core Button block. Key implementation details include:

• Configuring InnerBlocks with a predefined button template
• Implementing template locking to maintain download functionality
• Preserving existing accessibility features and ARIA attributes
• Ensuring proper inheritance of theme styles through theme.json
• Maintaining backward compatibility with existing File block implementations

Testing Instructions

1. Create a new post or page and add a File block
2. Upload a file and enable the download button
3. Verify that the button appears and maintains download functionality
4. Test button customization options in the sidebar
5. Confirm that theme styles are properly applied to the button
6. Check that the download attribute and link remain functional on the frontend
7. Verify that existing File blocks continue to work after updating
8. Test the block in different themes to ensure consistent styling
9. Confirm that template locking prevents button removal
10. Validate that accessibility features remain intact

Issues (Identified)

• Download attribute is missing in "core/button", related to "Download" attribute for links in button, image or paragraph blocks #57871, This requires further discussion to determine whether the attribute should be implemented directly in the "core/button" block or if an alternative solution, such as adding the attribute through custom logic would be more appropriate.
• Solution: For now I have tried adding the attribute support for download button with logic to detect origin. I have addressed the problem pointed out in the issue.

Screencast

Tes.file.innerblock.mp4

Test.button.implementation.mp4

[Mayank-Tripathi32]

download attribute is missing, should we have it added to button component or should we go with a work around here?

[Mayank-Tripathi32]

I went ahead with implementing the download attribute on button block for now, I think there is a need for discussion if alternative exists but I feel implementing download attribute is better way to handle this.

[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.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• 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: Mayank-Tripathi32 <[email protected]>
Co-authored-by: fabiankaegy <[email protected]>

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

[Mayank-Tripathi32]

@creativecoder @Mamaduka @mikachan Hello! If you could spare some time to review the PR or share your inputs, it would be greatly appreciated. Thank you!

[fabiankaegy]

In almost all cases, you want to use useInnerBlocksProps rather than <InnerBlocks /> these days because that allows you to match the markup between the editor and the frontend (you don't get additional div elements injected in the editor)

[Mayank-Tripathi32]

I see, thanks for pointing that out. I'll look into updating it to use useInnerBlocksProps!

[Mayank-Tripathi32]

I have updated the code to reflect the changes with useInnerBlocksProps. Thanks