Backup task breaks any site by replacing settings.php with version working only with Apache

Can I get some more information? / an example?

It only reverts the settings.php back to being cloaked if cloaking was previously enabled.

If cloaking was not enabled at all, it won't re-cloak.

It of course assumes cloaking, because that is TRUE by default.

So it will only ignore all that if you had cloaking turned off in your drushrc.php

I can't see where I've gone wrong, staring at the code.

It also doesn't make sense why would this only break nginx? I did a LOT of testing on Apache.

But I trust you! So do let me know what you find.

I still don't follow.

It's enabled by default, and has been for a long time.

that's why the code says 'if (drush_get_option('provision_db_cloaking', TRUE)'

eg: 'if it's enabled, and if it's not been set, then consider it enabled'

You have to set '$options['provision_db_cloaking'] = FALSE;' in your drushrc.php for it to consider this 'off' and not cloak.

This is by design

But if you didn't have it set in your drushrc.php, your settings.php *must* have been cloaked already, so that is why I'm confused by what you mean.

Maybe what you're saying is that nginx bypasses the cloaking altogether.

If that's the case, then nginx should also patch the drushrc.php to inject '$options['provision_db_cloaking'] = FALSE' into every site drushrc.php, in my opinion

(the alternative is to have the backup task check whether nginx or apache is in use, and i don't think that's the correct way to do it. If nginx is a special case, nginx should make a special exception) (Edit: that said, I don't know how to do that)

Right, so it means I was right in #7. (bypasses it completely).

I'll look into how to force cloaking off in nginx. i still think making a clause in the backup task itself is wrong

Got a patch ready, standby..

Please test. (reverify the nginx sites. 'provision_db_cloaking' should be then set to FALSE in the drushrc.php)

Hold up on that, sorry.

I don't like the idea of injecting FALSE into the drushrc.php (what if the site gets migrated to an apache server, then its credentials are exposed).

I'll have another patch shortly.

new patch! sorry again.

Now we load whether cloaking is enabled or disabled based on the service, but we don't write anything to the drushrc.php, that's smarter I think.

It now matches the way the settings.php is written on verifies, installs etc.

And another patch, I was on crack with that service check

This one *has* to work, cloaked is TRUE or FALSE here, simple as that :)

Wow ok. Totally not what I'm seeing.

Can you make sure that $options['provision_db_cloaking'] = false; it injected earlier is removed? and try another backup.

I guess if it still doesn't help I'll just revert this one, despite the fact I can't reproduce.

Yep so I think I basically just screwed you over with the earlier patch.

If you don't mind, please run a couple more tests until you're confident with it, I don't want to commit it and mess you up again

Now I am seeing weird results too.

If I edit the drushrc.php and put false, and backup, it rewrites the settings.php with cloaked.

If i edit the drushrc.php, and put false, and VERIFY, and backup, it leaves them uncloaked.

so a verify is required in between. weird

I have definitely broken it for Apache unless I verify first. I don't understand what difference the verify makes, so I'm just going to revert this.

You can keep the patch in yours I guess.

Sorry, another migression out of a migression

  // Check if we are currently cloaking credentials
  $cloaked = d()->service('http')->cloaked_db_creds();
  $cloaked = drush_get_option('provision_db_cloaking', $cloaked);
  dlm($cloaked);
  if ($cloaked) {
    drush_set_option('cloaking_off_temp', TRUE);
    // Disable the cloaking of credentials temporarily
    drush_log(dt("Temporarily uncloaking database credentials for backup"));
    drush_set_option('provision_db_cloaking', FALSE);

    // Write the uncloaked credentials to the settings.php
    _provision_drupal_create_settings_file();
  }

Where that dlm is, it should return false here because $options['provision_db_cloaking'] = FALSE; is in the drushrc.php of the site.

But it returns true, as if it doesn't care, or because the default is TRUE (apache), it overrides that. that is not how I understand drush_get_option to work.

you say it isn't the same for you but earlier in #16 you said you continued to try and backup the site you were testing with and it kept writing the cloaks. I believe you also encountered this here, that's the same issue. (it only started working for you on new sites).

The point is that I *should* be able to fetch drush_set_option from the site context and see it's false, but it returns true.

it returned false before, so it should still.

I wonder if it doesn't like the two definitions of $cloaked. I just don't know what to believe anymore :)

Oh!

I just realised why this is occurring.

If you :

1) install site
2) set provision_db_cloaking off in the settings.php
3) backup site

I thought it was *re-cloaking* the settings.php here, but in fact it works: it sees the drushrc saying 'we don't cloak!' and so it completely ignores the settings.php and doesn't rewrite it. It leaves it as it is: and it is still cloaked because it was cloaked on install (default = TRUE in apache service)

So I think it's the correct behaviour. It can only assume what drushrc says matches what the site is (if it says its false, it ought to assume the settings.php is uncloaked and not tamper with it).

Thats why a verify helped: the settings.php got rewritten on verify to match what was in the drushrc. I thought from thereon that the backup worked as normal, but it's the same story again: saw that it's not meant to be cloaked, so didn't tamper with the settings.php

with such a setting as cloaking, if you are setting it to false in the drushrc, you *must* reverify the site to apply that change (otherwise what's the point), and then you'll see correct behaviour.

So I was wrong about being wrong (!). I'll commit that fix.

Mig

Edit: removed, I am on crack and keep being wrong about being wrong.

Avoiding the computer for a while..

Yes I ended up making the backup logic the same as that.

All good I think. Sigh