[#43974] - [6.0] Numbers custom fields plugin
- Fixed in Code Base
- 16 Aug 2025
- Medium
- Build: 5.2-dev
- # 43974
- Diff
- TLWebdesign:5.2-dev
- Pending continuous-integration/drone/pr Build is pending Details
User tests: Successful: Unsuccessful:
I'm trying to create a new custom fields plugin for the standard Joomla Form Field Number. We have it for Integer and i'd like to have the same for the number field. That way w'll also gain ability to use floats.
Summary of Changes
Extra plugin added for the numbers standard form field type. With added currency options for display. Making it very useful for display of menu's for restaurants or anything else where a currency or a number is needed to be displayed.
Testing Instructions
You can discover the plugin and then use it in custom fields. It's called numbers.
Create a custom field of type numbers and check weather the options available do what they supposed to be doing. especially related to the number formatting.
Actual result BEFORE applying this Pull Request
No numbers custom field available.
Expected result AFTER applying this Pull Request
Numbers custom field available and working.
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings Front End Plugins |
| Labels |
Added:
Language Change
PR-5.2-dev
|
||
| Labels |
Added:
Feature
|
||
So the wall i'm hitting now is that i can't figure out how the display of the custom field in an "article edit view" is set or adjusted. Looking at for instance the integer custom field it sort of automagically seems to work. Because i can't seem to find a reference anywhere in the plugin folder itself.
Could someone point me in the right direction here?
I'm not there yet and i need help!
There is still some work to be done regarding the databases and the installation, see e.g.:
A nice example of another plugin can be found here:
https://github.com/joomla/joomla-cms/pull/42777/files
This pull request has been automatically rebased to 5.3-dev.
| Category | Administration Language & Strings Front End Plugins | ⇒ | Administration Language & Strings SQL Installation Postgresql Front End Plugins |
| Labels |
Added:
PR-5.3-dev
|
||
I have tested this item 🔴 unsuccessfully on 3d8f2bc
I have tested this item and it is not working as expected.
For more information - On discover number field plugin is available and installable. But after onstallation, in standard joomla form the number field is not available.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43974.
I have tested this item 🔴 unsuccessfully on 3d8f2bc
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43974.
@shindebalu Can you please provide the resons for your test result? Also notice that this Pull Request is a draft.
This pull request has been automatically rebased to 6.0-dev.
| Title |
|
||||||
| Labels |
Added:
PR-6.0-dev
Removed: PR-5.2-dev PR-5.3-dev |
||
I think this one is ready for review. I was wondering tho;
Does anyone think it would be a good idea to implement more layouts or an option to format the number like for instance a currency? Or would that be too much and we should stick to default behaviour of the same core field type?
I'm asking because i have a use case where i want to use this field to display prices. Would be nice if i could set the number formatting in the field settings.
Does anyone think it would be a good idea to implement more layouts or an option to format the number like for instance a currency?
like the integer field?
like the integer field?
No i was thinking using https://www.php.net/manual/en/numberformatter.formatcurrency.php and either get locale from the default language or have a list of locales to select from in a dropdown list? The last one would be the "lightest" on rendering is my guess. you could also add an option for the number of fraction digits.
Or just a regular number_format and have 3 settings for currency, thousand seperator and decimal operator.
| Category | Administration Language & Strings Front End Plugins SQL Installation Postgresql | ⇒ | SQL Administration com_admin Postgresql Language & Strings Installation Front End Plugins |
| Title |
|
||||||
@TLWebdesign - I tested this PR, it needs at least 1 fix before I can mark it successful.
When Toggling in the back-end the Toggle Inline Help, the last field Number of Decimals has a language-string instead of text:
PLG_FIELDS_NUMBER_PARAMS_DECIMALS_DESC
ALSO, seeing that the minimum has no bearing on Saving a field with a lower number, it would be good to update the text of the Minimum field: Minimum value that can be chosen (only limits the up/down arrows). to be clearer...
Something like: User can enter any value and a minimum value that can be chosen that limits the up/down arrows.
(or whatever you prefer)
When I set my Minimum to 100000, and saved my field with 5000, it let me save with no warning (even though the minimum was 100000) but then when I used the arrows, it jumped to 100000 - this is perhaps intended but needs clearer info.
Please review all the _desc strings to see if they are really needed.
For example isnt this just obvious from the label and the field options
PLG_FIELDS_NUMBER_PARAMS_POSITION_DESC="Place the symbol before or after number"
Please review all the _desc strings to see if they are really needed.
Ok thanks for having a look, i removed your suggestion and another one.
@TLWebdesign - I tested this PR, it needs at least 1 fix before I can mark it successful.
When Toggling in the back-end the Toggle Inline Help, the last field Number of Decimals has a language-string instead of text: PLG_FIELDS_NUMBER_PARAMS_DECIMALS_DESC
ALSO, seeing that the minimum has no bearing on Saving a field with a lower number, it would be good to update the text of the Minimum field: Minimum value that can be chosen (only limits the up/down arrows). to be clearer...
Something like: User can enter any value and a minimum value that can be chosen that limits the up/down arrows. (or whatever you prefer)
When I set my Minimum to 100000, and saved my field with 5000, it let me save with no warning (even though the minimum was 100000) but then when I used the arrows, it jumped to 100000 - this is perhaps intended but needs clearer info.
The missing language string is fixed. the desc shouldn't be on this field but it was left in the form definition.
For the language, it already states this in the description the same way as the official documentation does. So i'd like to just keep it consistent with that.
I have tested this item ✅ successfully on b89199b
I have tested this successfully! Thanks @TLWebdesign for the fixes.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43974.
I have tested this item ✅ successfully on 8e8f3e2
I have re-tested this successfully. Thanks @TLWebdesign
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43974.
I have tested this item ✅ successfully on 8e8f3e2
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43974.
@TLWebdesign Could you rename the update SQL scripts to something newer than "6.0.0-2025-08-02.sql", e.g. "6.0.0-2025-08-17.sql? Thanks in advance.
P.S. If the name of the new update SQL script is not newer than the latest present one when compared with PHP version compare, it will not run when updating e.g. from 6.0.0-alpha3.
| Labels |
Added:
Updates Requested
|
||
I have tested this item ✅ successfully on 3044c15
I have re-tested this successfully. Thanks @TLWebdesign
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43974.
Filenames "6.0.0-2024-08-24.sql" are still wrong. Please rename to "6.0.0-2025-08-17.sql". Mind also the year!
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-08-16 16:53:11 |
| Closed_By | ⇒ | richard67 |
| Status | Closed | ⇒ | New |
| Closed_Date | 2025-08-16 16:53:11 | ⇒ | |
| Closed_By | richard67 | ⇒ |
| Status | New | ⇒ | Pending |
Sorry, wrong button.
@exlemor Have you also tested updating from 6.0.0-alpha3? Then you would have noticed that the field will not be added on update due to the wrong update SQL script name.
For PRs which add new update SQL scripts updating should always be part of the test.
@TLWebdesign Maybe you should update the testing instructions accordingly.
Filenames "6.0.0-2024-08-24.sql" are still wrong. Please rename to "6.0.0-2025-08-17.sql". Mind also the year!
Filenames "6.0.0-2024-08-24.sql" are still wrong. Please rename to "6.0.0-2025-08-17.sql". Mind also the year!
sorry in the rush to get going here i didn't wait long enough for my laptop to commit the renaming. but i see it is done now. Thanks for your help
I will set RTC as it had 2 tests.
@Bodge-IT @softforge When this and the other one with the other field gets merged before beta 1, then we (or you) have to test if updating still works on MySQL and PostgreSQL. I will try to find time for that tomorrow morning, at least for the PostgreSQL part.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43974.
| Labels |
Added:
RTC
Removed: Updates Requested |
||
I will solve the conflicts in the base.sql now.
Done.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-08-16 18:09:22 |
| Closed_By | ⇒ | Bodge-IT |
Thanks @TLWebdesign, well done. Thanks for all the tests
@brianteeman Thanks for reviewing and fixing my mistakes.