User tests: Successful: Unsuccessful:
Pull Request for Issue #15666.
Changing the default value for the new "Allow Captcha on submit" param in com_content options -> "Editing Layout" to "" (empty) so the "- Use Default -" Option actually can be selected.
Selected "-Use Default -" value stays
After saving the value goes back to "- None Selected -".
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_content |
I have tested this item
i'm able now to Select "-Use Default -" and value comes back after save
can you explain better yuor unsecssfull test case?
try to update from 3.6.5 to 3.7.0 and the author can't be able to insert a new article in frontend. For me we need to fix it without the administrator save the article options. Already now if the administrator save the article options it is ok and the author can be able to insert a new article in frontend.
For all the new parameter in Joomla 3.7.0 we need to set in the php the "if" no value in database the default value in the php is...
try to update from 3.6.5 to 3.7.0 and the author can't be able to insert a new article in frontend.
He should be able to do it fine. He just gets the captcha now by default (if it's enabled in the global config). The feature can be disabled if it's not wanted. Similar to other features which are enabled by default (eg custom fields).
For all the new parameter in Joomla 3.7.0 we need to set in the php the "if" no value in database the default value in the php is...
That's what we usually do, but it doesn't work when you have an empty value which corresponds to "- Use Default -". PHP can't know if that empty value means "not saved yet" or "Use Default". That's the issue.
enable now by default captcha in insert a new article in frontend (if it's enabled in the global config) for me is a bad idea. Who has a template different from Protostar, don't see the captcha and it's not possible to send articles from frontend, but they can't understand why... They see only the error message "Empty solution not allowed."
I tried to do this in the view.html.php, but it still does not work when the captcha parameter is not present in db. Basically, I am looking if the param is present for com_content and its possible values:
if (!array_key_exists('captcha', $params))
{
$captchaSet = '0';
}
elseif ($params->get('captcha', '0') != '0')
{
if ($params->get('captcha', '0') != '')
{
$captchaSet = $params->get('captcha', '0');
}
else
{
$captchaSet = $params->get('captcha', JFactory::getApplication()->get('captcha', '0'));
}
}
foreach (JPluginHelper::getPlugin('captcha') as $plugin)
{
if ($captchaSet === $plugin->name)
{
$this->captchaEnabled = true;
break;
}
}
This succeeds in NOT displaying the captcha in the edit form but, as @AlexRed says, when saving, I get a "Empty solution not allowed."
Weird...
If I replace the code
$captchaSet = $params->get('captcha', JFactory::getApplication()->get('captcha', '0'));
by
$captchaSet = $params->get('captcha', JFactory::getConfig()->get('captcha'));
which makes more sense, same issue.
That doesn't work because the formfield itself is checking the parameters as well. You can't change that behavior.
The form only breaks if the template has an override for it. But that's the risk (or duty) of having an override, you need to check after an upgrade if it still works. In this case here, simply saving the options fixes it as well.
What we could try to do is improving the error message so it says that it's the captcha that is failing.
This PR needs to go in regardless.
I have tested this item
Without discussing the other comments/possible changes needed: this PR fixes the described issue of not being able to change the parameter to "-Use Default - for Allow Captcha on submit as least.
Done.
Status | Pending | ⇒ | Ready to Commit |
RTC after two successful tests.
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-03 08:37:02 |
Closed_By | ⇒ | rdeutz | |
Labels |
Added:
?
|
I have tested this item? unsuccessfully on 8e116eb
Please, we need to fix it for all the users who update.
Now the problem is here also with this patch.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15687.