I think in Boost this is now a Sass variable
scss/bootstrap/_variables.scss
767:$breadcrumb-padding-y: .75rem !default;
768:$breadcrumb-padding-x: 1rem !default;
769:$breadcrumb-item-padding: .5rem !default;
771:$breadcrumb-bg: $gray-lighter !default;
772:$breadcrumb-divider-color: $gray-light !default;
773:$breadcrumb-active-color: $gray-light !default;
774:$breadcrumb-divider: "/" !default;
scss/moodle.scss
2:$breadcrumb-divider: "▶" !default;
3:$breadcrumb-divider-rtl: "◀" !default;
So you could either set that variable to be an empty string, or use CSS to reset it to an empty string:
.breadcrumb-item + .breadcrumb-item::before {
content: "";
}
David Scotson
Αναρτήσεις που έγιναν από τον/την David Scotson
Two solutions are to write a script that duplicates your SVGs, or to hack the image renderer.
Here's a bug I filed on the issue: MDL-47082
And here's our workaround in the renderer:
https://github.com/moodlerooms/moodle-theme_snap/blob/master/classes/output/core_renderer.php#L1293-L1298
Here's a bug I filed on the issue: MDL-47082
And here's our workaround in the renderer:
https://github.com/moodlerooms/moodle-theme_snap/blob/master/classes/output/core_renderer.php#L1293-L1298
Hi Urs,
is there an issue to follow any work on this?
We've recently moved the Snap theme to sub-theme Boost, and this delay is somewhat annoying for developers.
Workarounds we've employed or things we've noticed:
* we have a grunt task that hits this url: joule2.dev/theme/styles.php/snap/-1/all, this starts the CSS regeneration process as soon as we hit save in our code editors so hopefully it is nearly done by the time we switch to the browser and refresh or load a new page
* we also spotted the tree post process call was taking up a lot of time. We were wanting to skip this in our child theme, but it seems if you set it to null in the child theme, it just uses the value from the parent theme (Boost). Even if you replace the call with a new function that does nothing, it still parses the full tree which is where the time is mostly spent. Hacking the Boost theme
* The time taken seemed to be proportional to the length of the total CSS. Our dev VMs have a whole lot of plugins installed and took an extra 10 seconds compared with a default Moodle install. We also found a few bits of the SCSS code that were using @extend and generating silly amounts of CSS code. We fixed the ones in Snap and also filed a bug upstream about uses of @extend in Boost: MDL-58930
* There are existing PHP extension Sass libraries on github that call the C lib to go faster, though it sounded like they only supported Apache.
We've recently moved the Snap theme to sub-theme Boost, and this delay is somewhat annoying for developers.
Workarounds we've employed or things we've noticed:
* we have a grunt task that hits this url: joule2.dev/theme/styles.php/snap/-1/all, this starts the CSS regeneration process as soon as we hit save in our code editors so hopefully it is nearly done by the time we switch to the browser and refresh or load a new page
* we also spotted the tree post process call was taking up a lot of time. We were wanting to skip this in our child theme, but it seems if you set it to null in the child theme, it just uses the value from the parent theme (Boost). Even if you replace the call with a new function that does nothing, it still parses the full tree which is where the time is mostly spent. Hacking the Boost theme
* The time taken seemed to be proportional to the length of the total CSS. Our dev VMs have a whole lot of plugins installed and took an extra 10 seconds compared with a default Moodle install. We also found a few bits of the SCSS code that were using @extend and generating silly amounts of CSS code. We fixed the ones in Snap and also filed a bug upstream about uses of @extend in Boost: MDL-58930
* There are existing PHP extension Sass libraries on github that call the C lib to go faster, though it sounded like they only supported Apache.
Do the styles appear if you wait a little and refresh the page? Sometimes generating the CSS takes a while, and depending on your web server setup, it might time out before the CSS is ready.
If it still doesn't appear after a while, there's probably an error in your SCSS code somewhere, even a small error can cause your entire CSS to not appear. You should see an error in your error logs somewhere.
I tried pasting the code into the post.scss textbox in Boost and it seemed to work, so the problem may not be that particular snippet of code itself.
You might find that targetting all table's is a little too broad, you may want to try targetting table.generaltable and table.flexibletable, as there are some tables used which are not for displaying tabular data.
If it still doesn't appear after a while, there's probably an error in your SCSS code somewhere, even a small error can cause your entire CSS to not appear. You should see an error in your error logs somewhere.
I tried pasting the code into the post.scss textbox in Boost and it seemed to work, so the problem may not be that particular snippet of code itself.
You might find that targetting all table's is a little too broad, you may want to try targetting table.generaltable and table.flexibletable, as there are some tables used which are not for displaying tabular data.
Hi Schwann,
that will make all images on the page disappear.
You should add a class name to the img tag you add in the Additional Head HTML, then you can use img.classname to hide only that specific image.