Resolved Setting up cron job

If the text from the cron.php doesn't show up, it means that the double dash is not accepted, something you already found out. According to the PHP manual it should be usable. Something must have been configured on the server not to allow it I think.

Yes. I need some way to print the content of variables either to a file or back to the command line. I just noticed that when you run '# /usr/bin/php -f /home/domain/public_html/administrator/components/com_csvi/helper/cron.php --help' the help text comes from cron itself, and not from csvi's cron.php. I did the check by adding some text in the if ($help) clause in the function doExecute() in cron.php, this text did not show up.

if ($help)

		{

			$this->out(JText::_('COM_CSVI_CRON_HELP'));

			$this->out('=========Kommer från cron.php=========');

			$this->out();

			$this->out(JText::_('COM_CSVI_USE_CRON'));

			$this->out();

		}

Hello,

I will try to add this, although it is a core file I'll be hacking.

Once it is working, you could contribute it to the project. So it won't be a core hack anymore

Are there more places where the cli.php resides?

There is only one CLI input file. You may need to trace where it goes through, if it doesn't show anything.

Tried this, in the file '/public_html/libraries/joomla/input/cli.php'

$arg = $argv[$i];

			// Sn 15-11-06: handle input from cron command line which does not accept the -- at start of argument

			$txt = print_r($arg,true);

			echo $txt;

			if (substr($arg, 0, 4) === 'csvi')

			{

				$eqPos = strpos($arg, '=');

				$key = substr($arg, 4, $eqPos - 4);

				$value = substr($arg, $eqPos + 1);

				$out[$key] = $value;

				$txt = print_r($out,true);

				$mf2 = fopen("/home/livingstudio/public_html/administrator/components/com_csvi/helper/testfile2.txt", "w");

				fwrite($mf2, $txt);

				fclose($mf2);

			}

			else

...but it does not produce anything. Are there more places where the cli.php resides?

Looking at the Joomla code, the arguments passed are being parsed based on the ==.

There it is, the treatment of the $_SERVER['argv'] values. As there is no way to make the cron command line to accept the double dashes, there is a need of this script being able to handle parameters without them. I can pass parameters like

root@vps [~]# /usr/bin/php -f /home/domain/public_html/administrator/components/com_csvi/helper/test.php key=key### template_id=5

and they get into the $_SERVER['argv'] array, look like:
Array
(
[0] => /home/domain/public_html/administrator/components/com_csvi/helper/test.php
[1] => key=key###
[2] => template_id=5
), so I will have to see if there needs to be another conditional clause to handle such input, ie split the array values on the "=" sign and assign $out[$key] = $value; from that. It ought to be there already, but as it does not work, I will try to add this, although it is a core file I'll be hacking.

Makes me wonder if it could be possible to escape the dashes in som way.

I have no idea. I doubt it though. What I am more curious about is why it is an issue on your system. You are not the first one to use the cron script

Looking at the Joomla code, the arguments passed are being parsed based on the ==.

Akeeba works perfectly. I believe that the problem is in the cron command line, which would not accept parameters with any dashes, only when they begin with any other legal character. Makes me wonder if it could be possible to escape the dashes in som way.

I don't know if you are a user of Akeeba Backup, this very popular backup extension for Joomla also has CLI scripts for running backups. Their CLI scripts also require the double dash as explained in their documentation.

In your case this wouldn't work either I think, which does make your setup a little different from the rest.

Your idea is something you can try for sure.

Now I'll test another idea: a small php file which assigns the values from the cron command the way Joomla CLI wants them before calling the cron.php file... Just a :silly: idea.

To see if arguments get passed from the command line the defaukt way, I wrote a little test.php file:

$txt = "arguments given: " . $argc . "\n";

$txt .= print_r($argv,true);

$mf = fopen("testfile.txt", "w");

fwrite($mf, $txt);

fclose($mf);

When run like this:

/usr/bin/php -f /home/domain/public_html/administrator/components/com_csvi/helper/test.php key### 5

it produced a text file with this content:

arguments given: 3

Array

(

    [0] => /home/domain/public_html/administrator/components/com_csvi/helper/test.php

    [1] => key###

    [2] => 5

)

So this way works. The same file run with double dashes:

root@vps [~]# /usr/bin/php -f /home/domain/public_html/administrator/components/com_csvi/helper/test.php --key=key### --template_id=5

produced an error message, and the usage instructions:

Error in argument 3, char 2: no argument for option -

Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]

       php <file> [args...]

  -a               Run interactively

  -b <addressort>|<port> Bind Path for external FASTCGI Server mode

  -C               Do not chdir to the script's directory

  -c <path>|<file> Look for php.ini file in this directory

  -n               No php.ini file will be used

and exactly the same with single dashes.

So I an sorry to say, but double dashes don't work in the command, at least in my configuration.

That is then something related to your configuration. Would it work if you use a single dash?

If you have a look at this explanation, you will see we use the single and double dash. This is from a tutorial on how to build a Joomla CLI application.

The $this->input->get('h') code is looking for a -h flag on the command line. This is a boolean condition - it’s either there or it’s not. This is usually referred to as the short form of a command line argument.

The $this->input->get('help') code is looking for a --help option. This is the long form of a command line argument and it can actually take a value. For example, if you used the following on command line:

$ php -f tagaliser -- --help=now
then $this->input->get('help') would return the value “now”.

(source)

The only thing I notice in the article that he has -- after the filename. Notice he doesn't use the -f switch either

there is a "silent fail", ie. the php script gets called, but there is no output.

Nothing happens as no arguments seem to be passed.

Thank you for the information that prices with tax are calculated, it led me in the right direction on where to look for the culprit. It turned out, that products with shopper groups were excluded from the calculation. A backup of the table first, and then TRUNCATE TABLE `prefix_virtuemart_product_shoppergroups` solved this problem.

As for the problem with passing the key and template_id this happens in the cron command, before it gets to the cron.php file:

Error in argument 3, char 2: no argument for option -

Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]

       php <file> [args...]

  -a               Run interactively

  -b <addressort>|<port> Bind Path for external FASTCGI Server mode

  -C               Do not chdir to the script's directory

  -c <path>|<file> Look for php.ini file in this directory ...

The second char is the second dash, and then follows the help file with the usage instructions. So I don't think the call reches the script at all.
If I remove the dashes, and put either key=### or just the key, and the same for the template name, there is a "silent fail", ie. the php script gets called, but there is no output. Nether is there any mail.
So I an sorry to say, but double dashes don't work in the command, at least in my configuration.

Hello,

I'm sorry, but I don't really understand "...a not to the cron job article", is there something new that I could read?

It is a typing mistake, it should be note

From what I have read in other forums about passing parameters to php scripts through cron, they should be written as just the value, no dashes and no variable name, thus not like --key="####" but only ####

That is not how the Joomla CLI works.

As for your other problem, you need to open a new thread please unless your question is whether they are taken or calculated. I can tell you that they are calculated by VirtueMart. The only price stored is the base price, every other price is calculated from that.

Hi rolandd,

I'm sorry, but I don't really understand "...a not to the cron job article", is there something new that I could read?

I noticed another thing, the parameter --help is correctly interpreted and sent to cron.php - or would this be built-in in cron? From what I have read in other forums about passing parameters to php scripts through cron, they should be written as just the value, no dashes and no variable name, thus not like --key="####" but only #### and then they need to be taken care of in the php script from the argv array, in the order they were given in the command ($key = argv[1]; and so on, argv[0] being the path to the cron.php script itself).

I have another problem too, it is about which database table the values for "basepricewithtax" (Virtuemart product export) are taken, or wheter they are calculated. For this I probably need to open another thread.

Thanks for the feedback, it is appreciated. I have added a note to the cron job article.

:laugh:
Wow!

Found the error! The command needs the flag -f between the path to php and the path to /[...]/helpers/cron.php to make it run. Yes, when I got it running, I saw it in the help file that came in the mail... -f for parse and execute.

Nope. The command to get the help file runs just fine, but the export command throws this error message:
Error in argument 3, char 2: no argument for option -
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]... etc.
Quite close now, though.

So it seems like the cron daemon is interpreting the parameters meant for csvi as options to itself, the double dash before key (--key) is split into a dash for option and the second as argument, which is "illegal". So passing the variables to the php script this way does not seem to work on the present configuration: CENTOS 6.7 x86_64, Apache/2.4.16 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4, and:
Default PHP Version (.php files) 5
PHP 5 Handler suphp
Apache suEXEC on
Apache Ruid2 off

Installed Packages
cronie.x86_64 1.4.4-15.el6

Hello,

After changing the email setting I got this in my inbox from the cron daemon:

X-Powered-By: PHP/5.4.45

Set-Cookie: 56e0941d45fa9d1c05b076d061f96ef5=2df5108c941a8c2b5f8c9db2a618b47c; path=/; secure; HttpOnly

Content-type: text/html; charset=utf-8

Not much for a help file, is it?
Actually, the result is the same as when I ran the command in the console. It does not say anything to me. Could the problem be something abount privileges to run php scripts? I could try to put the command in the root's cron file, or maybe, if there is, Apache's?

Hello,

If you run the command from the console, you should see it in the console. When running it as a cron job, the server usually mails the cron output to the given email address set in the cron page.

Hi, where would I see the output, the help screen? Should I run this in the console?

Hello,

Ok, that looks like a good PHP.

Let's see if you get any output at all. If you run the job as

/usr/bin/php /home/xxxuserxxx/public_html/administrator/components/com_csvi/helper/cron.php --help

do you get the help screen?