? ? ? Success

User tests: Successful: Unsuccessful:

avatar brianteeman
brianteeman
10 Jan 2019

It is very common to need to display a unit of measurement with a field. Currently there is no way to do this without creating custom layouts for every field and every unit when needed.

This PR adds a new param to every custom field "Suffix" which allows you to add a unit of measurement (or any other text) to be rendered after the value of the field.

The new field is disabled by default so three is no b/c issue

To test

Apply the pr and then create a new custom field and you will see the new Suffix param in the render options.
image

Example usage

Before

image

After

image

##Plurals
If you need to have a different suffix for a plural then you can do this as follows

  1. In the suffix field enter a key such as MINUTE_N
  2. Create a language override MINUTE_N = Minutes
  3. Create any additional language overrides for specific numbers eg MINUTE_N_1 = Minute

The output will now be
0 Minutes
1 Minute
10 Minutes

Votes

# of Users Experiencing Issue
1/1
Average Importance Score
5.00

avatar brianteeman brianteeman - open - 10 Jan 2019
avatar brianteeman brianteeman - change - 10 Jan 2019
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 10 Jan 2019
Category Administration com_fields Language & Strings Front End
avatar wilsonge
wilsonge - comment - 10 Jan 2019

This is nice but i guess needs to be translatable so it can be run through Text::plural so that you can have mile vs miles, minute vs minutes etc etc

avatar brianteeman
brianteeman - comment - 10 Jan 2019

How is that possible?

avatar Bakual
Bakual - comment - 10 Jan 2019

For the rendering part, it would be possible, but the user would need to understand how plural strings work. You would have to enter a string like CUSTOM_UNIT. In the language override manager you then add the strings CUSTOM_UNIT_0, CUSTOM_UNIT_1 and CUSTOM_UNIT (for en-GB, other languages need different suffixes and maybe more or less strings) with the respective values.
When rendered, you pass the value and string through Text::plural. Eg Text::plural('CUSTOM_UNIT', 5);

edit: corrected my example which was wrong

avatar brianteeman
brianteeman - comment - 10 Jan 2019

It would be pretty pointless to do that and overly complex.

avatar Bakual
Bakual - comment - 10 Jan 2019

For english and german it's certainly not something that is needed often. We usually just write the plural.
I honestly don't know how such things are handled in other languages.

avatar brianteeman
brianteeman - comment - 10 Jan 2019

There are some things that can never be "easily" automated or translated. If someone really needs it then they can create an override but I doubt they ever will..

avatar ot2sen
ot2sen - comment - 10 Jan 2019

For the recipe example, it would be useful, in Danish at least.
Servings: 1 Adult
Preparation time: 1 Hour

Nice improvement btw. :)

avatar brianteeman
brianteeman - comment - 10 Jan 2019

Good luck writing the code to do that so it is usable - but I guess I will just have to make the changes in my own sites manually

avatar Bakual
Bakual - comment - 10 Jan 2019

I don't know. The code line is easy. Just pass the unit string through that Text::plural() function together with the value of the field. Or do I miss something?
If the user doesn't need that feature, the string will be rendered unchanged. If the user adds all the necessary language strings manually (eg in the language override manager) and knows what he does, it will be nicely translated. Same thing we do in other places where user input may be translatable.

avatar AndySDH
AndySDH - comment - 11 Jan 2019

This is a very nice idea. It would save the trouble of using layout overrides for the suffix.

It's also useful to have a "Prefix" option as well. Think of prices. You probably want to prepend a dollar icon, like: $200.

What would also be cool (another thing that I've been doing with custom layouts so far), is the ability to set a number_format for numeric values (so for text fields and for integer fields), allowing to set separators for thousands and decimals.

So for example, 365100 can be displayed as 365,100.
Or, 25.368274 (decimals) can be limited to 2 decimals as: 25.37.

Just throwing the idea out there as well. All stuff that I have been doing with layout overrides so far.

avatar brianteeman
brianteeman - comment - 11 Jan 2019

@AndySDH that is an interesting idea but off topic for this PR as it relates to just the integer field - this PR is for all fields.

avatar brianteeman
brianteeman - comment - 11 Jan 2019

Same thing we do in other places where user input may be translatable.

Can you point to an example please

avatar Bakual
Bakual - comment - 11 Jan 2019

Can you point to an example please

The title of a custom field is translatable, just a few lines above your added code.

$label = JText::_($field->label);

It's not using the plural method in that case, but the concept should work same.

avatar brianteeman brianteeman - change - 11 Jan 2019
Labels Added: ? ?
avatar brianteeman brianteeman - change - 11 Jan 2019
The description was changed
avatar brianteeman brianteeman - edited - 11 Jan 2019
avatar brianteeman
brianteeman - comment - 11 Jan 2019

Updated code (and instructions above) for plurals

avatar Bakual
Bakual - comment - 11 Jan 2019

I have tested this item successfully on 0973b87

Test units, including plural. Worked fine.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23499.

avatar Bakual Bakual - test_item - 11 Jan 2019 - Tested successfully
avatar AndySDH AndySDH - test_item - 11 Jan 2019 - Tested successfully
avatar AndySDH
AndySDH - comment - 11 Jan 2019

Issue I just realized with the code. This breaks out of the "field-value" span, as it sits outside of it. Therefore breaking the style of the value part.

The suffix span should instead be part of the field-value span as well.

<span class="field-value">
	<?php echo $value; ?>
	<?php if ($showSuffix == 1) : ?>
		<span class="field-suffix"><?php echo htmlentities($suffix, ENT_QUOTES | ENT_IGNORE, 'UTF-8'); ?></span>
	<?php endif; ?>
</span>

avatar brianteeman
brianteeman - comment - 11 Jan 2019

Why? This way allows styling for the suffix independent of the value

avatar brianteeman
brianteeman - comment - 11 Jan 2019

a new field cannot break your layout!

avatar AndySDH
AndySDH - comment - 11 Jan 2019

Here is what I mean happens now:

image

image

But up to you. I can override the render.php and fix it for my sites. So that's no problem. But I might not be the only one that took this styling approach.

avatar brianteeman
brianteeman - comment - 11 Jan 2019

So you would just adjust your template as you would whenever you add something new.

avatar Bakual
Bakual - comment - 11 Jan 2019

Either overriding the JLayout or adjusting the CSS allows to fix this for you.
It always depends on your usecase, what structure would be better. For example if you have mixed fields, some with and some without units (or with different units) you can align the numbers better with Brians approach.

avatar AndySDH
AndySDH - comment - 11 Jan 2019

I have tested this item successfully on 0973b87


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23499.

avatar AndySDH AndySDH - test_item - 11 Jan 2019 - Tested successfully
avatar Quy Quy - change - 11 Jan 2019
Status Pending Ready to Commit
avatar Quy
Quy - comment - 11 Jan 2019

RTC


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23499.

avatar AndySDH
AndySDH - comment - 11 Jan 2019

Just throwing out a couple of thoughts. Feel free to bash them.

  • Do we need the "Show Suffix" option? I think we could simply have the "Suffix" field, and in the layout file simply check if it's empty or not. If it's empty, don't display it. If not empty, display it. No need for an extra toggle imho.

  • And I think we could easily add a "Prefix" along with it, with the same exact logic as the suffix. So it would become something simple like:

image

Just my two cents anyway.

avatar Bakual
Bakual - comment - 11 Jan 2019

Do we need the "Show Suffix" option? I think we could simply have the "Suffix" field, and in the layout file simply check if it's empty or not. If it's empty, don't display it. If not empty, display it. No need for an extra toggle imho.

That's a good idea imho.

And I think we could easily add a "Prefix" along with it, with the same exact logic as the suffix. So it would become something simple like:

Personally I'd say you don't need both a prefix and a suffix. Or do you have a case where you'd use both at the same time? Otherwise the unit field could also be used before the value, nothing stops you from doing that in your override.

avatar brianteeman
brianteeman - comment - 11 Jan 2019

Feel free to submit your own pull request - I am not changing this

avatar AndySDH
AndySDH - comment - 11 Jan 2019

Feel free to submit your own pull request - I am not changing this

Well, I think this is good enough. As in, I don't think there is a urge to do more. Was just adding food for thought in case it resonated with you :)

avatar infograf768
infograf768 - comment - 12 Jan 2019

RC is out. Language freeze is on.
This would be for next version.

avatar Bakual
Bakual - comment - 12 Jan 2019

This would be for next version.

Actually, since it's a new feature and thus goes into 3.10 (if new features are merged into that) or 4.0.

avatar AndySDH
AndySDH - comment - 12 Jan 2019

This would be for next version.

Actually, since it's a new feature and thus goes into 3.10 (if new features are merged into that) or 4.0.

I understand your concept of keeping new features for new "minor" versions but this approach just doesn't work. Because for some reason you self-impose yourself to only release minor versions up to a certain amount of numbers or only after a certain amount of months. Why can't you release them at a consistent pace instead of one like every year? Why can't there be a 3.11? a 3.12? a 3.34?

No, you can only go up to 3.10, meaning that if 3.10 happens to come out in 2 years, features can be finished and ready to go, but purposely withheld for months or even whole years (Yes, years!! I know it happened last year), no matter how small and simple they are, either (like this one).

It hinders Joomla from progressing and improving at a fast pace. Put features in when they are ready. So that more stuff can be done. Waiting delays progress. So imho: either change this policy or keep running behind.

So... I guess it's time for my sites to manually override this feature for 1 year before it makes it in an official release. I did this from November 2017 to November 2018 last year for another feature, I can do it again.

avatar brianteeman
brianteeman - comment - 12 Jan 2019

I agree this is a feature and not a bug fix so it should not be in a patch release BUT If the next minor release is only going to be made at the same time as joomla 4.0 then we have a problem as @wilsonge has stated that it will not be released until 2020

avatar Bakual
Bakual - comment - 12 Jan 2019

Because for some reason you self-impose yourself to only release minor versions up to a certain amount of numbers or only after a certain amount of months.

We decided to follow SemVer which mandates that new features require a new minor version.
There is no such rule that there can't be more minors per year. We could release minors every three months or whatever. It just needs someone willing to do the release work. That's the limiting ressource.

BUT If the next minor release is only going to be made at the same time as joomla 4.0 then we have a problem as @wilsonge has stated that it will not be released until 2020

I fully agree and that's why I asked the PD to revisit this and allow more minors within J3 until J4 is released. It was (unfortunately in my opinion) rejected so there is more focus on J4.

avatar brianteeman
brianteeman - comment - 12 Jan 2019

I fully agree and that's why I asked the PD to revisit this and allow more minors within J3 until J4 is released. It was (unfortunately in my opinion) rejected so there is more focus on J4.

Is that documented somewhere? If it is then the maintainers of the issue tracker should be made aware so that they can inform people when they submit a PR that it wont see the light of day until 2020 - so much for release often

avatar Bakual
Bakual - comment - 12 Jan 2019

Only what is written in the Meeting notes (https://volunteers.joomla.org/departments/production/reports/936-production-meeting-december-2018):

It was voted to reject this and stick to the current plan of having 3.10 as the bridge release for Joomla 4

I don't really have more informations. @wilsonge or any other PD member could explain it better.

avatar brianteeman
brianteeman - comment - 12 Jan 2019

ah - that is what in the missing sentence

chrome_2019-01-12_18-20-41

avatar Bakual
Bakual - comment - 12 Jan 2019

Yeah, something is missing there ?

avatar AndySDH
AndySDH - comment - 12 Jan 2019

We could release minors every three months or whatever. It just needs someone willing to do the release work. That's the limiting ressource.

Eh, I see. Wish I had the skills to do it!

so that they can inform people when they submit a PR that it wont see the light of day until 2020 - so much for release often

I know right. So disheartening... :(

avatar mbabker
mbabker - comment - 12 Jan 2019

We could release minors every three months or whatever. It just needs someone willing to do the release work. That's the limiting ressource.

Eh, I see. Wish I had the skills to do it!

For the record, a minor release involves much more than just running the packaging script and publishing the release. Feature releases typically involve a larger number of project teams and resources, so a quick release cadence puts more work (and more burn out) on a higher number of project teams. Likewise, a quick release cadence alienates end users (even after having almost monthly releases for two years end users still groan that is too often). For a project the scale of Joomla, it is not feasible to push minor releases every time a feature is ready to ship to production.

avatar AndySDH
AndySDH - comment - 12 Jan 2019

For the record, a minor release involves much more than just running the packaging script and publishing the release. Feature releases typically involve a larger number of project teams and resources, so a quick release cadence puts more work (and more burn out) on a higher number of project teams. Likewise, a quick release cadence alienates end users (even after having almost monthly releases for two years end users still groan that is too often). For a project the scale of Joomla, it is not feasible to push minor releases every time a feature is ready to ship to production.

Well yeah, of course. I'm by no means saying there should be one every time there is a new feature ready, of course. But not even one release per year. There has to be a happy medium. Especially in this case where it's established for sure that it would take a full year for the next release.

avatar mbabker
mbabker - comment - 12 Jan 2019

One or two feature releases per year is that happy medium if you are one of the ones who are actively involved in the release processes (actual release publishing, marketing, documentation, translations, etc.). Anything more than that is asking for trouble, unless you are the CEO of a corporation using your company to force things to happen in your open source software to fulfill your for-profit organization's needs and investor promises.

avatar AndySDH
AndySDH - comment - 12 Jan 2019

Two would be an upgrade already. Especially now that with 3.10 being coupled with 4.0, it might get delayed etc. so there could potentially be 1.5+ year with no features getting merged... just because it has been decided that the number 3.10 "has" to be the last. No need to self-impose that restriction imho.
Oh well. Let's go back watching NXT UK Takeover.

avatar mbabker
mbabker - comment - 12 Jan 2019

3.9 was originally supposed to be the 4.0 bridge. Plans change.

Here's the issue from a pure code perspective. 4.0 is still 5 releases behind staging, this includes the entirety of 3.9. As long as features continue landing in 3.x, that just adds to the backlog of things that have to be merged forward to 4.0 (and then adapted to the 4.0 code). So moving forward on 3.x just makes it harder to move forward on 4.0 until 4.0 is caught up with 3.x (and it should never fall behind again once caught up). Sooner or later, you have to prioritize shipping 4.0 over continuing to ship 3.x feature releases, otherwise you continue to have the moving target of 4.0 with no realistic milestone in sight and continue splitting the few resources there are actually working on getting 4.0 shipped (outside of this elusive template team which seems to be the only 4.0 only group of people, most people working on 4.0 stuff are also working on 3.x maintenance). So sooner or later, it actually is a good thing that someone comes up and says "OK, 3.x feature releases are slowing down so we can actually ship 4.0 while PHP is still a relevant programming language".

avatar AndySDH
AndySDH - comment - 12 Jan 2019

3.9 was originally supposed to be the 4.0 bridge. Plans change.

Here's the issue from a pure code perspective. 4.0 is still 5 releases behind staging, this includes the entirety of 3.9. As long as features continue landing in 3.x, that just adds to the backlog of things that have to be merged forward to 4.0 (and then adapted to the 4.0 code). So moving forward on 3.x just makes it harder to move forward on 4.0 until 4.0 is caught up with 3.x (and it should never fall behind again once caught up). Sooner or later, you have to prioritize shipping 4.0 over continuing to ship 3.x feature releases, otherwise you continue to have the moving target of 4.0 with no realistic milestone in sight and continue splitting the few resources there are actually working on getting 4.0 shipped (outside of this elusive template team which seems to be the only 4.0 only group of people, most people working on 4.0 stuff are also working on 3.x maintenance). So sooner or later, it actually is a good thing that someone comes up and says "OK, 3.x feature releases are slowing down so we can actually ship 4.0 while PHP is still a relevant programming language".

LOL. It makes sense when put like that. Although I imagine that both bugfixes or features is stuff that needs to be merged forward anyway, so I assume it doesn't make much of a difference whether it's bugfix or a feature, especially if small like in this example. But I get it. I get this point of view too.
Well, I hope everything goes smoothly and you guys manage to catch up.

(This can probably be closed now by the way)

avatar kofaysi
kofaysi - comment - 18 Jan 2019

I have tested this item successfully on 0973b87

Tested with currency abbreviations. Worked well.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23499.

avatar kofaysi kofaysi - test_item - 18 Jan 2019 - Tested successfully
avatar rdeutz
rdeutz - comment - 19 Jan 2019

@wilsonge rebase on 4.0-dev ?

avatar brianteeman
brianteeman - comment - 16 Mar 2019

@HLeithner @wilsonge will this be accepted for J3 or should I refactor for J4

avatar HLeithner
HLeithner - comment - 18 Mar 2019

@brianteeman

Please migrate to j4 and please if its possible for you add post- and prefix maybe as selectbox.

avatar brianteeman
brianteeman - comment - 18 Mar 2019

I will rebase for j4 but i will not add the ability to only have either a prefix or a suffix
That places a limitation on the usage that is not required

avatar HLeithner
HLeithner - comment - 18 Mar 2019

Add both?

avatar AndySDH
AndySDH - comment - 18 Mar 2019

See my comment for inspiration :)
#23499 (comment)

avatar brianteeman
brianteeman - comment - 18 Mar 2019

yes i will do both but not have a switch

avatar wilsonge
wilsonge - comment - 18 Mar 2019

Once this is migrated to 4.0 branch this is approved (in case another maintainer gets to it before me)

avatar brianteeman
brianteeman - comment - 18 Mar 2019

Closed see #24232

avatar brianteeman brianteeman - close - 18 Mar 2019
avatar brianteeman brianteeman - change - 18 Mar 2019
Status Ready to Commit Closed
Closed_Date 0000-00-00 00:00:00 2019-03-18 16:30:54
Closed_By brianteeman
Labels Added: ?

Add a Comment

Login with GitHub to post a comment