I have cloned the Socialblue theme in order to extend it, as suggested in the theme's readme.md file:

The safest and fastest way to get started is to duplicate this theme and rename it to your custom theme name.

After enabling my new cloned theme, I uninstalled the socialblue theme. I expected that this would be fine because now my cloned theme depends on the socialbase theme. However; when I visit a group's members management page (E.g.: /group/5/membership), I get the following error:

TypeError: Argument 1 passed to Drupal\block\BlockViewBuilder::view() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in /app/html/profiles/contrib/social/modules/social_features/social_group/social_group.module on line 1102 in Drupal\block\BlockViewBuilder->view() (line 30 of /app/html/core/modules/block/src/BlockViewBuilder.php) 

After inspecting the content of social_group.module, I see that a block with ID socialblue_local_actions is being loaded near line 1102:

$entity = \Drupal::entityTypeManager()->getStorage('block')
      ->load('socialblue_local_actions');

Upon further inspection, I see that the block called "Primary admin actions" has the ID socialblue_local_actions on the Socialblue theme; however, the same block has the ID mythemename_local_actions on my cloned theme.

I have fixed the problem by re-enabling the Socialblue theme; but, I think it shouldn't be necessary to have a theme enabled if it isn't going to be used.

A possibly better solution would be to move the function

/**
 * Implements hook_preprocess_HOOK().
 */
function social_group_preprocess_views_view(&$variables) {
  /** @var \Drupal\views\ViewExecutable $view */
  $view = &$variables['view'];

  if ($view->id() === 'group_manage_members') {
    $entity = \Drupal::entityTypeManager()->getStorage('block')
      ->load('socialblue_local_actions');

    $variables['header']['actions'] = \Drupal::entityTypeManager()
      ->getViewBuilder('block')
      ->view($entity);
  }
}

...into the socialblue.theme file and document the necessary string replacements for new cloned themes.

I'd be happy to try this fix and share a patch, if you think this is a good idea.

Thank you for the great work on this distribution.

Comments

jcmartinez created an issue. See original summary.

ronaldtebrake’s picture

Thanks for reporting this and that's a great find, that would definitely be a good idea!

Pegasus360’s picture

The question for me in this custom theming process is why make a subtheme with the base theme socialbase when there will be future features added to socialblue. Shouldn't the subtheme use socialblue as the base theme? I am struggling with this idea as I try to create a subtheme for my existing site.

Kingdutch’s picture

Version: 8.x-5.6 » 8.x-5.x-dev
Component: Code (back-end) » Groups
Issue tags: -theme, -groups

The socialbase theme should be the only theme that's required to provide structural visual elements for Open Social. The socialblue theme should mostly be a coloring layer on top of the socialbase theme.

Ideally the core of Open Social would even work without socialbase but that's currently not possible as quite some functionality depends on visual elements present in socialbase.

A good first step here is to make sure that the referenced block is loaded from SocialBase instead of SocialBlue. If there are functional differences between the two than we'll have to resolve those differences in this issue as well.

Additionally we'll have to figure out whether this functionality is truly needed for the Group module in which case we may want to move it from SocialBase into the Group module itself altogether. If it's not vital for the functionality then we should move the alteration into the socialbase theme itself.

Some more investigation will be needed to answer the functional questions posed above.

Pegasus360’s picture

Thank you Kingdutch for the explanation and clarification. That certainly helps moving forward.

scm6079’s picture

This still exists in the current OpenSocial 10.2.5 version. As a simple workaround it is possible to clone the block configuration from your custom theme (e.g. customtheme_ local_actions) and simply change the ID to socialblue_local_actions, and then import that configuration.

The proper change would be as mentioned to either rely on socialbase, or read the active theme when making this call.

SocialNicheGuru’s picture

If I make a subtheme of socialblue would I just put this in the mysocialblue-subtheme.info.yml base theme : socialblue ?

Shouldn't that take on all of those elements.

SocialNicheGuru’s picture

I added issues that show that this is still an issue