Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ParisLiakos’s picture

Status: Active » Needs review
FileSize
3.32 KB
ParisLiakos’s picture

not sure about upgrade path, should i defer to #1921822: Take account of drupal_hash_salt during migration path from 7.x ?

Edit: yeap its in the second point of the issue summary there

Status: Needs review » Needs work

The last submitted patch, drupal-drupal_hash_salt-2036259-1.patch, failed testing.

andypost’s picture

dawehner’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, drupal-drupal_hash_salt-2036259-1.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
536 bytes
3.84 KB

We also need to make the change in install.core.inc, then I think this should be ok.

Status: Needs review » Needs work

The last submitted patch, 2036259-7.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review

#7: 2036259-7.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 2036259-7.patch, failed testing.

damiankloip’s picture

Assigned: Unassigned » chx

Spoke to chx on IRC, we briefly looked into debugging this. There are no real errors in the logs, so at the moment we have no more info than the qa result page...

Assigning to chx at his request - he is going to take a look and see what's going down.

sun’s picture

Assigned: chx » sun
Issue summary: View changes
Status: Needs work » Needs review
Issue tags: +API clean-up
FileSize
5.05 KB

Due to #2171683: Remove all Simpletest overrides and rely on native multi-site functionality instead, this patch should pretty much work as-is now.

Re-rolled against HEAD and converted new code that accesses the global variable.

Status: Needs review » Needs work

The last submitted patch, 12: drupal8.global-hash-salt.12.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
Related issues: +#2176621: Remove global $databases
FileSize
6.94 KB
4.98 KB
  1. Fixed drupal_rewrite_settings() does not import newly written settings into Settings singleton.
  2. Removed the now obsolete/unnecessary 'drupal_' prefix from setting name.
sun’s picture

Status: Needs review » Needs work

The last submitted patch, 14: global.hashsalt.14.patch, failed testing.

sun’s picture

14: global.hashsalt.14.patch queued for re-testing.

ParisLiakos’s picture

Good job, its green!:)

Very minor note:

  1. +++ b/core/includes/install.inc
    @@ -199,8 +200,14 @@ function drupal_rewrite_settings($settings = array(), $settings_file = NULL) {
    +  $settings_settings = array();
    

    maybe we could have a better name for this variable?

sun’s picture

Status: Needs work » Needs review

Heh, yeah, it was very hard to find an accurate variable name in there, because the entire function is about $settings. I considered $new_settings, $settings_variables, $settings_values, but all of those would be even more ambiguous within the scope of that function body. ;)

Thus, the $settings in settings.php are the $settings_settings :-)

ParisLiakos’s picture

heh, yeah:)
Added a draft change notice here:
https://drupal.org/node/2197037

It is good to go imo, but dunno if i can rtbc it

sun’s picture

Any change to move forward here? :-)

This patch contains changes that conflict with #2176621: Remove global $databases, and in turn, the latter contains a fix that currently blocks #1351352: Distribution installation profiles are no longer able to override the early installer screens

alexpott’s picture

Status: Needs review » Reviewed & tested by the community

Looks great - Drupal installs successful with this patch and generates a hash salt in seetings.php as expected.

+++ b/core/includes/bootstrap.inc
@@ -1662,10 +1662,13 @@ function drupal_get_user_timezone() {
+  // This should never happen, as it breaks user logins and many other services.
+  // Therefore, explicitly notify the user (developer) by throwing an exception.
+  if (empty($hash_salt)) {
+    throw new \RuntimeException('Missing $settings[\'hash_salt\'] in settings.php.');
+  }

Nice!

damiankloip’s picture

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

ianthomas_uk’s picture

I have updated the CR to indicate that it is better to use drupal_get_hash_salt() in both D7 and D8, rather than accessing the variable/setting directly.