-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The core filter module is running updates on config without ensuring config exists first and uses a constant that is not defined at update time. #6729
Comments
I also ran into an issue running I'm amending this PR to include the update for the constant as well. I ran into this again today doing a Drupal 7 core upgrade to Backdrop in the Backdrop summit at BADCamp. I think it's a more critical issue if it happens on every upgrade? |
@jenlampton What other modules were installed on the Drupal 7 site? I cannot replicate the bug on a bare bones D7 site. I'd like to check that your PR fixes it. (I also tried it after installing Rules UI and Entity - for random choices - but still no error.) |
I thought the PR at least would do no harm, but when I run the same D7 db with the PR, I get these errors:
|
I can avoid the previous error if instead of using
I recommend adding this to your PR @jenlampton. I left a comment on the PR. Though I'd still like to know how to reliably replicate your original error, so I can see if this really fixes it. |
Good suggestions @herbdool. Update hooks should only use database queries and config updates; avoiding any module-provided functions which might change in the future (or call hooks or whatnot). |
I've merged both suggested changes. Thank you!
You'd think this would have occurred to me since it was the function call that was causing all the problems. 🤦
I was upgrading a clean install of core / standard profile for the BadCamp presentation, but I ran into it the first time on a Drupal 7 site that was previously running the PHP filter module. Maybe try that? |
I had a friend report the same problem to me on July 18th - but I didn't believe him since I thought the core upgrade path was "well tested".
Why doesn't the core upgrade test catch this problem if it happens on a clean install of D7 standard profile? @herbdool are you also using ddev? I think he and I are both doing the upgrades on ddev. Maybe it has something to do with batching and how the updates are divided across batches? |
Description of the bug
When upgrading from Drupal 7, I am seeing the following fatal error when running
core/update.php
:When proceeding to "the error page" (which is actually the same page), I see the following printed to the screen:
user_role_grant_permissions()
(line 2755 of/var/www/html/docroot/core/modules/user/user.module
).realpath()
: Passing null to parameter#1
($path) of type string is deprecated inBackdropLocalStreamWrapper->getLocalPath()
(line 380 of/var/www/html/docroot/core/includes/stream_wrappers.inc
).#1001
infilter.module
. All errors have been logged. You may need to check the watchdog database table manually.When I return to
core/update.php
and attempt to update again, I can see that User module is about to run update 1008, and Filter module is about to run 1001, so the failure happened at 1007/1000.The second time I run the update, everything completes with no issue.
Update 1001 in filter.module calls
user_update_1007()
.BACKDROP_AUTHENTICATED_ROLE
is hard-coded toauthenticated
, but the role name is not changed toauthenticated
untiluser_update_1007()
.I think the simplest solution would be to add an implementation of
hook_update_dependencies()
to ensure that this filter update only runs after roles have been converted to configuration, and renamed.Steps To Reproduce
Upgrade from Drupal 7
Actual behavior
Fatal errors
Expected behavior
No fatal errors
Additional information
Add any other information that could help, such as:
The text was updated successfully, but these errors were encountered: