eZ Community » Forums » Suggestions » Workaround for installations without...
expandshrink

Workaround for installations without phpcli

Workaround for installations without phpcli

Thursday 08 July 2004 4:11:04 am - 18 replies

The site point article "Command Line - Part 1" By Harry Fuecks
http://www.sitepoint.com/article/php-command-line-1/
details a method of using the phpcgi executable in the same mode as the cli interface.

See http://www.sitepoint.com/article/php-command-line-1/3 under the "Compatibility" section.

"As I mentioned earlier in this article, it's possible to use the PHP CGI binary in more or less the same way as the CLI binary, but some additional "tweaking" is needed. Some of these changes are best made at runtime by including an additional PHP script. Others need to be made either in php.ini itself, or by passing additional arguments to the PHP binary."

We use redhat that doesn't come with the CLI binary so it's pain for our sysadmin to have to recomplie php just to get the cli binary.

I've added Harrys' code to the kernel/classes/ezscript.php file and have used this to run the update scripts successfully.

Would the ezPublish crew consider adding this to the code base? It would certianally make things much easier for those without the cli binary installed.
See http://ez.no/community/bug_reports/patch_for_systems_without_phpcli for a patch

Cheers
Bruce

Modified on Thursday 08 July 2004 4:14:19 am by Bruce Morrison

Wednesday 21 July 2004 2:11:24 am

If you use this workaround some parts of eZ will simply not work!

Maybe were are able to determin at some point what works and what doesn't.

I notices troules with the php include() function.

It does not work right when you call a script from a subdir e.g.

tests/testunits.php eztempalte

Wednesday 21 July 2004 10:17:21 am

> If you use this workaround some parts of eZ will simply not work!

Can you be a bit more specific as to what didn't work for you?

This change should not effect the actual running of the site itself. As far as I am aware the patched file is ony used for the update and cronjob scripts (stuff that is run from the command line blunk.gif Emoticon

> I notices troules with the php include() function.
> It does not work right when you call a script from a subdir e.g.

Is't this because you need to run all the scripts from the top ezpublish directory and with the -C flag, e.g.

 php -C update/common/scripts/updatexmltext.php

Maybe this is something phpCLI takes care of.

I've been using this patch with both 3.4.0 & 3.4.1 on a number of sites for both the update and cron scripts for a number of weeks now without issue.

Happy to help sort out any problems with this.

Anyone aware why the main linux distributions don't come with the cli version of php?
(edited above to clarify which distributions)
Cheers
Bruce http://www.designit.com.au/

Modified on Thursday 22 July 2004 10:36:34 am by Bruce Morrison

Wednesday 21 July 2004 1:34:45 pm

>Can you be a bit more specific as to what didn't work for you?

Basicly it the thing i noticed was about the current working directory.

Ok, I have to say that may saying "some things simply do not work" it not correct in the sense.

The cli executes in a certain way and sets the enviroment just right. (cwdir, headers)

To simulate this you need to turn some switches for a non cli version. (like -C,-q and maybe others)

So in general it is just easier to have the CLI when working with comandline scripts, because you cannot forget to set some flags that may lead to unwanted errors.

I guess most users are not aware when to set which flag. They might start bug reporting and having issues that came up because they execute php a certain. With the cli you simply do not have this issue.

From what I have heard from eZ is that they to not plan to make the commando line scripts avialable under sapi. I agree with them, because with that they do not run into the issues from above.

Also the fact you meantioned about cli is not shipped with php distribution is not right. I was able to find the cli in the windows and linux package of php.

Under windows the cli is under e.g. C:\php\cli\php.exe and under linux you have to run a extra command when building php somehting like "install cli-php"

Thursday 22 July 2004 1:21:12 am

Hi Björn

> So in general it is just easier to have the CLI when working with comandline scripts, because you cannot forget to set some
> flags that may lead to unwanted errors.

I agree with you 100%. Unfortinually there are hosting environments where the cli interface is not availiable (there have been posting about this in the forums). This patch allows those people to run their cronjobs and update scripts ( as long as they use the correct flags blunk.gif Emoticon

> Also the fact you meantioned about cli is not shipped with php distribution is not right. I was able
> to find the cli in the windows and linux package of php.

Sorry, I was not as clear as I could have been here. By distributions I was refering to the packaged php that comes with many linux distributions not the php source. Many of the major distributions (Fedora, RedHat Enterprise Linux - I'm sure there are others) do not ship with phpcli. Hopefully these packages will start to include phpcli in the future.

Apparently the installers supplied by eZ don't even include it: See http://ez.no/community/news/ez_publish_3_4_1_release/cli_interface

The patch enables another option. So in order of preference the options for running cronjobs and update scripts are:
1) phpcli, use it if you have it;
2) recompile php to get it if possible
3) Use the patch (with the right flags)

As far as support goes the change to force the use the phpcli has generated quite a few queries in the fourms.

Cheers
Bruce http://www.designit.com.au

Modified on Thursday 22 July 2004 1:31:47 am by Bruce Morrison

Thursday 22 July 2004 4:14:06 am

>1) phpcli, use it if you have it;
>2) recompile php to get it if possible
>3) Use the patch (with the right flags)

Yes this should be the order. I would highly point out in your patch that not using the should be the last option.

Maybe eZ should have a flag for forcing the cli mode for eZScript. Default is then "enabled".

Maybe you can create a nice diff and contribute it.

Interesting to know would be also if we can read the startup flags (-C ,q , or else) to determine if php got started right under sapi.

Thursday 22 July 2004 10:26:06 am

Hi Björn

> I would highly point out in your patch that not using the should be the last option.

I'm not sure the value of this? People who have found the patch probably don't have the cli binary. The thread is titled "Workaround for installations without phpcli" is that not enough?

> Maybe eZ should have a flag for forcing the cli mode for eZScript. Default is then "enabled".

The patched code (cli compatability) is only run if the cli version is not detected. I'm not sure of the point of the flag?

> Maybe you can create a nice diff and contribute it

Haven't I alrady done this in the bug report?

> Interesting to know would be also if we can read the startup flags (-C ,q , or else) to determine if php got
> started right under sapi.

It seems to me that if you use the patch or phpcli then you need to use the -C flag? The documentation on the ez site for running the update scripts and the ezpublish.cron seem to indicate that you do (This means that with the patch you run the scripts just as you would if you had the cli version). (edit: http://au2.php.net/features.commandline indicates that the -C flag is _NOT_ required for the phpcli as "It does not change the working directory to that of the script. (-C and --no-chdir switches kept for compatibility)"blunk.gif Emoticon

So the patch does not provide a direct replacement for the cli version. But running the script from the top diectory of ez Publsih with the -C flag will execute the scripts.

The -q flag is not essential as it only suppresses in the http headers.

The responce from eZ to the patch was pretty clear (it won't be included).

I submitted the patch to help out those people who don't have access to phpcli, it works for me, so if people want to use it then they are welcome to (thats why I posted it in the first place!). I'm happy to help those who have trouble with it.

I'm not sure how relevant this discussion is to the wider community, so if you want to continue I'm happy to take it off line <brucem@designit.com.au>

Cheers
Bruce http://www.designit.com.au

Modified on Thursday 22 July 2004 10:55:54 am by Bruce Morrison

Friday 23 July 2004 11:02:58 am

Ok lets stop the discussion for now, I was just throwing ideas around.

Wednesday 18 August 2004 5:38:03 pm

first we have to define an rss feed or a workflow for testing purpose.

for example

1)login to the admin of the ez
2)goto the setup tab
3)choose RSS from advanced on the left menu (Advanced is an expandable menu just click on it

to see the RSS and workflow)

4)now choose to import an rss
5) in the form enter the following

-title:New Rss (just a name)
-URL:http://ez.no/rss/feed/blog

-Destination path: / ez publish (or just browse to choose any node to put the RSS under it)
-never mind about the objects owner it's just a test RSS
-now choose which class do you want the RSS objects to be treated like (just to reflect the

template organization I suppose you choose (((Article))))

*now choose Article from the Class
*now click update
*now choose the title attribute of the Article to be the title of the RSS
*now choose the Intro attribute of the Article to be the URL of the RSS
*now choose the Body attribute of the Article to be the Description of the RSS

-make sure the RSS is activated (the Active check box is checked)

Now setup the PHP-Cli

read the article at
http://au2.php.net/features.commandline

download this
http://au2.php.net/get/php-4.3.8.tar.gz/from/a/mirror

chang to the place where I downloaded the file

execute the following to extract the file

gzip -d -c php-4.3.8.tar.gz | tar xvf -

then run

cd php-4.3.8

then run

./configure --prefix=/usr/local/php-cli --disable-cgi

then run

make

then run

make install-cli

then run

cd /path where ez is installed (e.g. cd /var/www/html/ez)

then run

/usr/local/php-cli/bin/php runcronjobs.php

<b>
Have fun!!

Mohammad Aboali
Egypt

(arabic comment)

Wa Al Hamdo Lellahe Rabe Al Alameen

</b>

Monday 03 January 2005 10:48:33 pm

Hi all,

Some people might be interested to know that I got the cli/cgi thing working to some extent just by excluding the line

exit(1)

in the file ezscript.php. This is the file where the patch should be included.
If anything, the cronjob now checks all the links and imports RSS feeds.

Including the patch returned a parse error in line 1111 of ezscript.php. And that script only has 1110 lines. More to the point:

-------------------------
Content-type: text/html
X-Powered-By: PHP/4.3.10

<br />
<b>Parse error</b>: parse error, unexpected $ in <b>/home/eyeondevelop/www/ezp/kernel/classes/ezscript.php</b> on line <b>1111</b><br />
---------------------------

Hope someone finds this useful,

Babak Fakhamzadeh

Tuesday 04 January 2005 1:18:24 am

the one is working great for me even though I know i should not use it happy.gif Emoticon

http://pubsvn.ez.no/community/trunk/kernel/classes/ezscript.php

for 3.4

Tuesday 04 January 2005 6:11:28 am

Björn,

It seems to work well for me, too. Can you tell my why you think you should not use it? Should I be wary using this on a high-traffic live site?

Thanks
Mark

Tuesday 04 January 2005 8:04:37 pm

Because it is against the idea of using the cli...

Futher more Derick said once the results could be relatively unpredictable and of couse the cli is different. Still I did not find any errors.

Thursday 14 April 2005 12:31:05 pm

Hi guys,

Are there any modifications available to http://pubsvn.ez.no/community/trunk/kernel/classes/ezscript.php in order for it to work with 3.5?

I currently get the following error:

<br />
<b>Fatal error</b>: Call to undefined function: isshellexecution() in <b>/home/naturno/public_html/mittnettsted/kernel/classes/ezscript.php</b> on line <b>188</b><br />

Thursday 14 April 2005 1:48:44 pm

Never mind, I fetched ezscript.php from trunk and added the AlwaysLog INI setting, and now it seems to be working.

Thursday 23 June 2005 12:02:54 am

I have exactly the same problem (no cli for php), so i got ezscript.php from trunk...
The runcrons.php script still don't work:
errors:
Warning: in_array(): Wrong datatype for second argument in /home/.../www/kernel/classes/ezscript.php on line 1116 (4 times)

Killed

i know this error is due to a log process
but i cant figure out what exactly means
> added the AlwaysLog INI setting

I also add AlwaysLog in debug.ini (override) with the value 'enabled', is that ok?

Could you tell me what value you set, an if you got same type of error?

Friday 16 December 2005 2:21:53 am

Ta for the modified ezscript.php code.

Installing it fixed manual cron job execution on my Fedora Core 4 eZ script 3.6.1 platform.

Tuesday 20 December 2005 10:56:52 pm

http://pubsvn.ez.no/community/trunk/kernel/classes/

Guys I added a diff file for you this might be easier to read

Tuesday 29 May 2007 12:17:34 am

Hey,

I had the same issue a while ago and found this post that solved the problem for me:

http://syn.ac/tech/13/creating-php-cronjobs-without-cron-and-php-cli/

It enables you to do cronjobs with php without even using phpcli. You just use the normal php module.

Greets,

Phpdev0r.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from