Cronjob gives 404 Page not found

[PvN94]

I'm trying to set up a cronjob, and to test I first just want to send a simple email (containing the message "Test") to myself. So I created the task, and when running it from the back-end it runs fine and sends the message. When trying to run it from the front-end (using ?fabrik_cron=1) I get Joomla's 404 Page not found page.
I activated the Scheduled Task plugin, updated through Joomla and through github, and the problem persists.
Any idea on what might be the problem here?

 

[troester]

Can't replicate, check your complete URL.

 

[PvN94]

What is there to check in the complete URL?? It's just the homepage with ?fabrik_cron=1 appended.

I did just notice that while the page says 404 page not found, the page title is 1064 - Error: 1064, so this seems to be some sort of SQL error. I tried reparing the database via Joomla and got it to run without giving an error page once, giving the following info in the logs table: "32,Module 'pcxsession' already loaded,Unknown,0"

 

[troester]

got it to run

So the email was sent from frontend?

 

[PvN94]

No, the email was not sent, but the page opened and a line was created in the logs table giving that error.

In the meantime I tried changing some things and now I still get the error page, but the logs table contains the message "8,Undefined offset: 0,/{site_root}/libraries/joomla/filter/input.php,202" for every time I try to run it.

 

[troester]

Which log table, #_fabrik_log?

 

[PvN94]

Yes

 

[PvN94]

Ok, I've been searching a lot for what may be the problem and I think I found where it is, just don't know what. When trying to run a simple test on a small, near empty list, everything works fine. The problem seems to be that I want to use the Employees list, which has list joins with like 8 other lists and databasejoins to 2 dozen more. Any ideas on what I can do to use the employee list without taking on all the load from the joins and links, as this seems to crash the plugin.

 

[cheesegrits]

The usual way would be to copy your List (select it in the main Lists tab, hit Copy, provide some meaningful names when it asks if you want to rename the list.form/group(s)). Then unpublish everything (groups / elements) you don't need for the cron job on that copy, and set up any pre-filters that make sense (like maybe "mail_sent <> 1", or some date restrictions, etc). And use that copy for the cron job.

Basically when you use the scheduled task system, we don't know what rows you want, so we'll just select everything (subject to pre-filters) and let you sort it out through things like the "email condition". That is obviously not optimal for large tables. So it's up to you to create a version of the list that only selects what you want.

-- hugh

 

[PvN94]

Alright, that works so thanks for that. But now I have the problem that while it should update 18 rows and does so when started manually, it only updates the first 4 rows when started via the url, so I'm guessing it hits the max execution time. I tried upping the php max_execution_time and max_input_time via the .htaccess file, but that's no dice either.

 

[troester]

it only updates the first 4 rows when started via the url

And the next 4 if it's started again? Or only 4 special rows?
Do you have prefilters applied to different access levels? (It's running with the access levels of the logged-in user which may be different if run via frontend).

 

[PvN94]

It's the same 4 every time. I do have prefilters applied, but those are all set to public so they should always be applied. Plus, the prefilters wouldn't result in just the first 4 records (alphabetically) being selected.
Also, after streamlining the php code for the condition I now get the first 7 rows instead of 4.

 

[PvN94]

Even after removing all the conditions and php code for the email body there is still a difference between the manual run and the automatic run. The first updates 14 records and the other just 10. I've been looking all over for settings regarding execution time for pages etc., but can't find anything that works. Any ideas?

 

[cheesegrits]

OK, I see where a change elsewhere in our code has broken how we remove pagination limits from the row selection for cron processing.

I'll be committing a fix to github later today which fixes it, once I've had a chance to test it more.

-- hugh

 

[cheesegrits]

That change is in github now. Check your plugin settings, there should be a "row limit" parameter now, see the tool tip on that.



Sent from my Nexus 7 using Tapatalk

 

[PvN94]

Everything seems to be working now. Thanks for that!