Cron Job didnt't process the file

-- HikaShop version -- : 4.7.5
-- Joomla version -- : 4.4.0
-- PHP version -- : 8
-- Error-message(debug-mod must be tuned on) -- : no error

Hi,
since we migrated our Shop on Joomla4 the processing of our ERP CSV is not working anymore. The Cron Job is triggered but didn't process the CSV. We tried all possible version how to enter the filename

• /2rs/uploadhika/bestandsupdate.csv (whereas the 2rs the Joomla root is)
• /kunden/homepages/22/d853227768/htdocs/2rs/uploadhika/bestandsupdate.csv (absolute path of our IONOS Webspace)
• /uploadhika/bestandsupdate.csv

but it is never working. We also don't received a status that the file is missing or was proceed (like in the past

HikaShop Cron ausgelöst am 2023-09-07 23:45
---- Details ----
Import of CSV file www.url.de//uploadhika/bestandsupdate.csv successful
Deleting file www.url.de//uploadhika/bestandsupdate.csv after import )

Any idea what can be the issue or how we need to enter the data ?

thanks Markus

Hi,

How do you know that the cron is triggered if you don't get the reports like before ?

Here is what I recommend:
- Make sure that the cron task itself is working: www.hikashop.com/support/documentation/5...cron-task.html#check
- Reduce the cron frequency in the HikaShop configuration and in the settings of the plugin to 1 second and manually call the URL of the cron task in your browser. That way, you'll directly see the report on your browser. If there is an error you should see it there.
If there is a blank page, then it's likely a fatal error, and your server/website is configured to not display them. Turn on the "debug" and "error reporting" settings of the Joomla configuration and try again to get the error message to show up. That should help in understanding what's going on.

Hi Nicolas,
thanks again for your help.
Really really strange. After setting the time out to 1 sec and triggering the cron manually the systems showed me that the the file wasn't found and with this info it was easy to correct the plugin settings to And the next manual cron trigger processed the file as expected and in the log and in the mail I received a perfect status For whatever reason the hikashop is not able to delete the file (but that's from the beginning) so I deleted the CSV via my script and uploaded a new version of the CSV.
Since that moment the system behave exactly like before. The 15 min and the manual cron trigger purely results in the info that the Cron was triggered with no further details even not my "Markus was here" which I added to the sourcecode

******************************************************************************************************************************************************
******************** 2023-10-21 14:13 ********************
HikaShop Cron ausgelöst am 2023-10-21 14:13

******************************************************************************************************************************************************
******************** 2023-10-21 14:22 ********************
HikaShop Cron ausgelöst am 2023-10-21 14:22

******************************************************************************************************************************************************
******************** 2023-10-21 14:23 ********************
HikaShop Cron ausgelöst am 2023-10-21 14:23

******************************************************************************************************************************************************
******************** 2023-10-21 14:23 ********************
HikaShop Cron ausgelöst am 2023-10-21 14:23

No information in the logs. Any idea?

thanks and best regards
Markus

Hi,

This indicates that the cron runs, but that the plugin doesn't think it should run itself due to the frequency configured in its settings. So I would recommend checking these.

For the plugin not deleting the file, it's probably a permission issue. The PHP user is not allowed to delete the file based on the permissions of the file. This happens often, especially when files are uploaded via FTP. The file owner would be the FTP server unix user, and the PHP unix user wouldn't be able to delete it unless the permissions of the file would be changed.

Hi,
thanks for the swift reply. And you're right the. In the plugin the Frequency is set to 86400 !!! But that value was never changed. No clue where the value is coming from. So I changed it to 900 to be in align with the 15 min. I'll keep you posted if this is changing the behavour.
One additional question regarding the Plugin. The 'Last Update' is set to 1697975528. Any idea what that means?

thanks
Markus

Hi,
that was the issue. The 86400 was daily (and I guess that's your default value). My assumption was that the script is running (and doing something) every 15 min. Due to the fact that I need to delete the input file later on via a scheduled script the availability of the input file and the cron were out of sync.

To fix it I will let the Cron run every 15 min and delete the file like in th past!

Thanks and like always an amazing customer support

Best regards
Markus

Hi,

Great !

Note that the last update setting contains the unix timestamp of the last time the plugin was run:
www.epochconverter.com/
That way, it knows when it should run next.