Theme interface crash on missing block description in views

By description you mean the "Administrative description" in Views UI?

This description is not used in the theme settings. Afaict this is not even get-able outside of views UI, I see no data or methods for this in the block values.

The theme uses three methods to retrieve data from the block values:

$block_id = $block_values->id();
$plugin_id = $block_values->getPluginId();
$block_label = t($block_values->label());

So I'm not really sure what caused your issue. The theme simply does not use the description, everything it uses is programatically generated by Drupal, even if you leave the label empty Views will fill it in with a machine name.

That description will become the block name (or label, i.e. $block_label = t($block_values->label());, however this is never empty, it's always set, if there no block name (Block admin description) it uses the View name instead.

Even if it were empty there is no way it would cause a WSoD.

When you do get a WSoD you need to check two things:

1) In Reports > Recent Log messages - to see if something happened (PHP error) at precisely that time and appears relevant) AND
2) The PHP error log, where all errors are logged.

Hunches are not great, PHP and Drupal can almost always tell us what is going wrong.

I can't reproduce this, if you can describe steps that allow me to, then we can reopen it, but as it's being described here it is not reproducible.

Lets look at the language stuff, could be the reason, when other languages are used some things change in the output.

After an update to the latest devs of adaptivetheme and at tools an hour ago, I got a similar problem. The settings page of my subtheme cannot be opened anymore and only gives me php error. The theme itself seems to be working fine, expect of my main menu styling, which is broken an the responsive menu twig template is not picked up like before.

After checking my views for missing block names, I discovered that an exposed filter block (views search) caused an issue.

Php error log before removing this block:

Uncaught PHP Exception InvalidArgumentException: "$string ("Exposed form: @view-@display_id") must be a string." at /Applications/MAMP/htdocs/pleasuremag2016/www/core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php line 140

Unfortunately that did not solve the problem, but the error changed:

PHP Fatal error:  Class 'Drupal\comment\Entity\CommentType' not found in /Applications/MAMP/htdocs/pleasuremag2016/www/themes/adaptivetheme/at_core/forms/ext/shortcodes.php on line 130

Where there any change concerning the templates that I would need to update in my subtheme?

Thanks for your help!

I am also using this version, yes. I activated a bunch of the shortcodes but actually did not use them on the fields inside the settings, I rather wanted to take advantage of them in my scss files.

@Jeff: If I comment out the following part of shortcodes.php (line 130), I can open the AT settings again, without getting the WSoD. That part was added, after the version (rc2+67-dev) I was using before. Would be nice if you could guide me through the necessary changes in my subtheme to keep it up to date and working.

FYI: I am not using any comments on my page so far, so the comment module is uninstalled.

// Comment types
$comment_types = \Drupal\comment\Entity\CommentType::loadMultiple();
$form['shortcodes']['commenttype_classes'] = [
  '#type' => 'details',
  '#title' => t('Comment types'),
];
foreach ($comment_types as $ct) {
  $comment_type = $ct->id();
  $comment_type_name = $ct->label();

  $form['shortcodes']['commenttype_classes']['settings_commenttype_classes_' . $comment_type] = [
    '#type' => 'textfield',
    '#title' => t($comment_type_name),
    '#default_value' => Html::escape(theme_get_setting('settings.commenttype_classes_' . $comment_type, $theme)),
  ];
}

The problem with my responsive menu solved itself, now that I could reach and save the extension settings again.

The issue from #11 still remains.

Cool, I'll have to try to figure out why the Class is not found, I think that's a downstream effect of something else going on in shortcodes.

I'll do the exposed filter test also - lets see if we can tease out the bugs and/or whats exactly going on here.

I've added a check for comment module so that will be safer now. Exposing the filter did not cause me any issues.

If anyone gets a similar issue please view your PHP error log and the Drupal logs and post them here (like #9), this is the most useful thing for me.

If you can then save the theme settings - I suspect this issue might occur with an update to Adaptivetheme dev.

Just to let you know, the check mentioned in your previous post solved it for me. Thanks!

How did you solve it?

I am getting this:

InvalidArgumentException: $string ("@view: @display") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 140 of core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php).

THanks!

@ #16 yes, I just ran into this myself, I have removed some of the translations in forms for blocks (Mobile blocks and Shortcodes): http://cgit.drupalcode.org/adaptivetheme/commit/?id=c7cb7cc

This solves your issue.