Drupal issueshttps://lab.civicrm.org/dev/drupal/-/issues2024-02-22T16:59:37Zhttps://lab.civicrm.org/dev/drupal/-/issues/194Recent Items block on the non-CiviCRM pages will have a missing CRM JS error2024-02-22T16:59:37ZherbdoolRecent Items block on the non-CiviCRM pages will have a missing CRM JS errorWe've got a site where the Recent Items block is on a non-CiviCRM page. It seems to work but there's a JS error of the `CRM` object is missing. I had put `\CRM_Core_Resources::singleton()->addCoreResources();` in a custom event subscribe...We've got a site where the Recent Items block is on a non-CiviCRM page. It seems to work but there's a JS error of the `CRM` object is missing. I had put `\CRM_Core_Resources::singleton()->addCoreResources();` in a custom event subscriber but that no longer plays nice with CiviCRM core. So perhaps adding it to the `CivicrmBlock` plugin class would be better. It seems that Drupal can't assume that the block will have everything loaded. In my testing, adding it in `__construct()` after `$civicrm->initialize();` works.5.72.0https://lab.civicrm.org/dev/drupal/-/issues/186drupal 9: Create User Record action crashes if using first+last+email as unsu...2023-07-05T23:49:05ZDaveDdrupal 9: Create User Record action crashes if using first+last+email as unsupervised ruleSee https://civicrm.stackexchange.com/questions/44841/create-user-record-action-on-a-contact-summary-page-throws-error-is-this-a-bug
Putting as regression for now but not completely sure.
Doesn't happen in drupal 7.See https://civicrm.stackexchange.com/questions/44841/create-user-record-action-on-a-contact-summary-page-throws-error-is-this-a-bug
Putting as regression for now but not completely sure.
Doesn't happen in drupal 7.5.63.0https://lab.civicrm.org/dev/drupal/-/issues/181Error: Trying to access array offset on value of type null in Drupal\civicrm\...2022-08-05T00:42:28ZherbdoolError: Trying to access array offset on value of type null in Drupal\civicrm\Plugin\Block\CivicrmBlock->build### Error:
> Notice: Trying to access array offset on value of type null in Drupal\civicrm\Plugin\Block\CivicrmBlock->build() (line 57 of modules/contrib/civicrm/src/Plugin/Block/CivicrmBlock.php).
### How to recreate
1. Add the block...### Error:
> Notice: Trying to access array offset on value of type null in Drupal\civicrm\Plugin\Block\CivicrmBlock->build() (line 57 of modules/contrib/civicrm/src/Plugin/Block/CivicrmBlock.php).
### How to recreate
1. Add the block Recent Items to a blocks layout. I don't think it matters if it's the front or admin side. And this may be an issue with other blocks too.
2. Log in as a user *without* the `access CiviCRM` permission and visit a page where that block is supposed to appear.
### Background
`CivicrmBlock::build()` has this line `$content = \CRM_Core_Block::getContent($block_id)['content'];`. But `getContent()` can return `NULL` (despite it claiming it only returns arrays). It'll return NULL if various access checks fail.
### What should happen
`CivicrmBlock::build()` should first check the result is an array before trying to access an offset.
```
/**
* {@inheritdoc}
*/
public function build() {
$block_id = $this->getDerivativeId();
$content = \CRM_Core_Block::getContent($block_id);
// Bypass Drupal SafeString escaping by setting output as already escaped.
if (!empty($content['content']) {
return [
'#markup' => Markup::create($content['content']),
'#cache' => ['max-age' => 0],
];
}
return [];
}
```5.53.0https://lab.civicrm.org/dev/drupal/-/issues/179KCFinder on D9: You don't have permissions to browse server.2022-08-12T05:14:07ZSandor SemseyKCFinder on D9: You don't have permissions to browse server.## Overview
The issue is very similar to this one:
https://civicrm.stackexchange.com/questions/41023/cannot-upload-images-using-ckeditor-on-message-template-after-5-45-upgrade
and the proposed workaround is solving it (reverting [this...## Overview
The issue is very similar to this one:
https://civicrm.stackexchange.com/questions/41023/cannot-upload-images-using-ckeditor-on-message-template-after-5-45-upgrade
and the proposed workaround is solving it (reverting [this](https://github.com/civicrm/civicrm-packages/commit/0bb407782b810c32a81e0ad42af67a435b44c845) commit), but I think the root cause is different.
**Steps to reproduce**
1. Use CKEditor4 as Wysiwig Editor
1. Create Event
1. Insert image to description
1. Try to browse, or upload image
1. Error: You don't have permissions to browse server.
## Analysis
In my case classes are found, so it's not namespacing. After some debugging, I think the following happens:
1. In `civicrm/packages/kcfinder/integration/civicrm.php` Drupal is bootstrapped, user authenticated and correct `KCFINDER` params are added to the `$_SESSION` var:
```
$_SESSION['KCFINDER']['disabled'] = false;
$_SESSION['KCFINDER']['uploadURL'] = $config->imageUploadURL;
$_SESSION['KCFINDER']['uploadDir'] = $config->imageUploadDir;
```
1. Then in `\kcfinder\uploader::construct()` session ID is requested from Drupal (`\CRM_Core_Config::singleton()->userSystem->getSessionId()`)
1. Eventually `Drupal\Core\Session\SessionManager::start()` finds no session so starts a new one, thus removing `KCFINDER` array from `$_SESSION`. This way kcfinder defaults are used, which is to disable access.
So I thought it's a cookie issue (though `$_COOKIE` was populated with all the cookies all the way through).
I changed `CRM_Utils_System_Drupal8::loadBootStrap()` to pass cookies to the Symfony request:
```
$request = new \Symfony\Component\HttpFoundation\Request([], [], [], $_COOKIE, [], $_SERVER);
```
This way session was found in step 3 above, it was restored, but it also didn't contained the `KCFINDER` array as `$_SESSION` was overwritten by restoring.
So I'm stuck here, probably I'm missing something obvious, but currently I can't see why should it behave differently.
Has anybody any idea?
**Drupal: 9.3.12**
**Civi: 5.47.4**
## UPDATE
Relevant issues in other repos:
https://lab.civicrm.org/dev/core/-/issues/3419#note_74113
https://lab.civicrm.org/dev/civicrm-asset-plugin/-/issues/45.51.0https://lab.civicrm.org/dev/drupal/-/issues/174Change message so it doesn't say Drupal8 on Drupal9 site2022-09-20T22:27:16ZJoeMurrayChange message so it doesn't say Drupal8 on Drupal9 siteThere was a message today on page for Synchronize Users to Contacts (/civicrm/admin/synchuser:
Synchronize Drupal8 Users
This was on a Drupal9 site, and the client got concerned about what they were running.
Please adjust the message s...There was a message today on page for Synchronize Users to Contacts (/civicrm/admin/synchuser:
Synchronize Drupal8 Users
This was on a Drupal9 site, and the client got concerned about what they were running.
Please adjust the message so that it either refers to just Drupal or ideally emits the correct major version of Drupal, eg Drupal9, Drupal10, etc.5.55.0Monish DebMonish Debhttps://lab.civicrm.org/dev/drupal/-/issues/172Deprecated function drupal_get_installed_schema_version() in 9.3, but with a ...2022-01-02T15:47:07ZDaveDDeprecated function drupal_get_installed_schema_version() in 9.3, but with a twistdrupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions()...drupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions() instead. See https://www.drupal.org/node/2444417
This is in vendor\civicrm\civicrm-core\CRM/Utils/System/Drupal8.php:
```
public function getModules() {
$modules = [];
$module_data = \Drupal::service('extension.list.module')->reset()->getList();
foreach ($module_data as $module_name => $extension) {
if (!isset($extension->info['hidden']) && $extension->origin != 'core') {
$extension->schema_version = drupal_get_installed_schema_version($module_name);
$modules[] = new CRM_Core_Module('drupal.' . $module_name, ($extension->status == 1));
}
}
return $modules;
}
```
The reason I haven't just put up a simple replacement PR is because if you look at the above function you'll notice schema_version is never used. If you look at the docblock in Base.php it says "List modules installed in the CMS, _including enabled and disabled ones_." Looking at the drupal 7 version (in DrupalBase.php), it does this:
`'SELECT name, status FROM {system} WHERE type = \'module\' AND schema_version <> -1'`
which means only the modules that are installed (but possibly disabled - that's what status is). Now in drupal 8 there is no concept of disabled, it's either installed or uninstalled, but the drupal 8 code is including all of them. In drupal 8 $extension->status means installed or uninstalled.
So two options are:
1. Try to match the drupal 7 implementation/docblock, which means excluding it if $extension->status is 0, and always passing 1 as the second parameter to CRM_Core_Module(), because disabled doesn't mean anything in drupal 8.
2. Leave it the way it is and just remove the unused line about schema_version.
Trying to track down where this gets used, it seems it's mostly in ManagedEntities, which I usually stay away from, and I'm not even sure why ManagedEntities would be dealing with drupal modules other than civicrm itself.
So I'm tempted to stop thinking about it and do item 2.5.46.0https://lab.civicrm.org/dev/drupal/-/issues/169"Your browser session has expired and we are unable to complete your form sub...2022-03-16T00:19:54ZJonGold"Your browser session has expired and we are unable to complete your form submission" on all D9.2 anonymous sessions### Overview
This is an expensive bug, so I'm reporting it even though I don't have complete information.
On all D9.2 sites, anonymous users whose first visit to a CiviCRM page is a contribution or event registration page, will receive ...### Overview
This is an expensive bug, so I'm reporting it even though I don't have complete information.
On all D9.2 sites, anonymous users whose first visit to a CiviCRM page is a contribution or event registration page, will receive the error "Your browser session has expired and we are unable to complete your form submission" on submission. If they resubmit the page it will go through.
### Steps to Replicate
* Install a fresh D8 buildkit site.
* Upgrade to D9.2.0 or higher.
* Open an incognito window and paste in the URL to an event/contribution page (easiest to test if it's a free event with a confirmation page).
* Submit the page. See the error.
### Analysis
I'm still tracking this down and I don't really know the Civi session manager well - but on initial page load, `CRM_Core_Key::sessionID()` returns an empty string. On submitting the form, it finds a session ID correctly, so in `CRM_Core_Key::validate()` the expected key doesn't match the actual key.
While debugging, it's good to note that you can `composer update` to switch between D9.1.3 and D9.2.8 to switch between unbugged and bugged behavior.
It looks like this is the cause:
https://www.drupal.org/node/30063065.43.2https://lab.civicrm.org/dev/drupal/-/issues/166Drupal function ip_address no longer exists after D72021-09-22T13:02:47ZAlanDixonDrupal function ip_address no longer exists after D7There are times where CiviCRM likes to know who it's talking to, i.e. the ip address of the visitor.
This matters especially when it gets passed on to a payment processor.
Here's a utility function that does that: https://github.com/ci...There are times where CiviCRM likes to know who it's talking to, i.e. the ip address of the visitor.
This matters especially when it gets passed on to a payment processor.
Here's a utility function that does that: https://github.com/civicrm/civicrm-core/blob/b599743f3daa46ab96c09ebe410fbb833cdd080f/CRM/Utils/System.php#L1293
This code is fairly naive, but makes use of the fact that Drupal 7 (and earlier) that had a function ip_address that would pay attention to the drupal configuration to be able to deal with front end proxies (like Varnish/hitch).
Unfortunately, D8/9 no longer includes this function, as also noted in this issue for iATS payments.
https://github.com/iATSPayments/com.iatspayments.civicrm/issues/370
Should we continue to provide spaghetti/cms-specific support for front end proxy confusion here? Are there better ways of doing this?https://lab.civicrm.org/dev/drupal/-/issues/163Session erroneously getting set to NULL on Drupal user login2021-11-11T23:32:18ZsteveplatzSession erroneously getting set to NULL on Drupal user loginAnonymous sessions may contain data that needs to be retained after login, for example commerce cart data. In the initialize() method of the core session class civicrm/civicrm-core/CRM/Core/Session.php, there is a check for a changed ses...Anonymous sessions may contain data that needs to be retained after login, for example commerce cart data. In the initialize() method of the core session class civicrm/civicrm-core/CRM/Core/Session.php, there is a check for a changed session id, which if it evaluates to TRUE will set a current session with data to NULL.
```php
// remove $_SESSION reference if session is changed
if (($sid = session_id()) !== $this->sessionID) {
$this->_session = NULL;
$this->sessionID = $sid;
}
```
I've tested this with Drupal 9.2.4 CiviCRM 5.35 and Drupal Commerce 2.26. This specific change was added in https://lab.civicrm.org/dev/drupal/-/issues/98 for Drupal 7.5.43.0https://lab.civicrm.org/dev/drupal/-/issues/153Drupal 8 profile validation not finding the right profile when validating sub...2023-02-15T06:04:10ZDaveDDrupal 8 profile validation not finding the right profile when validating submission on CMS user tabsIn drupal 8/9, like in drupal 7, the CMS user record by default has the Name and Address profile available for editing on the CMS side. As noted in passing at https://lab.civicrm.org/dev/drupal/-/issues/117#note_40124 the validation for ...In drupal 8/9, like in drupal 7, the CMS user record by default has the Name and Address profile available for editing on the CMS side. As noted in passing at https://lab.civicrm.org/dev/drupal/-/issues/117#note_40124 the validation for this form isn't working fully in drupal 8/9.
It appears to be a name vs label problem. The drupal 8 implementation uses the label to look up the profile. I have a quickie fix below but am mulling it over a bit since there's a lot of other things wrong with this form, e.g.
* https://lab.civicrm.org/dev/drupal/-/issues/113
* https://lab.civicrm.org/dev/drupal/-/issues/117
* https://lab.civicrm.org/dev/core/-/issues/2301
```diff
index 37e7ead..b18bb04 100644
--- a/src/Form/UserProfile.php
+++ b/src/Form/UserProfile.php
@@ -75,7 +75,12 @@ class UserProfile extends FormBase {
$this->profile = $profile;
// Search for the profile form, otherwise generate a 404.
- $uf_groups = \CRM_Core_BAO_UFGroup::getModuleUFGroup('User Account');
+ $uf_groups = \CRM_Core_BAO_UFGroup::getModuleUFGroup('User Account', 0, TRUE, \CRM_Core_Permission::VIEW, array(
+ 'id',
+ 'name',
+ 'title',
+ 'is_active',
+ ));
if (empty($uf_groups[$profile])) {
throw new ResourceNotFoundException();
}
@@ -109,7 +114,7 @@ class UserProfile extends FormBase {
* {@inheritdoc}
*/
public function validateForm(array &$form, FormStateInterface $form_state) {
- $errors = \CRM_Core_BAO_UFGroup::isValid($this->contactId, $this->ufGroup['title']);
+ $errors = \CRM_Core_BAO_UFGroup::isValid($this->contactId, $this->ufGroup['name']);
if (is_array($errors)) {
foreach ($errors as $name => $error) {
```
Relatedly, this seems an odd return value if it couldn't find the profile. Shouldn't it return an error?
https://github.com/civicrm/civicrm-core/blob/a7b9631b60548092f8c3056c375dd4b81606dbd4/CRM/Core/BAO/UFGroup.php#L785
FYI @alandixon @spalmstrom5.59.0https://lab.civicrm.org/dev/drupal/-/issues/149D8/D9 Fix Session Start Handling2020-11-30T23:13:25ZseamusleeD8/D9 Fix Session Start HandlingAt present because there is no override in the Drupal8 system class, the DrupalBase SessionStart function is used instead which uses functions and session related code that is not suitable for Drupal8 and can cause Session Already Starte...At present because there is no override in the Drupal8 system class, the DrupalBase SessionStart function is used instead which uses functions and session related code that is not suitable for Drupal8 and can cause Session Already Started notices in watchdog if you use cron.php to execute your cron job.5.33.0seamusleeseamusleehttps://lab.civicrm.org/dev/drupal/-/issues/148When creating Premium - requiring subscription even for "physical" premiums2020-12-02T20:14:25ZplanetwebbWhen creating Premium - requiring subscription even for "physical" premiumsWhen trying to add a new Premium (first one), I get the error "Please enter a Period Type" - even though the premium is a regular "product" and not a subscription.
Civi 5.31 / Drupal 7.73 / PHP 7.3
It has been reproduced by another us...When trying to add a new Premium (first one), I get the error "Please enter a Period Type" - even though the premium is a regular "product" and not a subscription.
Civi 5.31 / Drupal 7.73 / PHP 7.3
It has been reproduced by another user with 5.31, his workaround is to submit dummy subscription info just to submit.
![Screen_Shot_2020-11-20_at_10.08.59_AM](/uploads/8ae8ed5da027f8fd5e550f3ea5185971/Screen_Shot_2020-11-20_at_10.08.59_AM.png)5.32.0https://lab.civicrm.org/dev/drupal/-/issues/145Action dropdown menu no longer working after upgrade from 5.29.x to 5.30.12021-01-15T23:20:39ZbkeevilAction dropdown menu no longer working after upgrade from 5.29.x to 5.30.1The site is using Drupal 8 with the composer install. Running a composer upgrade to 5.30.1 has caused the action dropdown menus to stop working everywhere they are used. See screenshot.
Nothing in the web browser console logs. Nothing ...The site is using Drupal 8 with the composer install. Running a composer upgrade to 5.30.1 has caused the action dropdown menus to stop working everywhere they are used. See screenshot.
Nothing in the web browser console logs. Nothing in apache error logs. Turned error reporting on in CiviCRM and got nothing.
![Screenshot_from_2020-11-12_15-23-58](/uploads/04285ca287009ab295ce73ef2a42a9ae/Screenshot_from_2020-11-12_15-23-58.png)https://lab.civicrm.org/dev/drupal/-/issues/141Drupal 8 hook_uninstall not implemented2021-03-15T15:49:45ZDaveDDrupal 8 hook_uninstall not implementedUninstalling civi using the UI or drush doesn't currently uninstall anything it just tells drupal basically to uncheck the box on the modules list page, but all the data is still there. This leaves drupal+civi in an inconsistent state an...Uninstalling civi using the UI or drush doesn't currently uninstall anything it just tells drupal basically to uncheck the box on the modules list page, but all the data is still there. This leaves drupal+civi in an inconsistent state and trying to check the box again leads to a borked UI because civi keeps trying to do a first run but can't because as far as it's concerned it's already installed.
In drupal 7 hook_uninstall is implemented and drops all the civi tables.
https://github.com/civicrm/civicrm-drupal-8/pull/45#issuecomment-6989822575.37.0https://lab.civicrm.org/dev/drupal/-/issues/137D8 Install checks run via Drupal Status Report - give misleading warnings.2020-10-14T13:50:13Zluke.stewartD8 Install checks run via Drupal Status Report - give misleading warnings.**Problem:**
If the civicrm.settings.php file is not writable, a warning is showing on Drupal Status Report indicating that the civicrm.settings.php file should be writable by the webserver user. This also shows on the command line when...**Problem:**
If the civicrm.settings.php file is not writable, a warning is showing on Drupal Status Report indicating that the civicrm.settings.php file should be writable by the webserver user. This also shows on the command line when running some drush commands.
**Ideal solution:**
The reverse behaviour should be present. Ideally we should warn if civicrm.settings.php is writable by the web server user.
The drupal hook requirements is what is generating this error message.
**Details:**
There is an argument passed to this hook `$phase` that would allow us to target this behaviour.
Currently the behaviour is to use \Civi\Setup checkRequirements() which runs Civicrm Core's install requirements checks.
There is possibly some use in some of these requirements being checked and warnings displayed on the Drupal Status Report page - however there is currently no easy way to differentiate between checks that should only run at install time like the writability of civicrm.settings.php and those that make sense to run post install as well.
Currently the check to see if the user is authorised to run the install only runs when phase is set to install.
An initial solution is potentially to only run the check requirements on install. Then if additional metadata can be returned by `$setup->checkRequirements()->getMessages()` as to whether the warning should run on install or runtime, or checks performed inside civicrm core requirements checks to test for if civi is installed the change could be reverted.5.32.0https://lab.civicrm.org/dev/drupal/-/issues/133Breadcrumb error on CiviCRM admin pages (Drupal 8)2023-12-13T17:46:26ZW01FBreadcrumb error on CiviCRM admin pages (Drupal 8)Getting the following error on several CiviCRM admin pages, including /civicrm/admin
```
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 190 of /home/customer/www/youpickfarms.org/v...Getting the following error on several CiviCRM admin pages, including /civicrm/admin
```
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 190 of /home/customer/www/youpickfarms.org/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php).
CRM_Utils_System_Drupal8->appendBreadCrumb('Administer CiviCRM', '/civicrm/admin?reset=1') (Line: 60)
CRM_Utils_System::__callStatic('appendBreadCrumb', Array) (Line: 76)
CRM_Contact_Form_Domain->preProcess() (Line: 599)
CRM_Core_Form->buildForm() (Line: 120)
CRM_Core_StateMachine->perform(Object, 'next', 'Next') (Line: 45)
CRM_Core_QuickForm_Action_Next->perform(Object, 'next') (Line: 203)
HTML_QuickForm_Controller->handle(Object, 'next') (Line: 103)
HTML_QuickForm_Page->handle('next') (Line: 347)
CRM_Core_Controller->run() (Line: 98)
CRM_Utils_Wrapper->run('CRM_Contact_Form_Domain', 'Organization Address and Contact Info', Array) (Line: 285)
CRM_Core_Invoke::runItem(Array) (Line: 68)
CRM_Core_Invoke::_invoke(Array) (Line: 36)
CRM_Core_Invoke::invoke(Array) (Line: 88)
Drupal\civicrm\Civicrm->invoke(Array) (Line: 80)
Drupal\civicrm\Controller\CivicrmController->main(Array, '')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```5.70.0https://lab.civicrm.org/dev/drupal/-/issues/132Drupal 8 Profile menu items2020-10-04T04:46:49ZAlanDixonDrupal 8 Profile menu itemsWhen using the CiviCRM profiles for "View/Edit Drupal User Account", the tab generated on the user page doesn't use the 'public title'.
Fix on line 40 of
src/Plugin/Derivative/LocalTasks.php
change uf_group['title'] to uf_group['fronten...When using the CiviCRM profiles for "View/Edit Drupal User Account", the tab generated on the user page doesn't use the 'public title'.
Fix on line 40 of
src/Plugin/Derivative/LocalTasks.php
change uf_group['title'] to uf_group['frontend_title']5.31.0https://lab.civicrm.org/dev/drupal/-/issues/131Error: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requ...2020-08-05T11:04:31ZRob_SError: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requirements->checkMysqlVersion()Hi, I am getting this error message with Civi installed on a Drupal 8 site:
Error: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requirements->checkMysqlVersion()
(line 294 of [path]/vendor/civicrm/civicrm-core/Civi/...Hi, I am getting this error message with Civi installed on a Drupal 8 site:
Error: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requirements->checkMysqlVersion()
(line 294 of [path]/vendor/civicrm/civicrm-core/Civi/Install/Requirements.php)
I'm currently on 5.26.2. The problem happened a couole of upgrades back - sorry I cannot remember what versions I was upgrading from and too, but it is kept up to date.
The problem only really manifests when I run the Drupal update.php script (essential after upgrading core and modules), plus also on other rare occasions like once when I had to rebuild the permissions.
I have checked and the CRM_Upgrade_Incremental_General class is there, and the file permissions look ok, so I am guessing the problem is with the class loader, but I do not have any experience of how this works. I would be greatful if someone could give me a tip on how to fix this?
I can get round it for now by putting a 'return' statement at the beginning of the relevant function in the Requirements.php file, so can run the upgrade script, so it is not urgent.5.28.0https://lab.civicrm.org/dev/drupal/-/issues/123acl_entity_role entries deleted after upgrading to 5.25.02021-03-28T20:24:15Zedvanleeuwenacl_entity_role entries deleted after upgrading to 5.25.0After upgrading tot 5.25.0 all entries have been deleted on the Assign Users page. The table acl_entity_role is empty. In the log there are the following lines for each role:
```
"id" "acl_role_id" "entity_table" "entity_id" "is_active"...After upgrading tot 5.25.0 all entries have been deleted on the Assign Users page. The table acl_entity_role is empty. In the log there are the following lines for each role:
```
"id" "acl_role_id" "entity_table" "entity_id" "is_active" "log_date" "log_conn_id" "log_user_id" "log_action"
"458" "459" "civicrm_group" "175" "1" "2020-06-06 14:29:11" "286442" "2" "Delete"
```
I am using OG Sync which did not have any problems previously.https://lab.civicrm.org/dev/drupal/-/issues/118civicrm_views module no longer present causing updatedb error: "The module ci...2020-04-30T18:34:04Zjohnkcivicrm_views module no longer present causing updatedb error: "The module civicrm_views does not exist"CiviCRM 5.24.4 with Drupal 8.8.5. The last few version upgrades, now, I get this error from updatedb.
```
In ExtensionList.php line 265:
...CiviCRM 5.24.4 with Drupal 8.8.5. The last few version upgrades, now, I get this error from updatedb.
```
In ExtensionList.php line 265:
The module civicrm_views does not exist.
```
I thought I was able to fix it, before, with a `drush pm:uninstall civicrm_views`. (I don't need it.) But the error came back. This time I was only able to resolve it by copying civicrm_views from my vendor/civicrm/civicrm-drupal-8/modules/ into web/modules/contrib/civicrm/modules. I can then run the updatedb. Even though I now have this module disabled, I can't remove it from web/modules or I get this in my Apache log upon going to the status page:
```
Uncaught PHP Exception Drupal\\Core\\Extension\\Exception\\UnknownExtensionException: "The module civicrm_views does not exist or is not installed." at /var/www/acreresidency.org/web/core/lib/Drupal/Core/Extension/ExtensionList.php line 346
```
Was this recently taken out of the set of modules and stuff that gets installed by the composer scripts? I'm thinking back to when I used to have to do some of this install work manually, and then eventually composer took over for me.
If I had to take a guess at what this bug is: civicrm_views got removed from what is installed by default, but I already had it installed. And the module doesn't properly clean up after itself on uninstall?
I seem to recall I also, for one of the upgrades, had to remove a line saying "civicrm_views" from an extensions list that's in my config/sync. Just now I looked in the database too. I tried out some "LIKE" queries with "civicrm_view%", and I wasn't able to find anything in my drupal_config table that relates to this module.
How screwed up is my install now? I should have reported this sooner.