I have installed 3.9 -- first timer here -- and despite the "Time/Date last fired: " times shown for my various jobs the scripts only execute FOR REAL when I click the "Test Path" utility in the Modify view.

I have the HTML script correctly referencing the JobScheduler application with 2 locations. In the footer of the site and in the header of the internal application where users login to a menu. Traffic happens every few minutes all day long into the evening. Time is set at the default 60 minutes.

So, 2 basic problems --

1) Despite Last Time fired indications no scripts execute even though I am using the internal path references that work when I use the "Test Path" utility.2) The View log continues to show my testing executions on June 1, yesterday, but nothing for today.

My times are at daily 2 and 3 hours intervals and of 13 script tasks NONE have executed. I must go to MODIFY for each script and hit the "Test Path" to launch each script manually.

Strict Standards: strftime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/36/d236264054/htdocs/mywebsite/wp-content/themes/twentythirteen/mywebsiteappfolder/include/phpjobscheduler/pjsfiles/functions.php on line 150

In my php.ini I have this, trying to correct for the above error but it is not working to prevent the Error--

date.timezone = "Europe/Berlin"

Can the phpjobscheduler config or constants be set with something that will satisfy the strftime() error?

I just wanted to clear up any errors before switching off Debug mode.the code can be less redundant to just "date_default_timezone_get()", of course! But I was curious to see if this works, and it does. Errors gone.

Now, as for using the absolute url, I am using such paths as ../../../CheckTableQuery_list.php

and ../../../include/14daylieracemails.php for other scripts.

I would think that the Test Path would not even run these scripts if I HAD used "Check'TableQuery_list.php"

But THIS is new! "Also, the "test path" may work for testing but when phpJobScheduler is running on your server the paths will be different."

For the same reason you discuss in one forum reply... the path winds up in directories that are only accessed by the users who have logged in.

I was not using the full path because the Test Path showed me that as long as the phpjobscheduler application was INSIDE the protected folder and file paths it would go directly to the scripts without needing logins.

By your own explanation elsewhere in the forum this was a "solution" that was a viable alternative to trying the absolute path with the username and password method.

And I figured that this was much quicker to execute... not needing to pull up the Login process just to run each script.

"And it does a simple include when you use something like this:"../../scriptFolder/script.php"

In the first instance it needs to authenticate you so it needs a username/password to check (if the folder is protected), in the second instance no authentication is required as the script is running on the local server."

So, I followed your advice..

I thought the Test Path was exactly that... a confirmation that I had this script figured correctly to the relevant file in my folders.

Through the use of the Test Path facility I configured each script that way... if the Test Path arrived at the literal location of each script then I figured I was good to go.

What good is the Test Path utility if it is not THE guide to getting Scripts to run?