[4.2] Fix deprecated warning for Calendar form fields on PHP 8.1+

[joomdonation]

Pull Request for Issue # .

Summary of Changes

This PR fixes deprecated warnings for calendar form field which does not have translateformat="true" in it's definition. From what I see, all calendar form fields use on Joomla core have translateformat="true", so this PR will only affect third party extensions use this form field type. There are few changes in this PR:

1. Allow define filterformat attribute for calendar form field. This attribute, if provided, must provide equivalent format with format defined in format attribute of the field.
2. In case filterformat is not defined, the system will try to calculate value for filterFormat base on the format provided in format attribute. And just to be safe, we will only do this format calculation for PHP 8.1 only.

Testing Instructions

1. Use Joomla 4.2 on PHP 8.1
2. Modify this block of xml https://github.com/joomla/joomla-cms/blob/4.1-dev/administrator/components/com_content/forms/article.xml#L87-L94 to :

<field
			name="created"
			type="calendar"
			label="COM_CONTENT_FIELD_CREATED_LABEL"
			format="%Y-%m-%d %H:%M:%S"
			filter="user_utc"
		/>

3. Try to edit article, change data of Created Date, make sure it is being saved properly (this is test for case filterformat is not defined)
4. Try to modify the above xml code to:

<field
			name="created"
			type="calendar"
			label="COM_CONTENT_FIELD_CREATED_LABEL"
			format="%Y-%m-%d %H:%M:%S"
                        filterformat="Y-m-d H:i:s"
			filter="user_utc"
		/>

5. Edit article, change date of Created Date again, make sure it is being saved properly (this is test for case filterformat is defined)

[richard67]

And just to be safe, we will only do this format calculation for PHP 8.1 only.

@joomdonation Any reason for that? I know, the PHP deprecated warning only happens on PHP 8.1+. But would it be unsafe to do this calculation also on lower versions so we have the same behaviour on all versions? I'd really like to avoid functional behaviour depending on the PHP version.

[joomdonation]

@richard67 It is just because I don't know how reliable the code for strftimeFormatToDateFormat is. As you can see from the comment, it is just a script from stackoverflow

Honestly, I'm unsure if we should do that format conversion automatically like that. I don't know which one is better:

• Do the conversion like how we are doing on this PR
• Or Do not do that and force developer to update extension, add filterFormat attribute to the form to make it fully compatible with 8.1

[laoneo]

I second here the argument of @richard67, there should not be PHP dependent code. Personally I would introduce another attribute where the extension dev can pass a PHP date command instead of strftime. I expect some issues when we do some magic transformation.

[joomla-bot]

This pull requests has been automatically converted to the PSR-12 coding standard.

[xjdfhbv]

What is happening with this problem please? At the moment there is no way to make a date field without warnings in PHP 8.1, without using translateformat="true". In this case both format and filterformat are ignored, and the format is DATE_FORMAT_CALENDAR_DATE. In English, "%Y-%m-%d, but in Russian (for example) "%d-%m-%Y". In other words there is currently no way to make a calendar field with a specific date format. Or am I missing something?

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37376.}

[joomdonation]

I updated the PR to remove the magic format conversion. If someone uses Calendar form field without translateformat="true" and want to prevent deprecated warnings on PHP, he needs to add filterformat attribute with right value to his field definition.

@xjdfhbv Could you please help testing this PR ? If this is accepted, it will give a way to solve your problem.

[xjdfhbv]

I would be happy to test it but I have no idea how to download the modified code!

[joomdonation]

@xjdfhbv You can try to get the attached CalendarField.zip file, unzip it, upload the received file to libraries/src/Form/Field folder on your Joomla installation to test the change.

[xjdfhbv]

Well, it works with filterformat="Y-m-d", but when I tried filterformat="d-m-Y" and default="27-03-2023", the field appears with the value 2032-09-12.

[joomdonation]

Well, it works with filterformat="Y-m-d", but when I tried filterformat="d-m-Y" and default="27-03-2023", the field appears with the value 2032-09-12.

Could not re-procedure this issue myself. I can only guess that it happens because you do not add format="%d-%m-%Y" to the field ? Please note that in order to have it works, you need to have both format and filterformat defined. Something like:

<field
    name="test_calendar"
    type="calendar"
    label="Test Calendar Field"
    filterformat="d-m-Y"
    default="27-03-2023"
    showtime="false"
    filter="user_utc"
    />

Could you please try again and update us with the result? Thanks !

[xjdfhbv]

You are right, it works correctly if you specify a non-empty value for format. Even something like format="yes" is ok. It would be better if that wasn't necessary.

[joomdonation]

That format is used by the javascript code for calendar form field. I haven't read the code to understand exactly how it is used, but I think it is needed. I don't know how format="yes" works in this case, I would say that the format is needed so that when you select a date time from the popup, the value in the right format will be displayed in the text input. But I'm unsure.

[xjdfhbv]

Oh yes, you are right, an invalid format crashes the javascript. Both formats are needed, and they must be compatible, for example format="%m-%d-%Y" filterformat="m-d-Y". Ok, so with that understood, this is now a working solution.

[joomdonation]

Yes, that's right. Both format are needed and must be compatible with each other. format is used by javascript and filterformat is used by PHP for formatting the datetime.

Could you please go to https://issues.joomla.org/tracker/joomla-cms/37376 and mark your test result? Each PR needs 2 successful tests before It could be merged. Thanks !

[xjdfhbv]

I have tested this item :white_check_mark: successfully on 84fb229cd98de71716a8ff9da9fc0151835641d9

Tested OK

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37376.}

[xjdfhbv]

Just for information, when setting a calendar field value dynamically using Form::bind() or Form::setValue() you always have to use Y-m-d format, even if a custom date format is specified with format and filterformat. If you try to dynamically set a date like "03-29-2023", a PHP error occurs.

This also applies when using translateformat="true". Most countries have DATE_FORMAT_CALENDAR_DATE="%Y-%m-%d" so there is no problem. But some countries (e.g. ru-RU) have DATE_FORMAT_CALENDAR_DATE="%d-%m-%Y", and in this case if you recycle the form post data straight back to re-initialise the form values, you get a PHP error. You always have to transform dates back to Y-m-d format to initialise calendar field values.

It's a bit messy, but this is how it works historically so we are stuck with it. At some time in the future, an easier solution will be to use format="%Y-%m-%d" filterformat="Y-m-d".

[carlitorweb]

I have tested this item :white_check_mark: successfully on 84fb229cd98de71716a8ff9da9fc0151835641d9

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37376.}

[carlitorweb]

@joomdonation can this PR handle the Deprecated: Creation of dynamic property... messages this class have on php 8.2?

[joomdonation]

@carlitorweb We can do that in a separate PR later . There are still so many Deprecated messages in our code base for with PHP 8.2.

[joomdonation]

RTC. Thanks all for testing and feedbacks !

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37376.}

[laoneo]

@carlitorweb there is already a pr for it #39605

[laoneo]

Thanks!