When I try to create a download through the site, I get error message:
Save failed with the following error: Incorrect datetime value: '-0001-11-30 00:00:00' for column 'modified' at row 1
I presume this is the same error as that reported in "Joomla 5 Error when adding a download from the site"
https://www.jdownloads.com/forum/index.php?topic=14136.msg50456#msg50456.
Versions are: Joomla! 4.2.6; jDownloads 4.0.36; PHP 8.1.26; MySQL 5.7.44.
Templates: standard Cassiopeia and Atum
Site: originally Joomla! 3.10.11 with jDownloads Version 3.9.8.4. Joomla updated to 4.2.6 with jDownloads disabled. jDownloads updated later by following relevant parts of "Upgrading from jD3.9 to jD4"
https://www.jdownloads.net/documentation/getting-started-v3-9/upgrading-from-jd3-9-to-jd4. Settings are default (I think).
Hi
Yes this is the same error as that reported in "Joomla 5 Error when adding a download from the site".
Just for clarity were you adding Download from:
(1)Frontend, (2)Backend using'Check Download Area', (3)Using the Backend 'Files' or (4) directly in the Backend Downloads 'New' button ?
Colin
I was adding from the frontend.
The files (I tried more than once) were uploaded and are shown by 'Check Download Area' to be in the correct jdownloads sub-folder. (They are also shown by Plesk's File Manager.) They are not shown anywhere else in the backend.
I can successfully add a file from the backend using either Backend 'Files:Upload Files' or the Backend Downloads 'New' button.
Are there any other checks I could make that would be useful?
John
Hi,
could I get access to your backend and to your database?
If so, send the data via PM.
By the way, I could not reproduce your problem here. Just like the other error report you mentioned. Perhaps the data field has not been converted correctly?
Hi,
I confirm same mistake: jDownloads 4.0.39 and Joomla 4.4.2
I can add Downloads from Backend. But in Frontend my Users face this error after upgrade to J4 and jD 4 . I have to ask them to send their Download to me.
Hi,
thanks for the info.
Did you also have this approach?
QuoteSite: originally Joomla! 3.10.11 with jDownloads Version 3.9.8.4. Joomla updated to 4.2.6 with jDownloads disabled. jDownloads updated later by following relevant parts of "Upgrading from jD3.9 to jD4" https://www.jdownloads.net/documentation/getting-started-v3-9/upgrading-from-jd3-9-to-jd4.
Hi Arno,
yes I disabled jDwonloads before I did the upgrade from Joomla 3.10 to 4.4. Afterwards I installed jDownloads 4.0.36 and now updated to 4.0.39 .
Hi
Just for clarity, when you say you disabled jDownloads does that mean you only disabled jDownloads 3.9 System Plugin?
Colin
Hi,
no I disabled every single jDownloads extension before Upgrade.
Hi,
what I understand is that jDwonloads tries to save a new Download where modified is NULL and tries to enter this nonsense date. Table __jdwnloads_files does not allow NULL nor this artificial '-0001-11-30 00:00:00' modified date. Therefore MYSQL reports this error.
My proposal: Allow NULL as modified date and use that for new downloads_files.
Okay Arno,
I think I found the solution. You have defined field modified as required and NOT NULL in table. Now you must also fill it with something when you create a new Download. But you only fill it on existing Downloads while editing.
Add a line in administrator/components/com_jdownloads/src/Table/DownloadTable.php to also fill modified with today's date. I listed 2lines before and after so that you can easily find it.
// fill out created date field
$this->created = Factory::getDate()->toSql();
$this->modified = Factory::getDate()->toSql();
if (!$this->created_by){
// we use only automaticly the user ID when the user list is not listed in the form (this is selectable in the jD User Groups Settings)
Quote from: Florian on 17.01.2024 17:59:16Okay Arno,
I think I found the solution. You have defined field modified as required and NOT NULL in table. Now you must also fill it with something when you create a new Download. But you only fill it on existing Downloads while editing.
Add a line in administrator/components/com_jdownloads/src/Table/DownloadTable.php to also fill modified with today's date. I listed 2lines before and after so that you can easily find it.
// fill out created date field
$this->created = Factory::getDate()->toSql();
$this->modified = Factory::getDate()->toSql();
if (!$this->created_by){
// we use only automaticly the user ID when the user list is not listed in the form (this is selectable in the jD User Groups Settings)
Thank you very much! It helped!
Hi Rivan,
great that I could be of help.
Arno must decide whether he wants to allow empty (NULL) modified date or wants to set it to day of creation as he does in Admin backend. That is exactly what my patch does.
I would find it more logical to allow NULL in database field "modified" and change backend tso that it also leaves modified date empty with new downloads.
Hi Florian,
sorry for the delay. Unfortunately, I have not been able to spend the time I actually needed for jDownloads and support in the last few weeks. And then I also had to migrate the website to Joomla 4. But I hope to have more time next week.
I'll probably implement your fix, but I'll have another look at it. Thank you!
[Fixed in 4.0.40, coming soon]
I have now tested it again here with the latest version 4.0.39 and cannot reproduce this error. Are you sure you are using the latest files (and table definitions)?
I have tested it with two different user group settings:
- with activated form field modified
- without display of form field modified
The field is checked in DownloadTable.php from line 1430 in store() function:
// Set modified to created date if not set
if (!(int) $this->modified)
{
$this->modified = $this->created;
}
// Set modified_by to created_by user if not set
if (empty($this->modified_by))
{
$this->modified_by = $this->created_by;
}
Hi Arno,
I had jD 3.9.8.4 active when I disabled EVERY jD Extension and finally upgraded to J 4.4 (not sure about sub no.). Then I installed jD 4.0.36 and later upgraded to jD 4.0.39 .
Field modified has following definition in MariDB
type = datetime
NULL = NO
default = 0000-00-00 00:00:00
Maybe that helps you to identify which database version I have. Anyhow it seems that I am not the only one who had this issue. It worked fine from backend and when I analyzed table I found out that it would create a field modified with today's data as modified date. That is when I understood that there must be an issue with empty modifed when storing from frontend.
Hi Arno,
I also checked whether I have your code lines at line 1432 (as I have 2 lines more with my patch). And yes I can confirm. But something happens in form handling anyway. Remember that PHP refuses to store a strange date "-0001:11:30" . Your code would not find that if form returns a non-zero and !Null value.
QuoteField modified has following definition in MariDB
type = datetime
NULL = NO
default = 0000-00-00 00:00:00
It should be with jDownloads 4:
modified` datetime NOT NULL,There are no more definitions of this type in install.mysql.utf8.sql:
default = 0000-00-00 00:00:00And even after an upgrade from 3.9.x, all tables should have been corrected accordingly.
However, something may have gone wrong here. Please take a look at the installation logs of jDownloads. Control Panel or /administrator/logs/com_jdownloads_install_logs.php
Hi Arno,
I checked the Log in Backend and the file administrator/logs/com_jdownloads_install_logs.php is attached here. I told that I have just recently upgraded to J4 and follwoing to also jD4 . All jD4 extensions were disabled during installation of J4.
#
#<?php die('Forbidden.'); ?>
#Date: 2024-01-12 09:44:48 UTC
#Software: Joomla! 4.4.1 Stable [ Pamoja ] 28-November-2023 16:00 GMT
#Fields: date time priority message
2024-01-12 09:44:48 INFO ------------------------------------------------------ System Information
2024-01-12 09:44:48 INFO OS : Linux d
2024-01-12 09:44:48 INFO PHP : 8.2.9
2024-01-12 09:44:48 INFO MySQL : 10.6.12-MariaDB-0ubuntu0.22.04.1-log
2024-01-12 09:44:48 INFO Joomla! : 4.4.1
2024-01-12 09:44:48 INFO Debug : 1
2024-01-12 09:44:48 INFO Debug Language :
2024-01-12 09:44:48 INFO Error Reporting : default
2024-01-12 09:44:48 INFO SEF : 1
2024-01-12 09:44:48 INFO Unicode Aliases :
2024-01-12 09:44:48 INFO System Cache : 0
2024-01-12 09:44:48 INFO Captcha : hcaptcha
2024-01-12 09:44:48 INFO ------------------------------------------------------ Update Started
2024-01-12 09:44:48 INFO Update started by user Super User (412). Old version is 4.0.36. New version is 4.0.39 Stable.
2024-01-12 09:44:49 INFO Modules succesfully installed/updated: 12.
2024-01-12 09:44:49 INFO Plugins succesfully installed/updated: 6.
2024-01-12 09:44:49 INFO Wrong values successfully corrected in jdownloads_files `publish_down` field.
2024-01-12 09:44:49 INFO ------------------------------------------------------ Update Finished
Hi Volker,
too bad, I actually need the log from the 3.x to 4 upgrade.
I still suspect errors in your jDownloads tables. The only thing that will help is a manual comparison with the file in question or a 'fresh' jDownloads installation.
Perhaps I should add a small check routine when starting the jD backend for the first time, so that the admin can then point out faulty tables. I am already aware that the corrections during the upgrade process do not run smoothly for some users (but probably only very few). However, it was difficult to reproduce the problem. It could possibly be due to overly restrictive DB settings.
Hi Arno,
shall I dump table structures of jDownloads and attach here or send to you via email?
I tried to reply a few days ago, but could not as the verification failed (many times).
I was trying to say that Florian's fix works for me.
If it would be helpful, I am happy to provide a dump of anything.
John
Quote from: Florian on 23.01.2024 11:51:22Hi Arno,
shall I dump table structures of jDownloads and attach here or send to you via email?
It would also work as a PM attachment.
Quote from: jononorvic on 23.01.2024 14:37:44I tried to reply a few days ago, but could not as the verification failed (many times).
I was trying to say that Florian's fix works for me.
If it would be helpful, I am happy to provide a dump of anything.
John
Thanks John, but if you had the same problem, it seems that your jDownloads tables are not up to date either. I will therefore have to integrate a check in one of the next versions.
I have now had a closer look at the recent posts and have made a small change. First, I removed Florian's mod; the error returned. Then I changed the default setting for the column "modified" in table "ne6_jdownloads_files" from "0000-00-00 00:00:00" to "None". I can now add downloads from the front end without error.
The log from the upgrade is:-
#
#<?php die('Forbidden.'); ?>
#Date: 2023-12-18 22:03:35 UTC
#Software: Joomla! 4.2.6 Stable [ Uaminifu ] 13-December-2022 15:00 GMT
#Fields: date time priority message
2023-12-18 22:03:35 INFO ------------------------------------------------------ System Information
2023-12-18 22:03:35 INFO OS : Linux c
2023-12-18 22:03:35 INFO PHP : 8.1.26
2023-12-18 22:03:35 INFO MySQL : 5.7.44
2023-12-18 22:03:35 INFO Joomla! : 4.2.6
2023-12-18 22:03:35 INFO Debug :
2023-12-18 22:03:35 INFO Debug Language :
2023-12-18 22:03:35 INFO Error Reporting : default
2023-12-18 22:03:35 INFO SEF : 1
2023-12-18 22:03:35 INFO Unicode Aliases :
2023-12-18 22:03:35 INFO System Cache : 0
2023-12-18 22:03:35 INFO Captcha : 0
2023-12-18 22:03:35 INFO ------------------------------------------------------ Update Started
2023-12-18 22:03:35 INFO Update started by user John Cooper (994). Old version is 3.9.8.5. New version is 4.0.36 Stable.
2023-12-18 22:03:36 INFO Modules succesfully installed/updated: 12.
2023-12-18 22:03:36 INFO Plugins succesfully installed/updated: 6.
2023-12-18 22:03:37 INFO Wrong values successfully corrected in jdownloads_files `publish_down` field.
2023-12-18 22:03:37 INFO ------------------------------------------------------ Update Finished
I will also PM a dump of the table.
In "install.mysql.utf8.sql", column "created" is also defined with default "None", but in the "ne6_jdownloads_files" table structure has default "0000-00-00 00:00:00". Should that also be changed? Are you aware of any other columns (and tables) that might have the same problem and cause errors?
Thanks for your help. Let me know if anything else would be useful.
John
QuoteIn "install.mysql.utf8.sql", column "created" is also defined with default "None", but in the "ne6_jdownloads_files" table structure has default "0000-00-00 00:00:00". Should that also be changed? Are you aware of any other columns (and tables) that might have the same problem and cause errors?
Thanks for your help. Let me know if anything else would be useful.
Yes. All the tables should have after the Upgrade to jDownloads 4 not longer a datetime field with 'default "0000-00-00 00:00:00"
Use the install.mysql.utf8.sql file as a reference.
Only 'datetime NOT NULL' or 'datetime NULL DEFAULT NULL' is still used.
Normally this is checked with a special function during the upgrade and corrected if necessary. But this does not seem to have worked one hundred per cent for all users.
Thanks. I will now update the live site. It has slightly different hosting, so I will see if that suffers from the problem.
John
Hi Arno,
I have thought about this subject and I conclude
1. Field __jdownloads_files.modified should be set to have no default value . I noticed that HTMLHelper creates this strange date "-0001-11-30 00:53:28" from "0000-00-00 00:00:00" default value.
2. I also recommend to set NULL to YES on this field. When you create a new download file, it is logical that it has no modified date. A modified date and modified by user should in my eyes only be set when you really modify an already existing download.
3. That should also be the case when doing the new upload in admin backend. So modied and modified_by shoudl be empty on NEW files
I will do an update of my tables so that I do not need this fix by setting DEFAULT to NULL and allow NULL manually
Of course you can do that for yourself. I have adopted the structure of the Joomla articles and saw no absolute necessity for a different structure. There are currently no plans to make any further changes.