No Code Attached Yet Documentation Required
avatar toivo
29 Nov 2021

Steps to reproduce the issue

Install Joomla 4.0.4
Install en-AU language pack en-AU_joomla_lang_full_4.0.4v2.
Make en-AU default.
Create an article and save it.
Modify the article and save it.

Expected result

No errors.

Actual result

0 Call to a member function format() on bool

System information (as much as possible)

Joomla 4.0.4

Additional comments

Reported and confirmed in the Forum topic
Workaround by changing the filter format:

Go to administrator/language/en-AU/joomla.ini and edit the line 829:

Change this line back to what Joomla 3.10.3 has in line 6 of the file administrator/language/en-AU/en-AU.ini and the problem goes away:

avatar toivo toivo - open - 29 Nov 2021
avatar toivo toivo - change - 29 Nov 2021
Labels Removed: ?
avatar joomla-cms-bot joomla-cms-bot - change - 29 Nov 2021
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 29 Nov 2021
avatar ceford
ceford - comment - 29 Nov 2021

To clarify, this is what is in the joomla.ini file for en-AU:


It is the inconsistency in CALENDAR_DATETIME and FILTER_DATETIME that needs to be caught in the Calendar field. Look at line 360 of CalendarField.php.

This comment was created with the J!Tracker Application at

avatar particthistle
particthistle - comment - 29 Nov 2021

The issue is not specifically with the language string, but with how it is processed as @ceford pointed out.

Workaround for language pack until the main issue is fixed
In the pack out tomorrow DATE_FORMAT_CALENDAR_DATETIME in en-AU will be reset to:

The ability though to set fields for d/m/Y (en-AU) or m/d/Y (en-US)

Longer Term Fix
#35222 should have resolved it, but does not appear to do the various conversions that are required correctly.

The issue (also discussed in #35207) is that whichever format the date is being displayed in needs to always be converted back into Y-m-d H:i:s format for saving to the database.

Unfortunately, my PHP, JS and available time don't currently combine to resolving the code in CalendarField.php to avoid the error when the language strings are set to a different format.

Perhaps you can take another look @Fedik or @joomdonation?

Scenario to test:

  • Edit article and save it. Dates will be displaying as d-m-Y H:i:s format.
  • Current: you will get the errors described above
  • After Resolving: Article will save without error, with the date saving as Y-m-d H:i:s but will display as d-m-Y H:i:s
avatar joomdonation
joomdonation - comment - 29 Nov 2021

@particthistle It is a problem with the language package. All you need to do is changing DATE_FORMAT_FILTER_DATETIME to the right value:


Currently, it is :


and that's the reason causing the error.

avatar particthistle
particthistle - comment - 29 Nov 2021

@joomdonation I know that is the reason for the current error. But that error is only caused by the code not being able to convert the date successfully into other formats.

The ability to change the date format to d-m-Y or m-d-Y for display purposes is a preference that users should have available to them.

With this breaking when the string is changed, the error is in the code doing the conversion of the dates - not the date strings themselves.

avatar brianteeman
brianteeman - comment - 29 Nov 2021

@particthistle Quite correct. There would be no point in having the date as a translatable string if it can't be changed

avatar joomdonation
joomdonation - comment - 30 Nov 2021

@particthistle @brianteeman We have two language strings here

DATE_FORMAT_CALENDAR_DATETIME : This is the format used by the our calendar form field to show the selected date in the format to end-users
DATE_FORMAT_FILTER_DATETIME: This is the format used by our PHP code to convert the value from calendar form field to a DateTime object before changing that value to Y-m-d H:i:s format and store into database. Think about this second language string as a helper format to help PHP code

So the format is translatable , but DATE_FORMAT_FILTER_DATETIME depends on DATE_FORMAT_CALENDAR_DATETIME. When you change DATE_FORMAT_CALENDAR_DATETIME in a language, you need to provide equivalent value for DATE_FORMAT_FILTER_DATETIME, too.

avatar Fedik
Fedik - comment - 30 Nov 2021

@joomdonation is correct.

The ability to change the date format to d-m-Y or m-d-Y for display purposes is a preference that users should have available to them.

If User changing DATE_FORMAT_CALENDAR_DATETIME, then he/she also should change DATE_FORMAT_FILTER_DATETIME. They both must be in sync.

The problem that we cannot magically guess in which format User enter the date, and another problem that the Calendar and PHP uses different date format "style".

If the field does not have translateformat attribute or it is translateformat="false" then the calendar will not use this constants.
But it does not guarantee that php DateTime will correctly handle the entered date.

That what we have currently.

avatar particthistle
particthistle - comment - 2 Dec 2021

So the pairings should look like this to show d-m-Y and d-m-Y H:i:s respectively?

avatar joomdonation
joomdonation - comment - 2 Dec 2021

Yes, that's right.

avatar brianteeman
brianteeman - comment - 7 Dec 2021

Is this issue now resolved?

avatar toivo
toivo - comment - 7 Dec 2021

Seems to be fixed now. Just installed en-AU version, created an article as en-AU and updated the article all right.

This comment was created with the J!Tracker Application at

avatar alikon alikon - change - 8 Dec 2021
Status New Closed
Closed_Date 0000-00-00 00:00:00 2021-12-08 06:05:18
Closed_By alikon
avatar alikon alikon - close - 8 Dec 2021
avatar alikon
alikon - comment - 8 Dec 2021

thanks for reporting

avatar particthistle
particthistle - comment - 9 Dec 2021

On a side not, @joomdonation feedback is not currently documented anywhere that I can find.

Please add "Documentation required" label, and that will allow it to be picked up in a documentation project sweep later on.

avatar toivo toivo - change - 9 Dec 2021
[4.0][en-AU] 0 Call to a member function format() on bool when updating article in en-AU
[4.0][en-AU][Documentation Required] 0 Call to a member function format() on bool when updating article in en-AU
avatar toivo toivo - edited - 9 Dec 2021
avatar toivo
toivo - comment - 9 Dec 2021

Labels could not be changed but I added [Documentation Required} to the title.

This comment was created with the J!Tracker Application at

avatar Quy Quy - change - 9 Dec 2021
Labels Added: Documentation Required
avatar Quy Quy - labeled - 9 Dec 2021

Add a Comment

Login with GitHub to post a comment