I think there is a serious misunderstanding on your side. The mockup has something missing. This is not a design question. If you do not like to see the links in article-content types you can disable the read more links in field settings. Please do not name this design.
Also do not forget about language flags/links and/or statistics counters obly a logged in users can see. So you can have an view counter in logged in state and nothing on public view.
Again, this is nothing about design - it is all about configuration. If you like to hide the read more - disable it in field setzings, but allow others to show it if they have a different opinion.
The fields I tested with allow multiple file and image entries. They are just empty as not ipload has been done yet. However I think it should look the same all times if we think about the outer border.
We do this for all content types and not only for articles.
It was the date_range module that was not enabled.
marc.bau → created an issue.
Tested it, but I cannot see the border?
details.css seems not added to page.
That works. Thanks.
Can confirm ist works.
But why have you removed field-prefix/suffix? It may be a helpful class to address the span if someone may needs to customize it.
I agree there is always room to improvements, but the current look and featl very basic and makes most people just uninstalling it. :-) I do not like the word "base theme" in this context.
I think it can still look very modern and nice out of the box like Claro. This safes a lot of effort as developer do not need to design everything on thier own for no need. I think that was mainly the reason why I personally never switched to Bario theme.
Please try to make the theme look great out of the box like core themes.
Not sure why it is still not using the full width as the CKEditor really needs a lot of space.
With the update the tabledrag cross (first column) is not shown in node edit form.
There is a typo in the .info file... two "cc"
ccore_version_requirement
After updating to latest DEV i get this in D10.3.3:
Drupal\Core\Extension\InfoParserException: The 'core_version_requirement' key must be present in themes/contrib/bootstrap/subthemes/bootstrap_subtheme/bootstrap_subtheme.info.yml in Drupal\Core\Extension\InfoParserDynamic->parse() (line 67 of core\lib\Drupal\Core\Extension\InfoParserDynamic.php).
Thanks for working on it. I think you added a new issue. This path fails for sure on my development machine. url(/themes/contrib/bootstrap/images/help.png);. Make it relative and it should work. Same issue like the mime type image paths.
What about the bootstrap.min.css? Should this have a different weight?
marc.bau → created an issue.
marc.bau → created an issue.
marc.bau → created an issue.
marc.bau → created an issue.
marc.bau → created an issue.
I think it would be perfect to migrate all previous settings. A clean upgrade should map all previous settings to the new and set good defaults to what is missing.
Manually fixing many views is really a lot of work and if this can be a smooth upgrade I‘ more than happy like many others who are also affected.
Just one simple example. Clone bootstrap_subtheme. Style.css has no weight defined by default.
Add this to css new subtheme style.css
.btn-default,
.btn-default:hover {
color: #fff;
}
It gets overridden by _banner.scss and the color becomes blue.
Core styles should be disabled, so no risks on them.
I see many core CSS files loaded?
Furthermore, your custom theme styles order could be set on the subtheme.
I can change the wrong order, but I refer to code example bootstrap_subtheme many will use as a default start point like me.
I also suspect (not tested) that the SASS subtheme also has a bug about this as ../../contrib/bootstrap/ looks incorrect to me.
Replacing /themes/contrib/bootstrap/images/ with ../../images/ works in both uncompressed and compressed CSS.
marc.bau → created an issue.
I'm now able to edit the view - what is great. But the view still shows
Oops, something went wrong. Check your browser's developer console for more details.
Is this fully fixable with an update hook?`
I guess it is caused by the card field settings. I have seen all fields title / content / image have been lost.
marc.bau → created an issue.
@shelane: You can set a weight in theme libraries of -100 and you are before core if I remember correctly. Your css_alter works the same way :-). There are default value for core/modules/themes, but you can always change the weight and jump in every position you need.
But here - the theme need to make sure it is properly positioned first... otherwise - possible chaos.
This is not a support case. This is a defect in the theme.
Have you disabled aggregation and verified the order of files?
Why are you saying than this is not a defect? I do not get it.
I'm sorry, but it need to load last. Other files ordered after my style.css are overridding my style.css because of wrong order. My custom changes are the last order...
That looks visually exacly like the issue I reported. Great you have been able to fix it.
The difference with Logo image is that logic to adjust the file dimensions on upload should still be there.
Please also do not forget that uploading SVG files must be forbidden where setting a path to a SVG file need to be allowed.
I have 8 other roles. What permission do you mean?
marc.bau → created an issue.
The question however, is how is the upgrade process between version 8.x-3.32 and 5.0.0-beta1? I'm pretty sure it is not a simple step of changing the version number in composer.json...
This is more or less a rebuild from scratch.
Just from real live - I just banged against views_bootstrap... installed 5.x and several views made for 3.x crash and say a plugin is missing... well that plugin no longer exists in views_bootstrap B5, but the worse issue - I cannot edit the old view at all to fix the issue... I think I need to install views_bootstrap 3.x again, edit the view to a core plugin and than install views_bootstrap 5.x again to follow up. I hope the views_bootstrap team may solve this somehow with an update hook. Just be warned :-)
themes/contrib/bootstrap/js/bootstrap.js is a file that exist in B3, but dot not in B5. But the references to the file still exists in code. That is the reason why this error bubbles up. Only the reference need to be removed I think.
In my specific example it is not about a CSS class only. I have a content type that need to change the HTML code.
Lets say
- HTML Layout A for item number 1,3,5,7
- HTML Layout B for item number 2,3,6,8
There is no theme suggestion, no class, no zebra and I have no idea how to solve this now...
The changes are somehow massive, so I cannot use CSS only to implement the layout changes.
Perfect. Thanks!
It is common that print views only who useful content and not navigations. If you need the navigation for documentation reasons or mockups you can make screenshots and print these. But in all other cases a user like to print the page content and not navigations bars.
@joseph: I also have a B3 theme in D7, but learned in last week that a migration these B5 is not that difficult than I expected it first. It is still a lot of effort to switch from D7 to D10 as all templates need to be redone (this stresses me a lot), but the CSS stuff seems not that difficult to migrate to B5. I love to hear you spend time on the jquery issue when I thought last week - this is not going to happen (as there was a note - D10 is the last that will work with B3), but now I started with B5 and I think - everyone who can or is redoing a site should move and not stick at B3 that is end of all from bootstrap side.
The only reason why people are not upgrading in last 5 years (at least me) is there is no B4/B5 in the project available and I do not like to move to bario or any others. It looks like the previous main bootstrap theme maintainer became very inactive ~5 years ago and this is also the reason why the statistics show that 8.x-3.x is the most active. Nobody can use something that does not exist.
Moving to SDC can only be good.
Same here - "Format: Bootstrap Grid - Settings were straight out of the box - no changes."
Well, my websites should not depend on external servers. All files must come from my machine.
marc.bau → created an issue.
Not really clear. There is no note about 5.3 and 5.4 releases - only about 8.x-3.x and 8.x-4.x what is not the same.
- Versions
- 8.x-3.x
- Twitter Bootstrap 3.x. for Drupal 9/10
- 8.x-4.x
- Twitter Bootstrap 4.x for Drupal 9/10
- 5.5.x
- Twitter Bootstrap 5.x for Drupal 9/10
- 7.x-3.x
- Twitter Bootstrap 3.x
- 7.x-2.x
- Twitter Bootstrap 2.x
Latest bootstrap 5.2/5.3 only works with module v5.5. Reason seems to be classes named with „bs“ and only 5.5 has a correct template.
Have seen the same issue and not found a solution yet.
marc.bau → created an issue.
marc.bau → created an issue.
marc.bau → created an issue. See original summary → .
marc.bau → created an issue.
marc.bau → created an issue.
marc.bau → created an issue.
marc.bau → created an issue. See original summary → .
marc.bau → created an issue.
marc.bau → created an issue.
I found the reason now... but looks like a defect. The Configure Header: Global: Text area had no Text format configured.
After setting to Full HTML the titles are showing now.
marc.bau → created an issue.
marc.bau → created an issue.
I have *many* modules in alpha and beta versions installed and none was blocked by a minimum-stability blocker.
You click the "Add view" button and create your own by hand - and save it later in the database. Than you translate the stuff... and now I need the translation on a different system and how I can export these translations?
I translated several custom views from English to German in a development system. But I cannot find a way to export my dev translations to import them into the production system. That means my hard translation work get lost.
How can I transfer the translations of my custom views (not the module) to other systems? I simply cannot find the translated strings in any export I tried out.
Well, but why is this needed? I tested the software and it looks working for me. I may found some issues, but they all look not that dramatic that blocking the installation is needed.
Maybe the maintainer could explain why he think the module is so unready that it need to be so complicated. There are other alpha modules around that can be installed without changing the composer file manually.
Looks more like a config issue / usability issue.
Setting:
Image style for content: Hide (do not display image)
Image style for first image in content: 640x640
And all content images are hidden, but the first is shown.
I also need this and can confirm that this was a basic feature in D7 that is now broken in D10.
As I have no idea about the code - may the maintainer re-implement this soon, please?
marc.bau → created an issue.
marc.bau → created an issue.
The 100% width is also causing the issue in #3471683
marc.bau → created an issue.
marc.bau → created an issue.