portulaca β created an issue.
I can confirm it behaves like that, it's impossible to use the Views Accordion when there is more than one grouping criterion.
In D7 there was the addon module that implements more than one accordion level https://www.drupal.org/project/views_nested_accordion β but the new version isn't working.
This bug isn't about nested accordions though, it's about not being able to use field grouping in accordion content (only one grouping, the one for accordion headers, works as expected).
Patch #45 isn't working for me when Address field has some required fields.
If I make them optional, then the updates for other fields go through, even when the Alt field of an image field is kept as Required.
+1 for showing a message or at least adding a log entry why the main form button doesn't react.
I don't know if my configuration applies for this issue, I wanted to share info just in case.
I had problems with Views Bulk Edit working on a multilingual site so I tried this patch. It didn't make any difference. Canceling the form works even without this patch, but trying to submit the changes doesn't, with or without this patch.
For me the problem was the required fields, and the patch from https://www.drupal.org/project/views_bulk_edit/issues/3024419#comment-15... π Fix Required fields to really not be required Needs review didn't help either.
I was able to update my nodes by changing all the Required field options apart from Title (for Title I chose to Append and left it empty).
With that modification to my CT config Views Bulk Edit works, even without the patch above, to update all the node translations, the current interface language node and all the others as well.
I tried the fivestar token in the Header Text area, with Full HTML format, and the result is still wrong output, it doesn't show the form, only the text of the individual parts:
I tried playing with image field token and it's behaving correctly everywhere, it's showing image, linked or not, exactly as is set in its field settings, in regular Image field, Custom text, Header Text area, always shows up correctly. If I Rewrite the field with some image token on the Image field itself (because those tokens aren't available anywhere else), the output is propagated everywhere correctly, the Custom text and Header Text area are showing the output from the token selected in the Image Rewrite settings.
So far I only found fivestar is affected. What other module could I try with tokens that might shed more light on this?
The reason for using fivestar through a token is HTML control. Fivestar is being displayed along several other fields and there is HTML added around them so they display in the desired layout. All those fields are set to Exclude from display, and Custom text is outputting all of them with some HTML containers laying them out in the desired visual arrangement.
@TR the allowed HTML seems to be fixed, it doesn't seem to follow Text format settings, and I don't see anywhere in Custom Text where that could be set. It's not like Text area that you can add in Header of Views, I can see the select dropdown there, but not in the Custom Text field.
I tried using the "Strip HTML tags" that has "Preserve certain tags" in the "Rewrite results", I added all the tags that I see in the regular output, but I'm still getting the same result of the same text output as from above.
Also, I would imagine that the HTML limitations in Custom Text are to be applied to the HTML you enter around the tokens, not the tokens themselves, since tokens are governed upstream, extra validation at this point down the line could break things unpredictably.
Is this then an issue about how replacement pattern tokens are handled in general? I don't think I've seen a token behave differently from the regular field output, when you're using the token for the entire field and not some data breakdown.
___________
Unrelated: I also see 2 additional tokens when trying to Rewrite the actual field in its own settings:
{{ field_fivestar__rating }} == Raw rating
{{ field_fivestar__target }} == Raw target
but these tokens aren't available in the Custom Text field. Why is that? Usually what I see is that all the tokens related to a field are available to the fields that follow it in the Fields list.
Here is what I get on a new site with Testfivestar field added to Article CT, in Views:
When the fivestar field is being displayed, it's shown as a form correctly, it's interactive and it works.
When the same field is printed out through a token in a Custom text field the result isn't the same. Everything is written out, and not interactive.
There is only one token for the related field. The expectation is that it should output the same HTML (a working form, if that applies, in any case the output should be the same as the field printed out directly and not through a token).
portulaca β created an issue.
I got the same Error after upgrading from D8.8 to D9.5.10. All db updates went through and drush status was ok, cache rebuilt, but I was getting WSOD.
After applying the patch I got the site to show up.
The carousel still isn't working correctly and I'm still getting Errors in reports:
Error: Cannot use a scalar value as an array in _owlcarousel_format_settings() (line 113 of /modules/contrib/owlcarousel/owlcarousel.module)
#0 /modules/contrib/owlcarousel/owlcarousel.module(82): _owlcarousel_format_settings()
#1 [internal function]: template_preprocess_owlcarousel_views()
#2 /core/lib/Drupal/Core/Theme/ThemeManager.php(287): call_user_func_array()
#3 /core/lib/Drupal/Core/Render/Renderer.php(433): Drupal\Core\Theme\ThemeManager->render()
#4 /core/lib/Drupal/Core/Render/Renderer.php(446): Drupal\Core\Render\Renderer->doRender()
#5 /core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#6 /core/lib/Drupal/Core/Template/TwigExtension.php(479): Drupal\Core\Render\Renderer->render()
#7 /sites/default/files/php/twig/650725053cd53_views-view.html.twig_BlLcFEh-bn1E96s3L9C6enGzN/3MpzNDtFl9tJXhTfS6GDtCyzf1u2Bh0w4Af6xYet4m0.php(110): Drupal\Core\Template\TwigExtension->escapeFilter()
#8 /vendor/twig/twig/src/Template.php(405): __TwigTemplate_70b62d25bd5144577874a9bf37e814ce->doDisplay()
#9 /vendor/twig/twig/src/Template.php(378): Twig\Template->displayWithErrorHandling()
#10 /vendor/twig/twig/src/Template.php(390): Twig\Template->display()
#11 /core/themes/engines/twig/twig.engine(55): Twig\Template->render()
#12 /core/lib/Drupal/Core/Theme/ThemeManager.php(384): twig_render_template()
#13 /core/lib/Drupal/Core/Render/Renderer.php(433): Drupal\Core\Theme\ThemeManager->render()
#14 /core/lib/Drupal/Core/Render/Renderer.php(446): Drupal\Core\Render\Renderer->doRender()
#15 /core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#16 /core/lib/Drupal/Core/Template/TwigExtension.php(479): Drupal\Core\Render\Renderer->render()
#17 /sites/default/files/php/twig/650725053cd53_block.html.twig_5F8DcAJhGAcLY1gkHU5-0kLgH/qW0XtmQac8v0qt1amf885h8UVsMe5gxhSbt_ZDXThy4.php(84): Drupal\Core\Template\TwigExtension->escapeFilter()
#18 /vendor/twig/twig/src/Template.php(182): __TwigTemplate_63a3a26fcc67716e34c03194943eaf6e->block_content()
#19 /sites/default/files/php/twig/650725053cd53_block.html.twig_5F8DcAJhGAcLY1gkHU5-0kLgH/qW0XtmQac8v0qt1amf885h8UVsMe5gxhSbt_ZDXThy4.php(68): Twig\Template->displayBlock()
#20 /vendor/twig/twig/src/Template.php(405): __TwigTemplate_63a3a26fcc67716e34c03194943eaf6e->doDisplay()
#21 /vendor/twig/twig/src/Template.php(378): Twig\Template->displayWithErrorHandling()
#22 /vendor/twig/twig/src/Template.php(390): Twig\Template->display()
#23 /core/themes/engines/twig/twig.engine(55): Twig\Template->render()
#24 /core/lib/Drupal/Core/Theme/ThemeManager.php(384): twig_render_template()
#25 /core/lib/Drupal/Core/Render/Renderer.php(433): Drupal\Core\Theme\ThemeManager->render()
#26 /core/lib/Drupal/Core/Render/Renderer.php(446): Drupal\Core\Render\Renderer->doRender()
#27 /core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#28 /core/lib/Drupal/Core/Template/TwigExtension.php(479): Drupal\Core\Render\Renderer->render()
#29 /sites/default/files/php/twig/650725053cd53_page--front.html.twig_zfNTopfwE4522-XoZVHMeYkYD/mND5AKQDQlfNEgKWEe0oxiQpxwzP_JZQZJXM61YqBoA.php(243): Drupal\Core\Template\TwigExtension->escapeFilter()
#30 /vendor/twig/twig/src/Template.php(182): __TwigTemplate_351b05afc2f581dd8f5c62dee7dafff6->block_featured()
#31 /sites/default/files/php/twig/650725053cd53_page--front.html.twig_zfNTopfwE4522-XoZVHMeYkYD/mND5AKQDQlfNEgKWEe0oxiQpxwzP_JZQZJXM61YqBoA.php(94): Twig\Template->displayBlock()
#32 /vendor/twig/twig/src/Template.php(405): __TwigTemplate_351b05afc2f581dd8f5c62dee7dafff6->doDisplay()
#33 /vendor/twig/twig/src/Template.php(378): Twig\Template->displayWithErrorHandling()
#34 /vendor/twig/twig/src/Template.php(390): Twig\Template->display()
#35 /core/themes/engines/twig/twig.engine(55): Twig\Template->render()
#36 /core/lib/Drupal/Core/Theme/ThemeManager.php(384): twig_render_template()
#37 /core/lib/Drupal/Core/Render/Renderer.php(433): Drupal\Core\Theme\ThemeManager->render()
#38 /core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#39 /core/lib/Drupal/Core/Template/TwigExtension.php(479): Drupal\Core\Render\Renderer->render()
#40 /sites/default/files/php/twig/650725053cd53_html.html.twig_n7C1LRD4iBFxEYglBjZffAJAk/5314BQnyYH0Ronh3j6AqNlef1uA3VSdanWCKTJQAgdE.php(84): Drupal\Core\Template\TwigExtension->escapeFilter()
#41 /vendor/twig/twig/src/Template.php(405): __TwigTemplate_143d426f9d2e1dfdc75fb61902de7d8c->doDisplay()
#42 /vendor/twig/twig/src/Template.php(378): Twig\Template->displayWithErrorHandling()
#43 /vendor/twig/twig/src/Template.php(390): Twig\Template->display()
#44 /core/themes/engines/twig/twig.engine(55): Twig\Template->render()
#45 /core/lib/Drupal/Core/Theme/ThemeManager.php(384): twig_render_template()
#46 /core/lib/Drupal/Core/Render/Renderer.php(433): Drupal\Core\Theme\ThemeManager->render()
#47 /core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#48 /core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(162): Drupal\Core\Render\Renderer->render()
#49 /core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#50 /core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(163): Drupal\Core\Render\Renderer->executeInRenderContext()
#51 /core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse()
#52 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
#53 /core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(142): call_user_func()
#54 /vendor/symfony/http-kernel/HttpKernel.php(174): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#55 /vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#56 /core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle()
#57 /core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#58 /core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#59 /core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#60 /core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#61 /core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#62 /vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#63 /core/lib/Drupal/Core/DrupalKernel.php(718): Stack\StackedHttpKernel->handle()
#64 /index.php(19): Drupal\Core\DrupalKernel->handle()
#65 {main}
I can confirm it goes back to D7, version 7-3.6 and the latest dev version.
Stripes based on Content types show up, while stripes based on Taxonomy terms are missing from the output entirely.
The Legend block is showing up correctly, listing Taxonomy terms and their assigned colors (it's not the same code origin), Views Format Calendar Entities is working correctly too.
Maybe it's related to PHP version adjustments?
I found the cause, it was another views that was active on the same page and it didn't appear, I had forgotten about it.
Steps to reproduce
To reproduce getting the log message you can use Standard Drupal installation (Tags Vocabulary).
Here is the export of the Views in question, and the log message on D10 (original message is for D9):
https://gitlab.com/-/snippets/2491413
After you import the Views place the Block "Terms
" into a region of your theme, visit a page where the Block is supposed to be visible and it will trigger the log message.
Views still output correct results (on the test site as well as on the site where the whole setup makes sense), the only downside AFAICT with this particular setup is the log message.
Other conditions:
"Specify validation criteria" under "When the filter value IS available or a default is provided" must be turned ON to trigger the message.
If it's left to "Basic validation" the Page where the Block is shown is WSOD.
If Validator gets set to "Taxonomy term name" it's still showing WSOD on the page with the Block:
> Drupal\Core\Database\InvalidQueryException: Query condition 'taxonomy_term_field_data.name IN ()' cannot be empty. in Drupal\Core\Database\Query\Condition->condition() (line 106 of /var/www/html/viewstest/web/core/lib/Drupal/Core/Database/Query/Condition.php).
If I turn on "Transform dashes in URL to spaces in term name filter values" the page with the Block appears and it triggers the reported message.
"Transform spaces to dashes in URL" under "More" doesn't seem to affect getting the log message.
Let me know if you need any more info.
I was able to get the message to appear again, although it's not consistent when it appears, it's very elusive. Sometimes it's after Views have been saved, sometimes after visiting the Views Page, sometimes after adding new Block to the page and visiting it.
I imported the same Views to a clean install and I can't reproduce it there. I Installed Simplenews because I have it on the page where the message appears and because it seems to be relying on Taxonomy (or it used to?) and I notice I don't have the same Newsletter configuration on the clean install. It may be an upgrade bug, I need more time to test and rule out Simplenews.
@rivimey thank you!
It's
use Drupal\Core\Language\LanguageInterface;
use Drupal\Core\Url;
It's working now, although I'm getting a double slash in the CSS link path https://example.com//themes/custom/β¦
Should the variable be without it?
$variables['mail_css'] = $base_path . 'themes/custom/my_theme/css/mail.css';
@liquidcms it's not working for me, I get a WSOD when I try to send an example mimemail and this in the log:
Error: Class "LanguageInterface" not found in mytheme_preprocess_mimemail_message() (line 41 of /var/www/html/name/web/themes/custom/mytheme/mytheme.theme)
β¦
portulaca β created an issue.
portulaca β created an issue.
Thank you for the suggestion! It does work.
I deleted what I had filled under the Base path in the Contextual filter, set the Link display:
option under Pager
to Page
and the Summary links are correct.
It never occurred to me that Summary option of the Contextual filter counts as a Pager, although it does seem to perform that function.
The way Views interface is organized I assumed that the options under the Pager section are applied only to the pager links that are usually below results. I do see now that the description of the Link display option states its purpose:
Which display to use to get this display's path for things like summary links, rss feed links, more links, etc.
But that isn't so discoverable when setting up the Summary Contextual filter. Base path is one of the specific options of the Summary of a Contextual filter, and it seems reasonable to assume that that option would take precedence over all others. It's a bit confusing that it does actually help with the Summary/Feed situation if the Base path is filled in, but it doesn't if it's left empty.
Is there a recommendation or a most sensible way to set up various Views "link construction" options, especially when dealing with multiple displays shown on the same page?
If I fill in the Base path
under Summary options, and set Link display
under Pager section the Summary links don't work out right, I only get the root path on all of them.
So there must be some logic and conditions about when using the Base path
under Summary is recommended and when Link display
should be preferred.
BTW Link display
name also isn't very intuitive. It even has the Custom URL
option which doesn't vibe well with "display". Maybe "Pagination Base Path" or something similar would make more sense?
I know Views and Views UI are complex, but if someone who has a comprehensive overview of them can suggest how this situation can be improved?
From my perspective in this case it would have helped me if the description text of the Base path
under Summary in the Contextual filter mentioned Link display
option.
Maybe add something like from:
Define the base path for links in this summary view, i.e. http://example.com/your_view_path/archive. Do not include beginning and ending forward slash. If this value is empty, views will use the first path found as the base path, in page displays, or / if no path could be found.
to
Define the base path for links in this summary view, i.e. http://example.com/your_view_path/archive. Do not include beginning and ending forward slash. If this value is empty, views will use the first path found as the base path, in page displays, or / if no path could be found. For more control use the Link display option under the Pager section.
portulaca β created an issue. See original summary β .
Thank you @robcarr for posting this! It works!
For anyone also looking to change the Submit button text and adding a title attribute to it:
<?php
/**
* Implements hook_form_alter().
*/
function mytheme_form_alter(&$form, &$form_state, $form_id) {
if($form_id == 'simplenews_subscriptions_block_simplenews_mycategory') {
$form['actions']['submit']['#value'] = t('Notify me');
$form['actions']['submit']['#attributes']['title'] = t('Receive email reminders about new articles published on this site');
$form['mail']['widget'][0]['value']['#attributes']['placeholder'] = 'myemail@example.com';
}
}
?>