robbnl → created an issue.
Hi,
Thanks for getting back to me.
For me it works.
Let me first explain what I did without this module:
I have a view page that I want to use to show random content. There is a setting for views to disable cache but that only works if I am showing the content in a block. So to have that page load random content I had disabled caching altogether with the development option. And that works, with every page load I get another random content item.
But since I only need this for one page I was looking at the cacheexclude module.
I have updated the info.yml file to include version 11 and installed it on my site.
I have disabled the development caching setting and verified that with each page load it was not loading random content.
Then I added the view's path to cacheexclude and now that page is no longer cached and with each page reload shows a different content item.
So as far as I can tell this module works with version 11.
If there is anything else you would want me to check to verify then let me know.
If you can indeed create an official release that reflects that then others can also without tweaking install the module and use and test it.
Greetings,
Rob
Hi thanks for getting back to me.
It now works and I learned something.
I had the development settings enabled to not cache markup, but with that enabled stylesheets are still cached.
I had expected that nothign would be cached but that's clearly not the case.
So after clearing the cache my lines in the custom stylesheet where picked up.
Greetings,
Rob
Hi,
For me this is solved.
There was something in the instructions for creating a sub theme that was incorrect and updated.
https://www.drupal.org/forum/support/theme-development/2025-02-17/subthe... →
But my major flaw was that after following hte instructions my sub-theme worked but it was using all the base-theme defaults. That of course makes sense but I just didn't know at that time.
Greetings,
Rob
Yes, it indeed looked exactly the same but with all the basic (read: no) settings.
Which might make sense but I didn't know
Hi,
It now works. I had never created a sub theme and I was unner the impression that the sub theme would use the same settings configured for the base theme but that is not the case. The sub theme does inhertit the possible settings from the base theme but they all are set to the defaults. Therefor nothing that I was using on my site was implemented. I have now configured the exact same settings and the layout of the site starts to look at what it was.
So I believe I will now be able to find the rest
Thanks
Rob
Hi,
Thanks for your input.
If I indeed follow this syntax:
global-styling:
css:
theme:
then when I add code such as the red background then indeed I get a red background.
But none of the css styling from the base theme is processed.
Greetings,
Rob
Hi,
Ok, but am I correct in thinking that I do not need to copy any css files from the base theme to my sub theme? Because that would seem redundant.
Greetings,
Rob
Hi,
I have created a folder under web/themes/custom/zeropoint_custom
And then I have these files:
zeropoint_custom.info.yml
name: 'zeropoint_custom'
description: 'Customizations for the zeropoint theme'
type: theme
core_version_requirement: ^8.9 || ^9.3 || ^10 || ^11
base theme: 'zeropoint'
libraries:
- zeropoint_custom/global-styling
# Regions
regions:
page_top: 'Page top'
topreg: 'Top region'
header: 'Header'
primary_menu: 'Primary menu'
secondary_menu: 'Secondary menu'
breadcrumb: Breadcrumb
user1: 'User 1'
user2: 'User 2'
user3: 'User 3'
user4: 'User 4'
sidebar_first: 'Sidebar first'
sidebar_second: 'Sidebar second'
help: 'Help'
highlighted: 'Highlighted'
content_above: 'Content above'
content: 'Content'
content_below: 'Content below'
user5: 'User 5'
user6: 'User 6'
user7: 'User 7'
user8: 'User 8'
tertiary_menu: 'Tertiary menu'
footer: 'Footer'
footer_right: 'Footer right'
footer_below: 'Footer below'
page_bottom: 'Page bottom'
zeropoint_custom.libraries.yml
global-styling:
css:
component:
css/style.css: {}
When I then place Twig-templates in a templates folder in my subtheme they are loaded right away. But the CSS and JS components from the base theme are not loaded.
If you have a suggestion then please let me know. I do also hope the maintainer of the zero point theme will respond and if so I will update this issue too.
Greetings,
Rob
I have created another view that doesn't show fields but in stead show content, that allows me to use a twig template and gives me much more control on what to display.
robbnl → created an issue.
Hi, same there here.
After a default installation of Search API and adding Taxonomy terms to the index they where not found/indexed.
Disabled the processors, saved, enabled them again, reindexed: problem solved.
Hi all,
I found that the label is configured in the settings of the filter criteria.
In that setup the label was Search.
When setting up the default view with a search input the chosen labels are in English and not translated. I also found that the header was in English. Not a big deal but I had thought these would have been in my chosen local language.
I have attached a screenshot of where this label can be found if others would seek the same.
Greetings,
Rob
Hi,
This was solved for me within the Zeropoint theme:
This goes into the custom-style.css:
#sidebar-left input.form-text,
#sidebar-right input.form-text,
.block-search input {
box-sizing: border-box;
width: 100%;
}
I have tested this with my main site that runs Drupal 10.4 with Zeropoint 8.x-1.24 and the SearchAPI module 1.37 . When using the narrow or narrower right sidebar size the SearchAPI input text box fits into the placed block.
So this issue is now solved
Hello Florian.
Thanks for diving into this issue.
I can confirm that the code you just shared via email works:
#sidebar-left input.form-text,
#sidebar-right input.form-text,
.block-search input {
box-sizing: border-box;
width: 100%;
}
I have tested this with my main site that runs Drupal 10.4 with Zeropoint 8.x-1.24 and the SearchAPI module 1.37 . When using the narrow or narrower right sidebar size the SearchAPI input text box fits into the placed block.
Great,
Thanks,
Rob
Yes, go ahead and close it, thanks
Hello Florian,
Thanks for your prompt reply.
I believe the problem only exists with the Search API module. Is the screenshot you attached from a site with the core search module enabled? Because on another site where I use the default search module I don't have a problem because the default search module uses a text box with size="15" and Search API use a text box with size="30".
So in the end I don't think it is a theme problem?
It is how I explained in my initial description, so if it is indeed not something that will be fixed in the theme I will create an issue for the Search API.
I have installed the dev version, tried with the addition in custom-styles.css and cleared caches. But that doesn't help. I have added another screenshot.
Greetings,
Rob
Hi,
I believe I am running into the same issue.
After installing Simpleads three days ago cron stopped working.
The errors I get are:
TypeError: Cannot access offset of type array on array in Drupal\Core\Database\Query\Merge->key() (line 331 of ******************/core/lib/Drupal/Core/Database/Query/Merge.php)
#0 ******************/modules/contrib/simpleads/src/SimpleAdsCron.php(96): Drupal\Core\Database\Query\Merge->key()
#1 ******************/modules/contrib/simpleads/src/SimpleAdsCron.php(79): Drupal\simpleads\SimpleAdsCron->runAggregation()
#2 ******************/modules/contrib/simpleads/simpleads.module(69): Drupal\simpleads\SimpleAdsCron->init()
#3 ******************/core/lib/Drupal/Core/Cron.php(275): simpleads_cron()
#4 ******************/core/lib/Drupal/Core/Extension/ModuleHandler.php(307): Drupal\Core\Cron->Drupal\Core\{closure}()
#5 ******************/core/lib/Drupal/Core/Cron.php(258): Drupal\Core\Extension\ModuleHandler->invokeAllWith()
#6 ******************/core/lib/Drupal/Core/Cron.php(97): Drupal\Core\Cron->invokeCronHandlers()
#7 ******************/core/lib/Drupal/Core/ProxyClass/Cron.php(75): Drupal\Core\Cron->run()
#8 ******************/core/modules/automated_cron/src/EventSubscriber/AutomatedCron.php(65): Drupal\Core\ProxyClass\Cron->run()
#9 ******************/vendor/symfony/event-dispatcher/EventDispatcher.php(246): Drupal\automated_cron\EventSubscriber\AutomatedCron->onTerminate()
#10 ******************/vendor/symfony/event-dispatcher/EventDispatcher.php(206): Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}()
#11 ******************/vendor/symfony/event-dispatcher/EventDispatcher.php(56): Symfony\Component\EventDispatcher\EventDispatcher->callListeners()
#12 ******************/vendor/symfony/http-kernel/HttpKernel.php(114): Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
#13 ******************/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(63): Symfony\Component\HttpKernel\HttpKernel->terminate()
#14 ******************/core/lib/Drupal/Core/DrupalKernel.php(683): Drupal\Core\StackMiddleware\StackedHttpKernel->terminate()
#15 ******************/index.php(22): Drupal\Core\DrupalKernel->terminate()
#16 {main}
I was wondering if there is already a solution to this problem?
Greetings,
Rob
Hi, thanks very much, this is indeed what I was looking for.
Happy that it can be fixed in the theme settings.
Greetings,
Rob
Hi, thanks for getting back to me.
Don't know what the problem is with the screenshots, I see them with my post. So I don't know what to do about that.
But if you want to you can see this behavior on one of my live websites: https://drupaltips.eu/
If you look at the blocks on the right hand side onder the title: Content Categories you will see this strange occurence right above the first item Bulk Edit.
Hope this helps,
Greetings,
Rob
I have now updated the site from drupal 10 to 11 but there it is the same. So I now have everything at the latest version including zero point at v8.x-1.24
If I inspect the input field it comes up as:
input data-drupal-selector="edit-keys" type="text" id="edit-keys--2" name="keys" value="virtual desktop" size="30" maxlength="128" class="form-text"
I have attched a screenshot of this
Maybe this is something that is not an issue with the theme but maybe with the search API module? Or something else?
If it's not with the theme I hope you can point me in the right direction
Hi there,
I see this request has been marked as fixed.
I see in the changes that there is a reference to the following in z_style.css
.block-search input {
box-sizing: border-box;
width: 100%;
}
So if that is to solve my problem that the seach form input would be resized then I don't believe that fixes my problem yet.
I am using the Search API module and the enabled block for the search form shows in a block in the right sidebar.
When I choose wide it fits but if I choose normal the search form doesn't fit. I have attached a new screenshot.
I have tried to update my custom css file with a width of 50% for the entry block.search input but if I do so nothing happens.
I hope it is possible to update the theme so the Search API form can be used in a smaller block than normal.
Greetings,
Rob
I was already using Twig Tweak but was not using it for this purpose yet, thanks for pointing me in the right direction.
What I now have is a content type with a field_city that references a taxonomy term city
In my twig template for the conent type I then use the following statement:
{{ drupal_entity('taxonomy_term', node.field_city.entity.id, 'city') }}
This provides access to the city and it's referenced country. I have then used the suggested twig templates for the city and country view modes and. field names to display them in my chosen format.
And this is exactly what I needed.
Hi,
Thanks very much for the very thorough explanation. This does allow me to automatically access the country information when I show a city taxonomy term.
What I can't seem to do with this approach is to access the country information when I display a content type. If I only have the City taxonomy term linked to the content then the country taxonomy term that is referenced by the city does not become available when I show content. I will further investigate the variables I get within my twig template.
Greetings,
Rob
Hi,
Thansk for the tip to look into the database. I will do that in the upcoming days. I had to move on with the website so I reverted back to the default Search module and used the Content Exclude module to disable some content types from being indexed.
The words I mentioned are not in the stopwords list so I will check if they are in the database when I am going to do maintenance and try to implement search API again.
Hi,
Thanks for the responses. I don't have time the next few days to check this on a fresh install of 10.4.
What I can say is that for me also if I uninstall the bigpipe module I no longer have this problem and I can again use the editor.
I do not have any extra CKeditor plugins installed on this site
I have been investigating this further with the limited knowledge I have. I find that when I inspect the element it refers to:
<!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'themes/contrib/zeropoint/templates/form/input.html.twig' -->
So I would think that I can change the attributes for the input text field in input.html.twig.
I do however have no clue of the syntax that I should use in that file to change the size of the input text field.
I have been searching for examples on-line but have not found anything that explains or shows examples of the syntax to use
Help on this would be appreciated.
Greetings,
Rob
Hi,
Yes, thanks for pointing me in that direction, this allows me to add a taxonomy term as a field and dynamically add values.
Thank you very much
Hi Florian,
Yes, thanks that was what I was looking for.
I have placed that pice of code in the custom-stule.css in the _custom folder and it works.
I did find that I have to disable the aggregate css function for the customized settings to work.
Hi,
Thanks for looking into this.
I was not sure how to apply the patch. I searched for procedures to apply it to the ace_editor files through a git command but with the examples I found on line I was getting different errors.
But when I looked at the syntax of the patch file I found that it just adds this line to the js dependencies:
- editor/drupal.editor
So I have manually added that line to the ace_editor.libraries.yml file and that works.
For anyone also applying this don't forget to clear your cache under Configuration - Performance.
Thanks for your support.
Rob
Hi Chi,
Thanks, this works.
Greetings,
Rob
Hi,
Thanks for creating the patch. Not sure why it didn't do what I wanted though because my knowledge of css is not in depth enough.
I created a workaround with a block with a certain size placed in the header-region. That way the header also adopts to that height.
Greetings,
Rob
In addition to my request I found that when I disable Aggregate CSS files under the Configuration - Performance options the customizations from custom-style.css are processed.
So that allows me to change the height and the header image as described.
However the toal height of the header is not adjusted, the main menu stays in the same place and a grey area exists under the menu.
I have attached a screenshot
So I do believe another setting will have to be adjusted too but I don't know which one.
Hope someone can help,
Greetings,
Rob
Hi, thanks for your reply, with that patch it will work with v10 but I don't think it is future proof to start building my site with a module that will no longer be maintained and where I would have to depend on a possible patch.
After some research I found that the Token and Token filter modules do exactly waht I need. In my inpunt field I can use a token in the following format:
<input type="date" name="date" value="[current-date:custom:Y-m-d]">
And then I get the current date.
I have now deployed my site under development with v10 and this now all works as it was before in the pre v8 era but then with the new supported and maintained themes and modules.
Hi,
Thanks for the response. The php filter module is no longer supported with v10. I had installed it and then the checkbox to enable it remains grayed out and the accompanying text says that it can not be used with v10.
Greetings,
Rob
I found that I can use that small php code piece when I use the PHP filter in drupal 9. I can see why it has been removed from drupal as a security measure because users can execute php code. But I don't have users, it's just me maintaining a simple site.
I read that I have to create a module to execute such PHP code. But to me that sounds like overkill for something simple as this.