Bootstrapping drupal not working with Quicksilver? about quicksilver-examples

I fully bootstrapped Drupal in a similar fashion (https://github.com/pantheon-systems/quicksilver-examples/pull/13/files). I wonder what your pantheon.yml file looks like and where it is located relative to the Drupal root?

[danshumaker]

My pantheon.yml file is in the drupal root as required. I am able to run other quicksilver examples like after code syncs and database clones that post to slack.

I see in your example you bootstrap drupal to FULL and I was only bootstrapping to DATABASE, so I tried bootstrapping to FULL and that still didn't work.

here is my pantheon.yml file

api_version: 1

workflows:
  deploy:
    after:
      - type: webphp
        description: post to slack after each deploy
        script: private/scripts/slack_deploy_notification.php
  # Notify team of new commit to master
  sync_code:
    after:
      - type: webphp # we are told there will be more
        description: post to slack after each code pushed
        script: private/scripts/slack_sync_notification.php
  # Notify, sanitize,and notify on db clone
  clone_database:
    before:
      - type: webphp
        description: post to slack before cloning the database
        script: private/scripts/slack_before_db_clone.php
    after:
      - type: webphp
        description: Environment DEBUGGING
        script: private/scripts/debug.php
      - type: webphp
        description: Empty solr authorization
        script: private/scripts/solr_deauth_post_db_clone.php

The debug.php script runs fine.

[bmackinney]

@danshumaker, I spoke with @greg-1-anderson and we think the errors you're seeing may be resolved by changing directory to the Drupal Root, as in @Gfriedman21's example.

chdir(DRUPAL_ROOT);

before

drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL)

[danshumaker]

Tried that today and it didn't work. Still get same error. I can send you the workflow id if you want or I can put it in the pantheon support ticket. It reveals db password so I won't paste it here.

[greg-1-anderson]

Do you have any redirects in your settings.php file, or anything else that might call exit() during bootstrap?

Have you tried #13 with your site, and seen if that works?

[danshumaker]

No redirects used in the settings.php

Of the five lines in the script:

<?php
header('Content-Type: text/plain; charset=UTF-8');
define('DRUPAL_ROOT', $_SERVER['DOCUMENT_ROOT']);
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
 drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

I've put print statements after each line and tested them. All four lines work fine (validated by the prints showing up in the output). It is only on the drupal_bootstrap line 5 that the script then fails and gives the output mentioned in the first comment.

#13 uses the deploy step for bootstrapping and I'm using the clone_database step, I'll switch my debugging script over to the deploy step and see if I can get drupal to bootstrap there.

[danshumaker]

Hi Greg,

I switched my drupal debug script over to the deploy and sync_code steps and neither of them worked. They get the same error as before.

PANTHEON ERROR:

Expected status 200, got: 301 while running your Quicksilver operation.

Please check your script path is correct and try again.

[joshkoenig]

@danshumaker sounds like bootstrapping drupal is resulting in a redirect, probably because of something in settings.php that's there for a good reason for normal web requests, but isn't so good for Quicksilver.

This is one of the challenges with more complex operations vis webphp. I'm sure it can be worked around, but it's also one of the reasons we are keen to offer direct invocation of Drush and WP-CLI.

[danshumaker]

@joshkoenig Thanks for your response. Yes, we do indeed have a bunch of redirects in settings.php that are necessary. @greg-1-anderson , sorry about that, I didn't check my settings.php earlier when I answered you in haste.
What I'd like to do is turn off and on modules depending on the environment. So I could do this manually with drush after each database push but it seems like Quicksilver is a perfect place for this type of thing.
Specifically:
On Prod = turn off devel
On dev/test/multi = turn on devel
On dev = turn on field_ui, views_ui
On Prod = turn off field_ui, views_ui

When you say "direct inovcation of drush" are you saying to do it within php in quicksilver or via my terminal on my laptop?

Thanks again.

[greg-1-anderson]

I'll spill the beans -- I have invocations of Drush working from within a webphp script. Hopefully we will be able deploy this soon. This will help you, because once you call Drush via a simple 'passthru' or 'exec' to Drush, and bootstrapping will just work, provided that you disable your redirects. This is easier when calling your site via exec("drush...") than bootstrapping directly in your webphp script, because php_sapi_name() == "cli" can be used to determine if your site is being loaded from a cli script. This is the typical way that redirects in settings.php are disabled. Unfortunately, it is currently difficult to differentiate between a webphp script and a page load of your site, because the webphp environment has all of the same environment variables set as page requests. We should really set a PANTHEON_QUICKSILVER environment variable, or something of that nature, so that you can differentiate between page requests and Quicksilver calls.

Note that calling a Drush script from the webphp script is not the same as the upcoming "direct invocation" of Drush (from Quicksilver itself, rather than from within a webphp script) that Josh is talking about above. If you call Drush from your webphp script, you are still subject to the 120s timeout, and cannot affect the processing of the operation (e.g. to cancel a code sync if a sanity check fails). Direct execution (withough webphp) is also in the works, but will take longer to deliver than my simple bugfix that allows Drush to be called from within a webphp script.

[danshumaker]

@greg-1-anderson Many thanks for the details. The PANTHEON_QUICKSILVER sounds very appropriate and I could foresee multiple uses for it. I'll hold tight for direct drush invocation, ENV, and/or drush within webphp stuff.

[greg-1-anderson]

You could put putenv(PANTHEON_QUICKSILVER, true); on the first line of your webphp script, and check for that in your settings.php file.

[joshkoenig]

@greg-1-anderson do we have an answer for this now? ;)

[greg-1-anderson]

Yes and no. It is now possible to call drush directly in a Quicksilver webphp script, and it will bootstrap Drupal for you. (The same sort of rework for wp-cli is also underway, but not deployed yet.) However, in the case of this particular error, the bootstrap will still fail in settings.php due to the redirect.

If you bootstrap with drush, you should be able to test php_sapi_name() == "cli" in your settings.php, and subvert any redirects on matches. That should fix things up for you.

[danshumaker]

@greg-1-anderson Thanks Greg and Josh, I'll give that a try asap.

[joshkoenig]

This should be working well now. We have some examples. Thanks for helping us beta test!