🇺🇸United States @safetypin

It seems like this patch has been working for 6 months. Can this be marked RBTC?

That is the most likely issue since you're not using patches. The newest version of Group does not allow User 1 (root/admin) any special permissions by default. You must create an admin role for the group type, and synchronize permissions from the group Role to the Drupal role.

Each Group Type has its own permissions system with its own unique roles, separate from Drupal roles. You must synchronize the permissions between the group type role and the core drupal role in order to have full permissions inside the group. Also, you may want to keep your admin account outside of each group, and setup an 'outside administrator' role for the group type so you won't need to add yourself as a member to every single group but you can still administer every single group from a single account.

The big picture is: the group module takes security very seriously, and has a "Trust No One" attitude in order to create a more secure system. You must work inside the group type permissions to give permissions for those groups to any administrative account (inside or outside the groups). This may be explained better in the documentation.

@lalustine, the issues I was experiencing were due to integrating the (unsupported) patch that allowed group to support config entities, such as menus. Are you also using that config entities patch?

safetypin → created an issue.

I think this issue is actually related to paragraphs. It only happens when I have a paragraph open for editing.

Not sure why the other comment interface didn't give me the option of changing status/version. It does seem to be related to CKEditor module. I'm getting this error trying to save/create a node with a particular rich text formatter. I'll work on recreating this error in a clean d10 install.

It seems like this error has popped up again for me on Drupal 10.2.6:

The website encountered an unexpected error. Try again later.

Error: Cannot create references to/from string offsets in Drupal\Component\Utility\NestedArray::setValue() (line 155 of core/lib/Drupal/Component/Utility/NestedArray.php).
Drupal\Core\Form\FormBuilder->handleInputElement('node_page_edit_form', Array, Object) (Line: 1006)
Drupal\Core\Form\FormBuilder->doBuildForm('node_page_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('node_page_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('node_page_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('node_page_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('node_page_edit_form', Array, Object) (Line: 579)
Drupal\Core\Form\FormBuilder->processForm('node_page_edit_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->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: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I found a stack overflow answer that lead me to the following set of options that do what I was looking for:

          $display_options = [
            'label' => 'hidden',
            'type' => 'entity_reference_entity_view',
            'settings' => [
              'view_mode' => 'lead_image',
            ],
          ];
          $field_view = $fields['field_bynder']->view($display_options);

I thought this was related to the PHP 8.3 upgrade, but I just downgraded to PHP 8.2 and I'm still seeing the error. I've renamed the issue to be specific to the deprecated functionality. I found a stack overflow answer explaining the deprecation message.

safetypin → created an issue.

safetypin → created an issue.

Just wanted to let you know, while another duplicate menu block appears to have been resolved: 🐛 Duplicate menu blocks appear in Layout Builder choose block form Fixed , this particular issue is still occurring for me.

Is this instance of duplicate menu blocks being available expected behavior or a bug?

This particular change is dramatically different from how permissions work everywhere else in Drupal. I feel like I understand your arguments for why you (and others) feel this is the appropriate way to handle permissions in Drupal, but it's very confusing (even for experienced Drupalers) because we expect User 1 to have all permissions everywhere regardless. In this case, that's a faulty assumption, but I haven't come across another contributed module in Drupal that handles administrative (lower-case A) permissions in this way. I don't mean to argue one way or another, but rather explain why this particular issue seems to be causing more grief to you and others.

Thanks for responding. I didn't realize this feature had been so recently added; I just needed to update to 4.3.2 and rebuild the cache, and the button showed up.

how access this interface? when I visit the URL path in the routing.yml file /admin/config/search/search-api/server/[solr_server]/solr-admin/field-analysis I get a 404 error.

@kristiaanvandeneynde - I doubt very much that this issue could be replicated with a clean install; in the original description I stated that I had used several patches from ✨ Entities identified by strings as group content Closed: won't fix . I guess I can't speak for the others who have commented here, but I personally don't have any expectation of support from you for this issue because I used those patches. I'm really grateful for the work you've done to maintain and improve this module. I think we're still missing support for core config entities (menus), from what I've read about your work to support that, there's a lot of core mess that will need to be cleaned up before that's possible. But, I'm thankfully in a situation where it's not strictly necessary for our groups to have access to the menu system.

@adriancotter - If I remember correctly, I resolved this issue using some sql in a custom module to move some data around from the "support config entities" patch:

function custom_module_fix_group_db_install() {
  $database = \Drupal::database();

  // We need to re-add the entity_id column to group_content_field_data.
  // Get data from the table that the patch added ('group_content__entity_id').
  $database->query("ALTER TABLE group_content_field_data ADD entity_id INT(11);");
  $database->query("
    UPDATE group_content_field_data
    JOIN group_content__entity_id ON group_content_field_data.id = group_content__entity_id.entity_id
    SET group_content_field_data.entity_id = group_content__entity_id.entity_id_target_id;
  ");

  // Now, we can remove all the messed up config, from the old field.
  $database->query("DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';");
  $database->query("DROP TABLE group_content__entity_id_str;");
  $database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");
}

So, my issue was that I wanted a node to be created automatically, once per day, and I was able to create a custom module that creates a custom cron task that does this in code. It is two files. If you can figure out how to do what you want to do in code, then you can replace the contents of the if (REQUEST_TIME >= $next_execution) block below:

once_per_day.info.yml:

name: Once per Day
type: module
description: A custom module to automate daily node creation.
core_version_requirement: ^9.2 || ^10
package: Custom
dependencies:
  - drupal:node

once_per_day.module:

use \Drupal\node\Entity\Node;

/**
 * Implements hook_cron().
 *
 * We implement hook_cron() to do "background" processing. It gets called every
 * time the Drupal cron runs. We then decide what has to happen in response.
 *
 * In this example, we log a message after the time given in the state value
 * 'cron_example.next_execution'. Then we update that variable to a time in the
 * future.
 */

function once_per_day_cron() {
  // We access our configuration.
  $cron_config = \Drupal::configFactory()->getEditable('once_per_day.settings');

  // 86400 seconds = 1 Day
  $interval = $cron_config->get('interval');
  $interval = !empty($interval) ? $interval : 60;

  // We usually don't want to act every time cron runs (which could be every
  // minute) so keep a time for the next run in the site state.
  $next_execution = \Drupal::state()->get('once_per_day.next_execution');
  $next_execution = !empty($next_execution) ? $next_execution : 0;

  if (REQUEST_TIME >= $next_execution) {
    $node = Node::create([
      'type'  => 'once_per_day',
      'title' => date('F j, Y', REQUEST_TIME) // date_iso8601(REQUEST_TIME)
    ]);
    $node->save();
    \Drupal::logger('once_per_day')->notice('once_per_day ran');
    \Drupal::state()->set('once_per_day.next_execution', strtotime('tomorrow +7 hours'));
  }
}

Has anyone seen this error when attempting to upgrade to Drupal 10 with SimpleSAMLphp Authentication:

Unable to install module simplesamlphp/simplesamlphp-assets-base, package name must be on the form "VENDOR/simplesamlphp-module-MODULENAME".                                                                                  

I've tried a few ways to upgrade everything at once, but this error keeps cropping up. I would assume that it's an issue with the SimpleSAMLphp library, but when I submitted an issue over there, the first suggestion I got was to upgrade sipmlesamlphp-assets-base before everything else, which I can't seem to make happen due to (at least, but probably not only) conflicting dependencies on psr/log:^3.0 for the simplesamlphp/simplesamlphp:2.1.0-rc1 and Drupal 9.5 limiting support to ^1.1.

So, I know this isn't a problem with this Drupal Module, but does anyone have any suggestions for getting around it?

Is there a recommended procedure considering Drupal 9.x will be EOL Nov 2023? Our site is at least somewhat dependent on File MDM & I prefer ImageMagick to GD.

Should we remove ImageMagick until D10.1 is supported so we can stay up to date with security updates?

I'm also experiencing this error when saving any node on the site, regardless of whether the node is related to a group:

 Error: Class "Drupal\group\Entity\GroupContent" not found in gnode_tokens() (line 63 of modules/contrib/group/modules/gnode/gnode.tokens.inc).
gnode_tokens('node', Array, Array, Array, Object)
call_user_func_array(Object, Array) (Line: 426)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'gnode') (Line: 405)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('tokens', Object) (Line: 433)
Drupal\Core\Extension\ModuleHandler->invokeAll('tokens', Array) (Line: 359)
Drupal\Core\Utility\Token->generate('node', Array, Array, Array, Object) (Line: 241)
Drupal\Core\Utility\Token->doReplace(1, '[node:group:url:path]/[node:menu-link:parents:join-path]/[node:title]', Array, Array, Object) (Line: 191)
Drupal\Core\Utility\Token->replace('[node:group:url:path]/[node:menu-link:parents:join-path]/[node:title]', Array, Array, Object) (Line: 228)
Drupal\pathauto\PathautoGenerator->createEntityAlias(Object, 'update') (Line: 381)
Drupal\pathauto\PathautoGenerator->updateEntityAlias(Object, 'update') (Line: 93)
pathauto_entity_update(Object)
call_user_func_array(Object, Array) (Line: 426)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'pathauto') (Line: 405)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('entity_update', Object) (Line: 433)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_update', Array) (Line: 251)
Drupal\Core\Entity\EntityStorageBase->invokeHook('update', Object) (Line: 900)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('update', Object) (Line: 598)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, 1) (Line: 781)
Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, 1) (Line: 523)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 804)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 339)
Drupal\Core\Entity\EntityBase->save() (Line: 270)
Drupal\node\NodeForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 114)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('node_page_edit_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
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: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
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: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19) 

I'm continuing to experience this when attempting to viewing group members. I'm also just noticing that this is a views error, and I don't see any reference to Group code in this error.

This appears to be working for me as well, but I think I'm using 4.x-dev instead of 4.0.0-rc1. However, when I try composer require 'drupal/simplesamlphp_auth:^4.0@RC' nothing gets updated, so I guess I'm using the right version? I don't see a version number in 'admin/extend'.

safetypin → created an issue.

Has anyone considered adding support for the Image Replace Effect module? It can integrate already with an image source media entity, so I would imagine it might not be too hard to extend support to Bynder media entities. I'll start to look into it, and if I develop anything useful I'll start a new thread. Not sure if it should be a patch to this module, a patch to the Replace Effect module, or a whole 'nother module all together.

This was apparently caused by the 'Chosen' module.

I found this video: https://www.youtube.com/watch?v=xo2z8NuKEH4 which seems like it should help, but when I attempt to create an 'outside admin' role for the group type, the Global role select menu is greyed out, and the only drupal role available is 'Anonymous'. Does anyone know why I wouldn't be able to select a different drupal role?

safetypin → created an issue.

Found a duplicate: 💬 Sitewide Administrator permissions not working Closed: works as designed

God mode accounts have no place in proper access control code and Group follows that idea.

@kristiaanvandeneynde I can understand why an 'administrator' role might not automatically get these permissions, but saying that 'god mode' accounts are bad ignores the idea behind a root user. Of course, no-one recommends operating a computer as root, but there always is a root account for which the administrator of the computer always has access. user/1 has always been root in Drupal, for as long as I've used it (since ~2005, and while I definitely support your "read the manual" response, I think it's also reasonable that your average Drupal Administrator would expect user/1 to always have access to every entity and every operation on the whole site. I don't think user/1 should have any restrictions whatsoever. user/1 should always bypass every restriction every time.

I'm hoping this comes across as a very forceful but respectful disagreement.

I shouldn't have to do anything to allow user/1 administrative access to every group, but I do understand why there isn't a default way to give an administrative role administrative access to every group by default. I hope you will consider this argument as an more specific request than maybe the one in the original issue.

safetypin → created an issue.

I'm pretty sure this is due to an entry in the key_value table that should have been deleted.

Try executing SELECT * FROM key_value WHERE name='group_content.field_storage_definitions'; and see if it returns any records. If it does, you should manually remove that row. (test it first in a development environment to be extra careful.

When can we expect a new release that includes this patch?

Has anyone started working on a new module to integrate menu config entities as group content for 2.x? Can we start a drupal/group_menu module?

I figured out how to get it working. For some reason, as mentioned in my last post, the sql command to remove the storage definition didn't get removed, but this command worked when I executed directly on the database server. This patch should apply cleanly to 1.5; you might need to change the update numbers to get it to apply to 1.6. If anyone else needs it, this is the content of the patch file I'm using:

diff --git a/group.install b/group.install
index d05dbb1..38c3f0c 100644
--- a/group.install
+++ b/group.install
@@ -722,3 +722,69 @@ function group_update_8025(&$sandbox) {
   \Drupal::entityDefinitionUpdateManager()
     ->installFieldStorageDefinition('entity_id_str', 'group_content', 'group_content', $entity_id_str_definition);
 }
+
+function group_update_8026(&$sandbox) {
+  $database = \Drupal::database();
+
+// We need to re-add the entity_id column to group_content_field_data.
+// Get data from the table that the patch added ('group_content__entity_id').
+$database->query("ALTER TABLE group_content_field_data ADD entity_id INT(11);");
+$database->query("
+  UPDATE group_content_field_data
+  JOIN group_content__entity_id ON group_content_field_data.id = group_content__entity_id.entity_id
+  SET group_content_field_data.entity_id = group_content__entity_id.entity_id_target_id;
+");
+
+// Make sure the entity_id column has the correct index keys and properties.
+$database->query("
+  ALTER TABLE `group_content_field_data`
+  MODIFY COLUMN `entity_id` int(10) unsigned DEFAULT NULL COMMENT 'The ID of the target entity.',
+  DROP INDEX IF EXISTS `group_content_field__entity_id__target_id`,
+  ADD INDEX `group_content_field__entity_id__target_id` (`entity_id`),
+  DROP INDEX IF EXISTS `group_content__entity_fields`,
+  ADD INDEX `group_content__entity_fields` (`type`,`entity_id`);
+");
+
+// Now, we can remove all the messed up config, from the old field.
+$database->query("DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';");
+$database->query("DROP TABLE group_content__entity_id_str;");
+
+// If we don't delete the whole field_storage_definition, we run into errors,
+// when we remove the patch.
+$database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");
+
+// Alternatively to removing the whole field storage definition, I'd prefer
+// to just remove the reference to entity_id_str, but I couldnt get that
+// to work.
+/** @var \Drupal\Core\KeyValueStore\DatabaseStorage $key_value */
+/*
+  $key_value = \Drupal::service('keyvalue')->get('entity.definitions.installed');
+  $group_field_defs_key = 'group_content.field_storage_definitions';
+  $group_field_defs = $key_value->get($group_field_defs_key);
+  unset($group_field_defs['entity_id_str']);
+  $key_value->set($group_field_defs_key, $group_field_defs);
+*/
+}
+
+/**
+ * Alter the database, to not have broken Groups module config.
+ */
+function group_update_8027(&$sandbox) {
+  $entity_type_manager = \Drupal::entityTypeManager();
+  $entity_type_manager->clearCachedDefinitions();
+
+  $entity_type_ids = [];
+  $change_summary = \Drupal::service('entity.definition_update_manager')->getChangeSummary();
+  foreach ($change_summary as $entity_type_id => $change_list) {
+    $entity_type = $entity_type_manager->getDefinition($entity_type_id);
+    \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);
+
+    $entity_type_ids[] = $entity_type_id;
+  }
+
+  drupal_flush_all_caches();
+
+  return t("Installed/Updated the entity type(s): @entity_type_ids", [
+    '@entity_type_ids' => implode(', ', $entity_type_ids),
+  ]);
+}

@ras-ben, do you have any insight into why this command might not work?

$database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");

I applied your patches (#298 & #299) as database updates to group v1.5, but I was still running into errors. I looked at a the key_value table, and found an entry named 'group_content.field_storage_definitions', so it appears that command didn't work. I removed that record manually and the error went away, so other than that, everything appears to be working.

No, I added a variable redirect in my hosting configuration for user/[0-9]* -- that's a regex expression -- and this accomplishes pretty much what I want, because there's no reason for users on our web site to view their profile pages. I can still edit accounts from the admin/people page, so it works for us. Definitely not ideal.

I think I've successfully extricated this patch from my installation of Group 1.5, at least that's which version I *thought* was installed. When I look at my production module list, I see 8.x-1.0-beta3. I removed all menu relationships manually. I manually added the functions from #298 & #299 as group_update_8026 & group_update 8027 to group.install, and executed database updates. This didn't result in errors, and I was able to uninstall the groupmenu module afterwards. Then I went into a couple of group entities' edit menus, and was able to click around a bit without errors.

So, I'd like to replicate this process in my production environment, but in order to do that, I need a patch file that will add these update methods to the group.install file. However, I'm not sure which version of Group I should check out locally in order to create that patch file. I would expect to work with 8.x-1.x, but that is missing some database updates. As an added complication, if I update group, I now get a 1.6 version. Composer gives the following output:
- Upgrading drupal/group (1.5.0 => 1.6.0): Extracting archive

And then the patch I've been using doesn't apply properly. So, I'm confused on a couple of counts: why does drupal's GUI report that I'm using 8.x-1.0-beta3 but composer says I'm using 1.5.0?

What is the best way for me to generate a patch against 1.5.0, so I add these group_update_xxxx functions and undo the database updates that this patch made?

Ah, thanks for pointing that out. I don't think I realized there wasn't an upgrade path from 2->3. Unfortunately, this error doesn't appear to be specific to 3.x, as I reverted my database, reapplied the patch, ran the database updates again, and I'm still seeing this error.

I've edited the summary and title, and replaced the old error with the new just to be sure.

This patch 🐛 field definition empty in group_update_9203 Needs review worked to get me past the langcode field error. I had some strange errors and outputs that went away after some cache rebuilding. But I've run into another issue: 💬 Error after upgrading from 1.5 -> 2.1 Active .

I've also just noticed that I'm missing several tabs on group entities: I'm missing at least the Members tab.

safetypin → created an issue.

safetypin → created an issue.

safetypin → created an issue.

So, I realize this does not constitute a test suite, but I just upgraded the simplesamlphp_auth module in my Drupal 9.5.9 site, and in a testing environment the SAML authentication process is working.

I'm not super confident I did this correctly, can someone else review this patch and continue discussion or open a merge request in the new issue? 📌 Support SimpleSAMLphp 2.1 release Fixed

I think we just need to update the dependency on the SSP library, right? We don't need to change the drupal version support, since it already includes 10: "drupal/core": "^9.4 || ^10".

safetypin → created an issue.

@nitesh624 i have an online development environment that I can use to test this in a close-to-production arrangement. should I ignore composer, and attempt to run this module with the 2.1 branch all installed manually?

If not, what is the best way to do this testing?

It's working for me, as far as I know. Using 4.x release 666615bd55fd20b1a744ca376765d257093d5538, and Drupal 9.5.9.

I'm looking at trying to upgrade to d10, and that isn't working. I think because of downstream dependencies from this module. About to go check the issue queue to see what's needed for a d10 compatible release.

safetypin → created an issue.

safetypin → created an issue.

safetypin → created an issue.

This patch is working for me. Needs further review.

Needed to remove the core key from the fastlypurger submodule info.yml file as well.

safetypin → created an issue.

I disabled a bunch of modules and it started working, so I think it's an interaction with another module. I tried to go through and disable just a few modules at a time last week, but I haven't had time to finish figuring out which module it is.

Thanks; it's still not working in our production environment, but I was able to verify that it does work out of the box on a fresh install. So, presumably there's some template for preprocessing method that is breaking it. It appears to be a rendering issue; the field HTML isn't rendered at all.

What is the recommended way to activate the threejs library with a CDN?

I've tried downloading the file https://unpkg.com/three@0.152.1/build/three.module.js and including it using my theme library. When I do this, I can see that the threejs module is included in the HTML, but it still doesn't work.

I removed the importmap script, and it's still not working. To address your initial question (what instructions?), the instructions i'm talking about are the ones in the description of the project:

Use CDN threejs
This module is based on https://github.com/eneus/drupal_threejs (but it's not totally the same I reuse about 30%).
How to use:

Enable modules Threejs + Threejs field
Configuration Threejs
Configuration field Threejs formatter

Support some format 3d like obj dae gltf stl....

some issue:
- camera fit to object (i set for scanner box)
- texture not work some case
- autorotation

I'm not familiar with the importmap script thing; how is the threejs library imported without that code?

I don't have any custom scripts.

safetypin → created an issue.

Thanks for your help. I think we might be ok without logging and no BCC functions.

Ok, that sort of makes sense to me. So, the argument against using native transport is: you cannot control how sendmail is configured.

I poked around the issues, and I found this ( https://www.drupal.org/project/symfony_mailer/issues/3274465#comment-145... ✨ Add Sendmail transport Fixed ):

$settings['mailer_sendmail_commands'] = [
  '/usr/sbin/sendmail -i -S -t mailhog:1025',
];

This looks to me like I can override the sendmail command. Could I use this to get around the -bs flag support issue?

Can you explain why "Native transport" option is not recommended? It appears to be working for me.

safetypin → created an issue.

I'm not really sure this requires any kind of fix. Testing in a local dev environment, I truncated all the broken_link tables and the database updates applied successfully.

When I run the database updates locally, the main thing that's different is the amount of memory that's exhausted. When I run it locally, the allowed memory size is:

Fatal error:  Allowed memory size of 1073741824 bytes exhausted (tried to allocate 4096 bytes) in /var/www/html/docroot/core/lib/Drupal/Core/Database/StatementWrapper.php on line 145
Fatal error:  Allowed memory size of 1073741824 bytes exhausted (tried to allocate 65536 bytes) in /var/www/html/docroot/core/lib/Drupal/Core/ProxyClass/Batch/BatchStorage.php on line 91

.

I think this could be related to the size of our broken link table: there are more than 218,721 rows. I think it's probably ok for us to just truncate this table, but I'm guessing this is at least somewhat related to the batch process management system.

safetypin → created an issue.

andy-blum → credited safetypin → .

It was so long ago that I had "one priority" before I would get to this, and of course I still have yet to get to it. Still hobbling along with VEF and IMCE instead of media library. I'll have to take a look at that media_migration issue this summer. We may end up skipping core media library in favor of DAM integration.