User tests: Successful: Unsuccessful:
Pull Request for Issues like #19735 and #17801 and for PRs #18188, #17837, #18207, #19742, #19753, #19850.
As #19753 revealed that the request data should be normalised only for com_fields and we do not want to have extension specific code in the libraries. This pr adds a new event which sends the data for normalisation in the controller. Like that the fields plugin can then modify the data.
Remark:
I was unsure about the plugin name, any feedback is welcome.
JFactory::getUser($USER_ID)->save();
.The user custom field data is still saved on the user.
The user custom fields data on the user are deleted.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_fields Libraries Front End Plugins |
Labels |
Added:
?
|
I'm also not sure if strlen is the solution as asked here #19753 (comment).
I'm also not sure if strlen is the solution as asked here
well, $value can not be an object, it is either
null, boolean, string, or array
null, boolean, string are all of them 'valid' inputs for strlen
so the only check that needs to be made is that $value and $value[0] are not an array
consider "empty" if
is_array($value) ? !count($value) : !strlen($value)
the above should replace empty($value)
is_array($value[0]) ? !count($value[0]) : !strlen($value[0])
the above should replace empty($value[0])
Category | Administration com_fields Libraries Front End Plugins | ⇒ | Administration com_fields Front End com_users Libraries Plugins |
I have tested this item
Tested on both com_content and com_user (back-end and front-end)
pinging @Denitz , @joomdonation , @ggppdk on this PR.
I have been trying to test for all your (related) issues and I think that they are fixed with this PR.
Can you test as well so we can get 'the show on the road' :)
Also calling on @tassosm and @regularlabs as I know they develop custom fields and (could) have an interest in also getting this fixed :)
Hi @laoneo just did two PR's against your repo.
with these PR's it is possible to save value 0 as actual value AND it corrects the incorrect behaviour on single character text values (strlen = 1)
Now clicking the Save
button two times will clear entered values.
@Quy could you try this: Digital-Peak#12
That should fix it.
Ok please let me explain things
the empty() check was in 2 places
now both are patched
but
It was:
$needsUpdate = !empty($value[0]);
It was patched to be
$needsUpdate = is_array($value[0]) ? !count($value[0]) : !strlen($value[0]);
The negation was of !empty($value[0])
Now clicking the Save button two times will clear entered values.
that is why it is not working !
the complex expression that you suggest in your PR fixes it but it is not needed be like that,
you are just readding the negation back with a more complex expression
so just re-add the negation:
$needsUpdate = ! (is_array($value[0]) ? !count($value[0]) : !strlen($value[0]));
//or better
$needsUpdate = is_array($value[0]) ? count($value[0]) : strlen($value[0]));
the complex expression that you suggest in your PR fixes it but it is not needed be like that,
you are just readding the negation back with a more complex expression
Agree and @laoneo already simplified that. the code I suggested was a quick-mockup from me trouble shooting where things went wrong :)
With this last PR Digital-Peak#12 it works :)
with your code:
$needsUpdate = is_array($value[0]) ? count($value[0]) : strlen($value[0]);
When this PR is committed I will be re-doing all my test cases (which are already a lot :))
I have tested this item
Tested on both com_content and com_user (back-end and front-end)
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-03-25 14:55:12 |
Closed_By | ⇒ | mbabker | |
Labels |
Added:
?
|
value '0' is quite common,
the checks empty($value) and empty($value[0]) should be changed