Reported by user alexanderbrix on https://forum.joomla.de/thread/11394-beiträge-veröffentlichung-starten-erhöht-sich-automatisch-bei-kategoriewechsel/ (Joomla 3.9.16)
and i can confirm the issue. User anka in forum, too.
Current nightly 3.9.17-dev
Global Joomla Configuration: Set "Website Time Zone": "Berlin"
Important addition (thanks to anka for further investigations): Create a custom field for articles. Only then the edit form of articles will be reloaded after category change.
Open an article. Note the date fields and fill not filled ones:
Labels |
Added:
?
|
Title |
|
Setting | Value |
---|---|
PHP Built On | Linux dd46134 4.15.0-76-generic #86~16.04.1-Ubuntu SMP Mon Jan 20 11:02:50 UTC 2020 x86_64 |
Database Type | mysql |
Database Version | 5.7.28-nmm1-log |
Database Collation | utf8_general_ci |
Database Connection Collation | utf8mb4_general_ci |
PHP Version | 7.2.24-nmm1 and 7.4.2 |
Web Server | Apache |
WebServer to PHP Interface | fpm-fcgi |
Joomla! Version | Joomla! 3.9.17-dev Development [ Amani ] 10-March-2020 15:28 GMT |
Joomla! Platform Version | Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT |
User Agent | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0 |
Release blocker for 3.9.17? Just asking...
Status | New | ⇒ | Confirmed |
Labels |
Added:
?
|
Priority | Medium | ⇒ | Urgent |
Increasing priority as this will block the upcoming release of 3.9.17
A short known issue doc for this isuue: https://docs.joomla.org/J3.x:Change_of_article_category_changes_article_publishing_dates
Not sure what to do here. The same issue occurs when form validation fails. We store unfiltered data to user state in such case so I don't think #28103 is necessarily wrong. Then again we store validated data when saving in model fails, so issues like #27919 (for which #28103 was made) pop up again.
Maybe you should store half filtered and half unfiltered data ;-) (joking)
Is filtering the problem or the missing fields removed by the filter?
When the fields are missing we could add them again after the filter? (I know sounds awful...)
Just BTW: I wonder why the "Finish Publishing" is increasing by 2 hours while the other date fields just by 1 hour.
Calendar field also changes value client-side sometimes.
Is it possible somehow to suppress the onChange event or whatever is fired by JS after reload?
Is it possible somehow to suppress the onChange event or whatever is fired by JS after reload?
I don't think JS does that on reload, only when date is first entered. But I could be wrong. Maybe someone more familiar with Calendar field knows.
Maybe it would be possible for the field to manipulate displayed value in JS but submit unaltered date.
When the fields are missing we could add them again after the filter? (I know sounds awful...)
This does sound awful. But it could work.
I changed a calendar field to a text field in XML and tested. The date inside the text field stays untouched after reload. Don't know if that helps anyhow... just poking...
Do we find a solution here? If not i would revert the PR til we find a solution.
No solution yet.
Just for information, the issue happens here because Calendar field type works in a different way compare to other form field types.
So this affects every calendar fields in the form.
So the solution here is get filtered data for calendar fields only and get these filtered values back to $data array. It works, but I'm unsure if it's acceptable. Below is the propose code for reload method:
public function reload($key = null, $urlVar = null)
{
// Check for request forgeries.
$this->checkToken();
$app = \JFactory::getApplication();
$model = $this->getModel();
$data = $this->input->post->get('jform', [], 'array');
// Determine the name of the primary key for the data.
if (empty($key))
{
$key = $model->getTable()->getKeyName();
}
// To avoid data collisions the urlVar may be different from the primary key.
if (empty($urlVar))
{
$urlVar = $key;
}
$recordId = $this->input->getInt($urlVar);
// Populate the row id from the session.
$data[$key] = $recordId;
// Check if it is allowed to edit or create the data
if (($recordId && !$this->allowEdit($data, $key)) || (!$recordId && !$this->allowAdd($data)))
{
$this->setRedirect(
\JRoute::_(
'index.php?option=' . $this->option . '&view=' . $this->view_list
. $this->getRedirectToListAppend(), false
)
);
$this->redirect();
}
// The redirect url
$redirectUrl = \JRoute::_(
'index.php?option=' . $this->option . '&view=' . $this->view_item .
$this->getRedirectToItemAppend($recordId, $urlVar),
false
);
/* @var \JForm $form */
$form = $model->getForm($data, false);
/* Get filtered data for calendar fields and set it back to posted data */
$filteredData = $form->filter($data);
foreach ($form->getFieldset() as $field)
{
if ($field->type === 'Calendar')
{
$fieldName = $field->fieldname;
if (isset($filteredData[$fieldName]))
{
$data[$fieldName] = $filteredData[$fieldName];
}
}
}
// Save the data in the session.
$app->setUserState($this->option . '.edit.' . $this->context . '.data', $data);
$this->setRedirect($redirectUrl);
$this->redirect();
}
It's not a complete workaround, I think searching for the filter server_utc and user_utc would be better.
the other way would be to fill only fields with "unset" filter, this would be a more generic approach.
Any opinions at this @SharkyKZ @joomdonation @ReLater and anyone else ;-)
@HLeithner I think we do not need to searching for the filter server_utc and user_utc. From what I see, Calendar is the only field type changed the passed value to it before displaying (a special behavior), so that's the only field type need to have the filter applied he.
@joomdonation that's maybe true for core but maybe not for 3rd party component, so I think searching for the unset filter would be better
Not a fan of the above solution or anything that checks specific field/filter types. The controller shouldn't even be touching the form directly, it should be using model's methods.
I deal solution would be to stop calendar field from altering the value like that, but not sure this can be done in a B/C safe way.
Our calendar has some hacks but validation before saving would make sense anyway and if our only problem is that "unset" filtered fields are missing we should exclude them from getting dropped.
If we can solve this problem with javascript by setting the time correctly I would be happy too.
Status | Confirmed | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-04-07 13:28:30 |
Closed_By | ⇒ | HLeithner |
Labels |
Removed:
?
|