Hi Sandra,
This is the result:
bridgese@chi-node4 [~]# php -r ‘echo php_sapi_name()."
";’
cli
Hope this error can help?
PHP Fatal error: require(): Failed opening required ‘/home/bxxxxxx/public_html/mxxxxxxxxx/cli/home/bxxxxxx/public_html/mxxxxxxxxxx/config.php’ (include_path=‘.:/opt/alt/php70/usr/share/pear’) in /home/bxxxxxxx/public_html/mxxxxxxxxxx/cli/userAdmin_statusCheckAndFix.php on line 22
Hmm, this part: ‘/home/bxxxxxx/public_html/mxxxxxxxxx/cli/home/bxxxxxx/public_html/mxxxxxxxxxx/config.php’ looks like the cwd is being added twice, did you mention earlier in the thread you edited the script to add to the require getcwd()` line? I think something is amiss with the absolute path
Perhaps restore those lines to the original require getcwd().‘/…/config.php’; otherwise try <code class="CodeInline">require '/home/bxxxxxx/public_html/mxxxxxxxxx/config.php';
btw that change/revert would apply to all three of the require’s, lines 20-22
Hi,
I reverted to the original file for the three lines as suggested and tried the config as seen below:
require getcwd().‘/home/bxxxxxxx/public_html/mxxxxxxxxxxx/config.php’;
require getcwd().‘/home/bxxxxxxx/public_html/mxxxxxxxxxx/functions.php’;
require getcwd().‘/home/bxxxxxxx/public_html/mxxxxxxxxxxxxx/lib/PHPMailer/PHPMailerAutoload.php’;
but I am still getting this message: This script cannot be run from a browser, only via CLI
Just to clarify (because we’re several posts in and it’s easy to miss something), when you see that message is it from the command line, or through a web browser? It will always return that message when used from a web browser because it’s preventing non-command line access.
The getcwd() function will add the current directory to the path, which is where the duplication came from in the previous post. Either using the original code or removing it should be sufficient:
`require getcwd().'/../config.php'; require getcwd().'/../functions.php'; require getcwd().'/../lib/PHPMailer/PHPMailerAutoload.php';` ````require '/home/bxxxxxxx/public_html/mxxxxxxxxxxx/config.php'; require '/home/bxxxxxxx/public_html/mxxxxxxxxxx/functions.php'; require '/home/bxxxxxxx/public_html/mxxxxxxxxxxxxx/lib/PHPMailer/PHPMailerAutoload.php';` ``` Hope this helps!
Thanks for your reply.
The message comes from the Cron email i set up to notify me when the Cron runs with an output. It comes to my personal gmail address.
I set up the following schedule in the cron: 15 13 * * *
using this command cd /home/bxxxxxx/public_html/mxxxxxxxxxxx/cli/ ; php userAdmin_statusCheckAndFix.php
I tried running the task firstly with the original codes and then with the others but they both produced the same message in the Cron mail: This script cannot be run from a browser, only via CLI.
There are no notifications or action in Gibbon that a Cli was performed for the expected users. So their status remain the same.
Willpro, Sandra touched on this, but I will try and add more detail. The “This script cannot be run from a browser, only via CLI.” error occurs when the following PHP code fails:
if (php_sapi_name() != ‘cli’)
This is featured near the top of each of the CLI scripts. It ensures that scripts cannot be run through the browser, which means that members of the public cannot run your CLI scripts by finding out the address.
I wonder, as your environment does not seem to be returning ‘cli’ if you can find out what php_sapi_name() is returning?
Ross
Willpro, Sandra and I were just discussing this, and it seems the best approach would be to add the following to one of your scripts, immediately above the if (php_sapi_name() != ‘cli’) section noted above:
error_log(‘CronIssue’.php_sapi_name());
Then allow the script to run via cron before checking your error log to fish out the result. The label ‘CronIssue’ will help you locate the error in the log file.
We will then find out what value is being returned for this.
Ross
This is the result using:
require getcwd().‘/…/config.php’;
require getcwd().‘/…/functions.php’;
require getcwd().‘/…/lib/PHPMailer/PHPMailerAutoload.php’;
[21-May-2017 14:13:01 UTC] PHP Notice: Undefined index: SERVER_PORT in /home/bxxxxxx/public_html/mxxxxxxxxx/src/Gibbon/core.php on line 244
[21-May-2017 14:13:01 UTC] PHP Notice: Undefined index: SERVER_PORT in /home/bxxxxxxx/public_html/mxxxxxxxxxxx/src/Gibbon/core.php on line 244
[21-May-2017 14:13:01 UTC] PHP Notice: Undefined index: SERVER_NAME in /home/bxxxxxxx/public_html/mxxxxxxxxxx/src/Gibbon/core.php on line 246
[21-May-2017 09:13:01 America/Jamaica] CronIssuecgi-fcgi
Looks like the mystery is nearly solved! cgi-fcgi is certainly a different output than the standard server would give, but it would appear it’s still a valid output for servers running php with FastCGI.
I’ve attached an updated copy of userAdmin_statusCheckAndFix.php with line 47 changed (unzip & replace the original).
This should let your cron task run without issue, and continue to prevent web access to keep the script secure. If that works we can update the rest of the scripts, and you’ve helped us fix an obscure issue in the codebase 
Thanks for your reply.
Unfortunately I am getting the same message from Cron mail:This script cannot be run from a browser, only via CLI. and the same error : CronIssuecgi-fcgi
Okay, here’s one more, this one has the full battery of CLI checks. If it doesn’t work I’m not sure what will …
Sorry about all the back and forth to figure this out, it’s an unusual enough case that it’s not something I can test from this end.
Hi Sandra, it worked 
yeh! Only one small issue , when the cli runs the students who were set to their “expected” start date were return to “full” at the start of the school calendar year and not the expected date.
Hi Willpro,
Glad to hear it’s working! I’m not sure I follow the error you’re having, are you able to elaborate? I took a quick look at the script, the logic is something like: If the student is Expected and the current date is past their Start Date, set them to Full. Are you seeing something different happen?
Hi Thanks,
The start date sets them to full ok, but not at the required start date. E.g. They are some students who didn’t start school until January 9 2017. This is their expected start date.
However when the CLI runs, they are set to full but at September 5, 2016 (start of the school term) which is incorrect.
Hmm, that’s odd. The script doesn’t change start dates, just the student status. If their start date was January 9 2017 (set when editing their user) it should remain the same date, and their status is Full. The rest of Gibbon will handle whether or not to display them in class lists based on their start date. On which pages are you seeing the dates changed back to September?
I had initially enrolled them in their form group and when updating the attendance by form group i noticed these students didn’t actually appear in the school’s register until in January. I set their start date to “expected” in January so has not to mark them as absent during the 3 mths from Sept. to December. When the cli run it should now turn their “expected” date to “full.” in January
The “Expected” and “Full” are just statuses, the date itself is controlled through the User Admin > Edit User:
Correct. I did that. They show the “expected” start date on that date which is correct when viewing their student’s profile and their attendance report.
So although they are starting in January, taking attendance by form group, the class shows an extra amount of students in the form who should not really be there until January. I am just wondering if it was because i had inadvertently enrolled them in the form group prior to seeing their actual “expected” date ?