Labels |
Added:
?
|
Category | ⇒ | com_csp |
Privacy Consent is a System plugin. It runs before User plugins.
TBH, I don't know if there is a good fix for this then. Because those two sets of fields are both being added by plugins, and the system plugin with the privacy consent is going to be run before the user profile plugin. To fix this means reordering the fields in the Form definition, and the only way to write a code solution for that is to introduce a very hard coupling between the core com_users views and the core consent and user profile plugins (because the fields are basically rendered in the order they're added, a system plugin is always going to run before a user plugin, and the form API doesn't give a way to specify field order because in that part of the API the order (which affects presentation) doesn't matter).
so is not possible to make it legal corect?
I personally have not seen a law that mandates the consent field must be immediately next to the submit action. But without changing your layout to manually render every field instead of using the dynamic functions to render all fields, no, it is not possible to specify the ordering of fields in a form.
it is common law for ecommerce and for everything nothing between tos, agreement and submit. I am very sure it is for registration too. So privacy tool cannot be legal from box - that is sad :(
I asked the lawyer he say Art. 7 GDPR number 2 says "the request for consent shall be presented in a manner which is clearly distinguishable from the other matters" that is very same to the ecommerce consent I know. If the user field are too much the consent is too far away from submit.
It can be made to render in the way you want, but this is a level of customization that cannot be done in core. The core layouts should not have hard coupled code between components and specific plugins (plugins are supposed to generically extend functionality, a specific plugin's implementation of that extended functionality should never be known outside the plugin, the fact that there are existing hard couplings between components and plugins is an architectural flaw that should be fixed and not the right way to handle things). On your own site, as you know the specific plugins in use, you can customize the layout to reorder the fields in any way you desire (this of course comes with extra maintenance burden of a layout override to keep up with), and can introduce logic specific to a plugin or a field added by a plugin.
So it's not a core issue that the fields don't render in the order you'd like (unless someone really wants to write more API for the Form class to order fields, I still say this is a presentation matter and not something that actually belongs in the Form class though). It's a core issue that the fields are added by plugins and not hardcoded into the components where the ordering is better controlled, but even if we did that the ordering would still be affected by other plugins adding (or potentially removing) fields.
Art. 7 GDPR number 2 says "the request for consent shall be presented in a manner which is clearly distinguishable from the other matters"
That implies that a consent field has a visual distinction from the other activity on the page, not that it is required to be shown next to a submit button. The general convention is to put these types of requirements next to the submit button, I agree there, but we have a software limitation which does not make this practical to achieve in core.
I ordered the privacy plugin at the end of all plugins but still not above submit. So I have to create a huge form and render all fields manualy like an override to have joomla legal?
Maybe a developer can help to solve. hopeful
The ordering only applies within the plugin group it is registered.
Plugins are imported by groups. Plugins are then processed in the order that they're imported (group then ordering within the group) The system plugin group is always the first plugin group imported as those plugins are available globally. Plugin groups like the content and user groups are imported in components as needed. So the privacy plugin will always run before any user plugin, because for any event the plugins from the system group are going to be executed first.
Again, the only way to fix this at a purely code level with a correct solution is to introduce logic to the Form API to order fields. There is no other code solution that is appropriate. As pointed out, there are ways you can address this on your own sites, but those solutions are not going to be appropriate for core.
ok, maybe a developer can help to make form logic, that would be good also for contact form and everything
This is the same problem as with the captcha plugin
Status | New | ⇒ | Discussion |
Labels |
Added:
J3 Issue
|
you solved it? i ve the same problem
as already stated a possible solution is to Create an Override of the registration form
in your Joomla administrator area,
well now you have an override for the registration form
<?php
/**
* @package Joomla.Site
* @subpackage com_users
*
* @copyright Copyright (C) 2005 - 2019 Open Source Matters, Inc. All rights reserved.
* @license GNU General Public License version 2 or later; see LICENSE.txt
*/
defined('_JEXEC') or die;
JHtml::_('behavior.keepalive');
JHtml::_('behavior.formvalidator');
?>
<div class="registration<?php echo $this->pageclass_sfx; ?>">
<?php if ($this->params->get('show_page_heading')) : ?>
<div class="page-header">
<h1><?php echo $this->escape($this->params->get('page_heading')); ?></h1>
</div>
<?php endif; ?>
<form id="member-registration" action="<?php echo JRoute::_('index.php?option=com_users&task=registration.register'); ?>" method="post" class="form-validate form-horizontal well" enctype="multipart/form-data">
<?php // Iterate through the form fieldsets and display each one. ?>
<?php foreach ($this->form->getFieldsets() as $fieldset) : ?>
<?php $fields = $this->form->getFieldset($fieldset->name); ?>
<?php if (count($fields)) : ?>
<?php
if (isset($fields['jform_terms_terms']))
{
$moveToEnd = $fieldset;
continue;
}
?>
<fieldset>
<?php // If the fieldset has a label set, display it as the legend. ?>
<?php if (isset($fieldset->label)) : ?>
<legend><?php echo JText::_($fieldset->label); ?></legend>
<?php endif; ?>
<?php echo $this->form->renderFieldset($fieldset->name); ?>
</fieldset>
<?php endif; ?>
<?php endforeach; ?>
<?php if (isset($moveToEnd)) : ?>
<fieldset>
<?php // If the fieldset has a label set, display it as the legend. ?>
<?php if (isset($moveToEnd->label)) : ?>
<legend><?php echo JText::_($moveToEnd->label); ?></legend>
<?php endif; ?>
<?php echo $this->form->renderFieldset($moveToEnd->name); ?>
</fieldset>
<?php endif; ?>
<div class="control-group">
<div class="controls">
<button type="submit" class="btn btn-primary validate">
<?php echo JText::_('JREGISTER'); ?>
</button>
<a class="btn" href="<?php echo JRoute::_(''); ?>" title="<?php echo JText::_('JCANCEL'); ?>">
<?php echo JText::_('JCANCEL'); ?>
</a>
<input type="hidden" name="option" value="com_users" />
<input type="hidden" name="task" value="registration.register" />
</div>
</div>
<?php echo JHtml::_('form.token'); ?>
</form>
</div>
you have moved the privacy to the end of the form....
something like this
Category | com_csp | ⇒ | com_csp com_users |
Status | Discussion | ⇒ | Expected Behaviour |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-12-07 09:02:53 |
Closed_By | ⇒ | alikon |
Status | Expected Behaviour | ⇒ | Closed |
Closed_By | alikon | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/22168
great mr Alicon!!! thank you so much. Is it possible to assign .control-label "jform_terms_terms" a particular class?
That screenshot doesn't look like one of the core templates.
Please check this against a core template. You may need to make changes to your layout override to move the fields the plugin adds to the form to the right spot on the page.