Stcuk with cron email problem

Ah man, I can't believe it's something so stupid! What I really can't figure out is how they showed before though if that was causing them not to show?

Dunno. Nothing has changed in the pre-filtering code, or how we differentiate between raw and not-raw, for at least a year.

Just FYI, I added a "Nobody" access level to your site, which has no groups in it. That's useful for several purposes, including turning pre-filters off when testing (assign them to Nobody). So when you have pre-filter issues in the future, with multiple filters, you can just turn them off one by one till the problem goes away, then you now which one causes the problem. I also enabled "Fabrik debug" so I could append &fabridebug=1 to the list URL and see the actual SQL of the query.

-- hugh
 
About that IP thing, I know with sending through SMTP, I can just use localhost. Does it work the same in this instance? It's Apache on Linux, so I'm positive it must me 127.0.0.1

And this Allowed PDF Localhost solves the access issue right? I can switch it back to Special?

I think I'll need to add that test to a couple of other access test functions. Just remembered the version of that option which extends to allowing list access is in a local branch on my fork, it's not on github. I need to do a little more testing, and commit it to master. I'll get to that in the next day or so.

-- hugh
 
Just FYI, I added a "Nobody" access level to your site, which has no groups in it. That's useful for several purposes, including turning pre-filters off when testing (assign them to Nobody). So when you have pre-filter issues in the future, with multiple filters, you can just turn them off one by one till the problem goes away, then you now which one causes the problem. I also enabled "Fabrik debug" so I could append &fabridebug=1 to the list URL and see the actual SQL of the query.

Thanks for that and thanks for the tips!

I think I'll need to add that test to a couple of other access test functions. Just remembered the version of that option which extends to allowing list access is in a local branch on my fork, it's not on github. I need to do a little more testing, and commit it to master. I'll get to that in the next day or so.

Ok cool, I'll just leave it as is for now then. If my emails still don't go out tomorrow morning when the cron is set to run, then I know, somewhere I must have messed up that access level thing.
 
Hugh, I still seem to be stuck with some of these emails not going out :(

I know, you're probably so sick of hearing about this. It seems my 'leads' list if running, but not the 'retail' list. Everything seems to be public, I double checked the pre-filters, the data is there, what should be raw, is raw, etc etc. But they simply did not go out.

I know I should be using MailChimp for this kind of thing, but as it is a private venture of mine, I'm launching it with minimal capital.
 
I'm still working on finishing off that IP access control stuff, when I'm done I'll let you know, you can update your site, and we'll take it from there.

-- hugh
 
Hi Hugh. I know, I know, you're probably sick and tired of this.

Having gone through every single possible place where my access levels could be preventing my crons from running, I started digging some more. I noticed yesterday that my wget command from my server might be wrong. I had: wget http://www.xxx.com/?fabrik_cron=1234, before that I also had, wget http://www.xxx.com?fabrik_cron=1234 (no slash). Last night I changed it to, wget http://www.xxx.com/index.php?fabrik_cron=1234 and it seems some of them actually went through! So that's a thing.

But, some still did not go through, however, I have discovered a bunch of errors in the Fabrik logs. Some look like they might be serious. Remember, I'm using pre-filters. Check these out:

Code:
2,DateTime::__construct(): Failed to parse time string (NOW()- INTERVAL 16 DAY) at position 3 ((): Unexpected character,/xxxx/xxxx/components/com_fabrik/helpers/parent.php,1875

2,is_file(): open_basedir restriction in effect. File(/media/sliders/js/script.min.js?v=6.3.0) is not within the allowed path(s): (/xxxx/:/tmp/),/xxxx/xxxx/libraries/joomla/filesystem/file.php,630

2048,Only variables should be assigned by reference,/xxxx/xxxx/components/com_fabrik/models/element.php(1289) : eval()'d code,1

8192,Comments starting with '#' are deprecated in Unknown on line 415,/xxxx/xxxx/libraries/joomla/language/language.php,843

That DateTime construct one looks like a problem? Not really sure what the rest mean?
 
The DateTime::__construct() warning is expected. In the date element code, when processing filters, we have to figure out if the specific value is a date string or something else. So we have a helper, isDate(), which checks several ways, including attempting to run it through DateTime() ...

Code:
        try
        {
            $dt = new DateTime($d);
        } catch (Exception $e)
        {
            return false;
        }

... and catching the exception PHP generates if it isn't a parsable date. But if you have PHP's error reporting set high enough, you'll still see the error message generated by that, even though we are catching and handling the exception.

The open_basedir warning is whatever extension is using that sliders JS is trying to use the wrong path, which is triggering the standard PHP open_basedir restriction (that restricts scripts form accessing files outside of the configured root). Wouldn't be affecting anything Fabrik is doing.

The "assigned by reference" error means you have an error in one of your element's evel'ed default values, probably using some old style code like ...

Code:
$db =& JFactory::getDbo();

... or similar, where the & is now deprecated in PHP. It'll still work, for now, until PHP actually starts considering that an error in some future version. Again, you are seeing that deprecated notice because you have the error reporting set high. Although you should find and fix that code, remove the &.

The # comment thing means that one of your language files has a line in it commented out with a # instead of a ;. Again, won't affect anything until PHP decides to actually treat that as an error. So it might be worth figuring out which file it is, although that won't be easy, unless you have an editor which can search for regular expression in the entire Joomla folder.

Bottom line, nothing in any of those warnings which would affect a cron job.

-- hugh
 
Ok cool. Thanks. I'll find that &, I think it might be some code I put in my template's index file that sets a session.

I'm stumped hey. Don't know where else to look for this issue anymore. I checked now and seems the emails didn't go out again this morning, ran them manually. Weird thing is, I receive the notification emails that the crons have run.
 
Hi Hugh. No rush, but was just wondering how development was going on that Allow PDF Localhost option?

Out of interest. I setup a new site, with all lists having default settings. Setup my scheduled tasks on pre-filtered lists and again, emails wouldn't send. Even though, when I log in, I can see the last run date/time being updated plus, I am able to run them manually through the administrator. So I spent some time going through everything, setting the time back a few hours in the last run field and also, if you look at the attached screenshot, I expanded that message field window by grabbing the triangle bottom right and dragging, then putting my cursor in front of 'return', then backspace and enter again to put it back on a new line.

I then saved each task individually again and voila, was able to get the tasks to run through the front end with ?fabrik_cron=task.

I have no idea why this is or what changed? Will see tomorrow if they run on their own now.
 

Attachments

  • a_screenshot_03.jpg
    a_screenshot_03.jpg
    14.9 KB · Views: 138
ok, so wasn't that, they're still not sending. only sends when I run the cron manually. everything is set to public access. suppose it's time to start forking out for a bunch of mailchimp accounts.
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top