[Query-Total Block] Add editable text and visibility toggle for total count in Query Total block

[sarthaknagoshe2002]

Enhancements for: #67629

What?

This update enhances the Query Total block by introducing two key features:

1. Editable text fields for user-defined customization of displayed content.
2. A toggle option for hiding or showing the total count when using the rangeDisplay type.

Why?

• Editable Text provides flexibility for users to modify the default text to match their design or communication needs without overriding block logic.
• Visibility Toggle allows a cleaner design by giving control over whether the total count is displayed alongside the range.

How?

1. Editable Text:

   • Added support for rich text editing in the block output for both total-results and range-display types.

2. Toggle Option:

   • Introduced a new block attribute showTotal.
   • Integrated a toggle control in the block control for visibility management.
   • Adjusted the rangeDisplay rendering logic to include or omit the total count based on user selection.

Testing Instructions

1. Add a Query Total block to a post or page.
2. Select the block and verify that the displayed text is editable directly in the editor for both the variations.
3. Choose the range display option from the toolbar.
4. Toggle the visibility of the total count using the newly added control from the Block controls.
5. Verify that the visibility toggle affects the rendered output in both the editor and frontend.

Screenshots or screencast

query-total.enhancements.mov

[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: sarthaknagoshe2002 <[email protected]>
Co-authored-by: fabiankaegy <[email protected]>
Co-authored-by: swissspidy <[email protected]>

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

[sarthaknagoshe2002]

@gziolo Looking forward for you feedback here 😇

[fabiankaegy]

@swissspidy I'd love to get your thoughts here in terms of cross language feasibility.

My guess is that there are going to languages that will need to have it as a suffix where as others need the text as a suffix to the number.

And probably even some that will need both a suffix and a prefix 🤔
Do we have any other instances of this in core?

A freeform text field for labeling numbers?

[swissspidy]

My guess is that there are going to languages that will need to have it as a suffix whereas others need the text as a suffix to the number.

Suffix vs prefix is one aspect that needs to be considered, yes, but there is way more to this.

Right now I see a lot of string concatenation, which is bad and should not be used. Single pieces of text such as Displaying, of or result found are impossible to translate well in every language.

totalResultsText also completely fails to acknowledge the fact that singular and plural forms exist. In English and many more languages, "results found" does not work if there is only 1 result found. Some locales have only 1 form for everything. And some locales have multiple different plural forms depending on the actual count, so you would need multiple input fields to properly support this case.

Example in Russian:

Japanese:

Arabic:

Do we have any other instances of this in core? A freeform text field for labeling numbers?

Not to my knowledge, no. As you can see, it is more complex than what you might think.

[sarthaknagoshe2002]

We could implement three text boxes that users can rearrange to different positions, like text1 $range text2 $total text3. Each text segment can be moved independently, and we can also provide options to specify singular and plural forms for each text box.

[swissspidy]

That's a lot of text boxes :-)

Something where placeholders can be used inside a text box would be better, but that opens another can of worms, like UX requirements and the need to properly sanitize those strings.

I would suggest opening an issue first to outline the requirements and constraints.