@NateDhaliwal ok, dank je wel voor het uitzoeken! Best jammer, want we vonden deze TC erg leuk, maar als het niet mogelijk is om het op te lossen en op onze site te hebben, laat ik het voorlopig gewoon weg en kijk ik naar andere manieren om de categoriekoppen er mooi uit te laten zien.
@jackierenee I have taken the liberty to step in and have a look at your site.
It seems you had only removed the theme component from the parent theme, updated it and added it back.
The problem is that Discourse does not recover when a theme component is updated beyond compatibility and after that a pin is added.
The correct way to recover from such a situation is:
- go to the theme component
- scroll all the way down
- copy the settings from “settings editor”
- store them in a text editor
- completely remove (
delete) the theme component - add it back from the Github repository
- copy the settings from the text editor and paste them in “Settings editor”
- make corrections if you have to (sometimes settings are added in the new version so you have to remove them again, the editor will tell you what to do when you try to save them)
- add the theme component to the parent theme.
I have done this on your site and the banners are now showing again.
For theme component authors: it helps a lot if you utilize the version field in about.json so it is actually visible to the administrator on what version a theme component is. Unfortunately Discourse does not show commit versions for theme components as it does with plugins.
8 likes
That seems polite. I’ll endeavor to add a github action that will automatically update a version at each new commit to main.
4 likes
You should be able to easily achieve that by using the Show category name setting of this Theme Component - it is designed specifically for your use case.
Sounds like a very good idea! Please document how to do this, and add to the Developing Theme Components for Dummies guide (if there is one).
I’ve tried it - all of my concerns have been resolved, and it looks great. Nice work!!!
Hey, how hard would it be to add the ability to specify how many paragraphs of the About topic to utilise for the description? Personally, I find the single paragraph quite restrictive and would love to be able to specify (perhaps per category) how many paragraphs to utilise.
Lastly (while still focused on this TC), do you think it would be good to more the “Read more…” to the end of the last paragraph? That would certainly save a lot of wasted space in my instance. But then again, if we could use multiple paragraphs it might clash somewhat with the second paragraph if it was links and the like. 
.
Hmm… the way the code accesses the category description is using this.args.category.description. IIRC it already comes as 1 paragraph. I’ll take a look into it. Perhaps I could do a fetch() or ajax, but that may be alower.
Maybe a setting to select if it’s inline or not? Let me take a look.
1 like
Hallo, ik merkte dat de lettergrootte van de categorie-tekst, wanneer ingesteld op “kleiner”, niet wordt meegenomen, deze is altijd groot (gebeurde volgens mij één of twee dagen geleden).
We hebben het zo aangepast dat de categoriebeschrijving kleiner of groter was dan de standaard in de kern (die recentelijk lijkt te zijn toegenomen).
Ik zal dubbel controleren of er geen thema-conflict is dat hier een misleidende aanwijzing was.
1 like
Hi @RGJ thank you so so much for this! I had no idea that theme components worked this way. I will definitely keep this in mind if we run into this situation again. Really appreciate your help! 
2 likes
This is a very rare and specific situation, with odd behavior, and hopefully we’ll not encounter this for a while!
3 likes
Hallo, ik heb het probleem met die CSS opgelost:
.category-title-description .cooked {
font-size: small;
}
Ik krijg ook lege categoriepagina’s op desktop- en mobiele browsers (Discourse versie 3.5.0.beta8-dev) wanneer dit onderdeel de volgende instelling heeft:
“setting”: “show_mobile”,
“value”: false
Wanneer ik het terugzet naar de standaardinstelling (true) worden de pagina’s correct weergegeven.
De console toont de volgende foutmelding…
Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating ‘this.site.mobileView’)
…wat gerelateerd is aan…
/discourse/theme-javascripts/theme-3/discourse/components/category-header.gjs)
…en de betreffende regel is regel 3 (const hideMobile) hieronder:
get showHeader() {
const isException = this.args.category && settings.hide_category_exceptions.split("|").includes(String(this.args.category.id));
const hideMobile = !settings.show_mobile && this.site.mobileView;
const subCat = !settings.show_subcategory_header && this.args.category.parentCategory;
const noDesc = !settings.hide_if_no_category_description && !this.args.category.description_text;
const path = window.location.pathname;
return /^\\/c\\//.test(path) && !isException && !noDesc && !subCat && !hideMobile;
}
Enig idee waarom dit gebeurt?
1 like
Dat zou technisch moeten werken… die regel stond er zelfs vóór de update. Ik zal het bekijken.
@HTW Ik heb een oplossing doorgevoerd. Laat het me weten als het nu werkt!
1 like
Opgelost. Hartelijk dank.
Er lijken recente kernwijzigingen te zijn in de categoriekoppen, wat betekent dat de kernkoppen niet langer verborgen zijn wanneer u deze component gebruikt.
Moeten we proberen deze component af te stemmen op de stijlwijzigingen in de kern?
3 likes
Hmm… wat zijn de wijzigingen hier? Misschien een screenshot? Bedankt.
With the TC active on a freshly updated site (clearly the styling has gone a little crazy):
With the TC inactive:
1 like
Heb ik er nu !important aan toegevoegd… werkt het nu?
2 likes
Kleine opmerking: De tekstgrootteopties voor de beschrijving zijn nog steeds te groot. Zelfs de “kleinere” optie gebruikt var(--font-up-2). Is er een kans om var(--font-0) (“kleinste” of “standaard”) als optie toe te voegen.
Of zouden jullie een PR hiervoor accepteren?
1 like
@jrgong I just merged a PR that adds a ‘smallest’ option, with the value of $font-0. Let me know if you encounter any issues!
2 likes