views:

63

answers:

2

My usual hosting environment is a dedicated server, however for one project I am required to deploy Symfony onto a Linux shared hosting account.

The project itself works fine, however, when I SSH in to the server the command line does not work as expected.

For example, if I navigate to data/symfony/bin then type:

php symfony 

this returns the list of symfony functions, but not the tasks associated to my plug-ins such as sfLucene.

How do I make the CLI aware of the plug-ins, so that I can run tasks such as rebuilding my sfLucene index?

A: 

Initialise the Symfony application instance at the top of the script you want to run, and stick the stuff you want to do in the script:

require_once('/var/www/domains/yourdomain.com/www/htdocs/config/ProjectConfiguration.class.php');
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);
sfContext::createInstance($configuration);

(change to your own project path)

That's what I use to run Cron jobs or just execute Symfony stuff via CLI.

Does that help?

Tom
This would solve the underlying problem of executing symfony from a cronjob or CLI, but the wider (and more elegant) solution of making the user-defined task available to the CLI remains.
Raise
@Raise: what I had in mind was to run the task from within that script, giving it access to everything it needs.
Tom
@Tom I understand and agree, as this would mimic the old batch/ script approach from symfony 1.0+, but the task should really be available to the CLI without your workaround.
Raise
@Raise... fair enough, I guess it's a bit of hassle to create scripts just to execute other scripts.
Tom
A: 

In the end, I asked my hosts to improve my access so that my scripts would run.

I could then run the default symfony file in the root of the project directory:

php symfony lucene-rebuild
Jon Winstanley