Look at a phpInfo() and see what php believes is the /tmp dir. In my case, it was /var/lib/php74/tmp
The problem with #11 above was a setting on Cloudflare that was blocking the page from wget or curl.
To fix, use curl to attempt to fetch your drupal site's webhook link. You will see the cloudflare error. Then fiddle with cloudflare settings (rules?) to get cloudflare's security features to cooperate.
Tested with php 8.1.7 and it works.
Curious why you didn't use trim((string) $var) instead? https://stackoverflow.com/questions/71707325/migration-to-php-8-1-how-to...
As of Jan 15, 2024, the latest Beta for D9/10 still causes this WSOD. Here's what I did:
1. Manually download the library:
cd <docroot>/libraries
git clone https://github.com/bshaffer/oauth2-server-php.git
2. Then:
cd oauth2-server-php
git checkout v1.7.0
3. Add the patch above to composer.json:
"patches": {
"drupal/oauth2_server": {
"AuthorizationCodeInterface method signature change for oAuth2 Server": "https://www.drupal.org/files/issues/2023-06-27/11.patch"
}
},
4. composer install should install the patch.
5. drush en oauth2_server
6. drush cr
7. drush updb (I did this just in case. Should throw no oauth2_server errors)
8. Website works with the module enabled!
php 7.4.29
Here's a patch to fix.
index cc0e78c..cfda712 100644
--- a/src/Form/MiniorangeServerMapping.php
+++ b/src/Form/MiniorangeServerMapping.php
@@ -164,7 +164,7 @@ class MiniorangeServerMapping extends FormBase
\Drupal::messenger()->addMessage($this->t('Configurations have been reset successfully.'));
}
- public function createRow($key, $value, $type='', $custom_fields=array(),){
+ public function createRow($key, $value, $type='', $custom_fields=array()){
$config = \Drupal::config('oauth_server_sso.settings');
if($type=='custom' || $type=='constant'){
$row_form['name']= array(
In Mailchimp, on this page: https://us2.admin.mailchimp.com/lists/tools/webhooks-edit?id=[xxxxxxx]
There is a field to enter the webhook url from your drupal site. This url is given on the config drupal page at /admin/config/services/mailchimp. The format of the URL is this:
https://YOURDOMAN.com/mailchimp/webhook/[randomCharactorsOfYourWebhookHa...
When attempting to paste and save the webhook URL from my drupal site into that Mailchip page, Mailchimp complains that:
"We couldn't connect to the specified the URL. Please double check and try again."
When I visit the webhook URL in my browser, it returns a page with only a "0" on it. It does not return an error.
I am out of the woods on this one now. Thanks for the help!
Another technique I used, as I had this problem for every deployment on local, dev, stage, and prod, is to manually download *.zip files of older versions of slick and blazy to your modules dir to temporarily use them to get blazy and slick into sync. In the end, once you have the latest of both, which work together, delete the downloaded directories, cd modules/contrib and then rm -rf both blazy and slick. Then run a composer install so that composer had installed the blazy and slick modules, preventing this from happening to other devs on your team. Then drush cr; drush updb; drush cr.
This happens when you take over a drupal install that hasn't been updated since D8.9!
#4 went well for the dev server. This next day we tried deploying to the stage server. Unfortunately, the same error happened.
Drush updb and any page load returns:
PHP Fatal error: Declaration of Drupal\slick\SlickManagerInterface::build(array $build = Array) must be compatible with Drupal\blazy\BlazyManagerInterface::build(array $build): array in /var/www/html/docroot/modules/contrib/slick/src/SlickManagerInterface.php on line 43
Slick with Blazy are required in composer files of other projects, for example the Thunder distribution. Upgrading within the confines of these other projects that require slick and blazy can create mini "dev storms" due to mismatching of the blazy version and the slick version. Generally, as of Dec. 28, 2023, this procedure will work for installing or upgrading slick and blazy together, as required.
1. Use composer as a tool, don't use it to compose by editing the composer.json file. Run these 2 commands:
composer require drupal/slick:^2.0
composer require drupal/blazy:^2.0
This should match the two projects' versions to each other.
2. Clear the cache, maybe several times. drush cr
3. Run drush updb
4. Run drush cr
5. Repeat as necessary (such as if the drush updb errors out.
6. You can discover what other installed projects or distributions are requiring slick and blazy — along with the version numbers of the requirements — by using the command composer why drupal/slick or composer why drupal/blazy. There may be a reason to open a report in the other project's issue queue should the other project's composer requirements are not allowing a smooth transition to the upgraded paired and compatible versions of Slick and Blazy.
(The above might deserve a place on the home page or somewhere else prominant in that it specifically addresses composer installations. BTW, pointing me to use the ^2.0 versions for each composer require fixed my problem. IDK why because both slick and blazy are on the same versios as before... Or maybe it fixed itself. Thanks!)
Found a workaround solution for disabling a badly behaving simple_oauth module.
1. Try drush pmu simple_oauth
2. If it complains of 'field secret' try running a drush core-cron to urge Drupal to purge that field
3. If core-cron doesn't work, look in the database for a simple_oauth_field__[random characters] with the 'secret' as the only item inside the table and then drop that table.
4. Try to run drush pmu simple_oauth again.
5. If it still will not uninstall because of a crazy error, it's time to remove it manually with this mysql commande:
6 run in mysql delete from key_value where collection='system.schema' and name='simple_oauth';
7. drush cex to export the deletion of simple_oauth from the db config to the sync yaml files
8. Look for simple_oauth tables in the db and drop them (I didn't have any as the uninstall had removed them, thus making it impossible to get a clean drush pmu on subsequent attempts.
9. You're done!
Upgrading another site from 8.9 to 9.4 and this problem still persists. Where is the field "secret"? Queues have been purged; cron has been run.
I get stuck again and again on this problem. New day, new site upgrade with commerce_license.
Either:
drush cr</drush> or <code>drush updb results in incomplete updb or the cr crashes with this error notice:
ArgumentCountError: Too few arguments to function Drupal\commerce_license\LicenseOrderProcessorMultiples::__construct(), 0 passed and exactly 3 expected in Drupal\commerce_license\LicenseOrderProcessorMultiples->__construct() (line 64 of /var/www/web/stage/docroot/modules/contrib/commerce_license/src/LicenseOrderProcessorMultiples.php) #0 [internal function]: Drupal\commerce_license\LicenseOrderProcessorMultiples->__construct()
I have also truncated cache_ tables trough PhpMyAdmin.
When upgrading from 9.1.2 to 9.3.22 received this error caused by page_manager when attempting drush updb.
PHP Fatal error: Declaration of Drupal\page_manager\Entity\Page::getContexts() must be compatible with Drupal\page_manager\PageInterface::getContexts
Applying this patch at #17 solved the issue.
(I am in Drupal upgrade prison with a large site. Hopefully this will get indexed into Google and help any others in same boat).
Let's re-open. I am getting same problem.
When uninstalling simple_oauth from browser UI:
Drupal\Core\Entity\EntityStorageException: The field secret has already been deleted and it is in the process of being purged. in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->onFieldStorageDefinitionDelete() (line 762 of /var/www/sanangelolive.com/prod/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php).
When drush pmu simple_oauth:
(event *=) $ drush pmu simple_oauth
In SqlContentEntityStorageSchema.php line 762:
The field secret has already been deleted and it is in the process of being purged.
Regarding #4 - An upgrade to D9.3.0 fixed everything.
#12 works with D9.3.22. It also solved my page_manager problem related to contexts and controllers matching.
The blazy.svg file.repositiory error is also stopping the drush updb for all of the Drupal 9.2 site:
shell$ drush updb
Do you wish to run the specified pending updates? (yes/no) [yes]:
> yes
> [notice] Update started: blazy_post_update_schema_formatter_grid_int_to_string
> [error] The "blazy.svg" service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead.
> [error] Update failed: blazy_post_update_schema_formatter_grid_int_to_string
[error] Update aborted by: blazy_post_update_schema_formatter_grid_int_to_string
[error] Finished performing updates.
I just upgraded from D8.9 to 9.2.* and have the same problem:
shell$ drush cr
The service "blazy.svg" has a dependency on a non-existent service "file.repository".
I have commented out the "file.repository" on the blazy.info.yml to try to get beyond this until I land on D9.5 (incrementally upgrading 9.1... 9.2... )because of these issues! Right now I am at 9.2.x. The issue emerged from the upgrade from 8.9 to 9.0.
More ideas to solve (I had a pesky commerce_product entity not found problem that took 2 days to figure out).
1. Look for instances of "commerce_product" (or known entity name) in your installation with grep.
From the top directory of the Drupal installation (web or docroot or whatever you called it)
grep -inRsH 'commerce_product' .
Look at any theme or *.theme file that has the offending entity. Look at modules or custom modules that require or reference it. Edit the code and get rid if it!
2. Look through your *./config/sync directory or search it grep -inRsH 'commerce_product' . looking for the field.
3. What I found was a config that made the flag module require it. Ended up solving by wiping out the config and drush pmu flag.
4. drush cim is your friend. Edit the *./config/sync directory and drush cim to make it live on your site!
5. Delete or truncate the contents of the key_value database table as needed.
6. drush cr a bunch!
7. See if you can configure using Sequel Pro on MacOS to speed the database stuff up.
8. If you delete something out of the serialized array inside the config table, remember that the first number at the beginning of that god awful string of poop is the number of modules installed. You have to also change that number (de-increment or make it be less than the original number in accordance with how many modules you deleted from the serialized array.)
9. load the original database in a second DB on the same server. You can switch back and forth looking at the original DB content (or export it easily using Sequel Pro).
10. Don't tell me what I did wrong. I am tired of developer-centric egos. I have a business to run and lose money running down dev ops rabbit holes. These ideas will help many solve this problem even it it isn't "the correct way."