Firepup650
(Firepup Sixfifty)
February 22, 2024, 6:43pm
2
Are you certain that comes from this component? Does it occur in safe mode with only themes disabled?
2 Likes
yes, thats only with this component
Firepup650
(Firepup Sixfifty)
February 22, 2024, 8:55pm
4
If you tried with only themes and theme components disabled via safe mode , then themes are not the issue, it’s a plugin issue. What plugins do you have installed?
Firepup650
(Firepup Sixfifty)
February 22, 2024, 9:35pm
6
That’s a theme, not a plugin. Could you check the admin/plugins page while in safe mode ?
This is likely a side-effect of this change:
discourse:main
← discourse:refactor_theme_field_validate_yaml
opened 06:31AM - 20 Feb 24 UTC
### Why this change?
The logic for validating a theme setting's value and def… ault value was
not consistent as each part of the code would implement its own logic.
This is not ideal as the default value may be validated differently than
when we are setting a new value. Therefore, this commit seeks to
refactor all the validation logic for a theme setting's value into a
single service class.
### What does this change do?
Introduce the `ThemeSettingsValidator` service class which holds all the
necessary helper methods required to validate a theme setting's value
The default value of this component setting should be a string (e.g., "0"
, or the type should integer
).
default: 60
type: enum
choices:
- 70
- 80
- 90
- 100
description:
en: "Choose the height of the header. The choice must be made based on the header_avatars_size + 10px. For example, if the header_avatars_size is set to 90px, the header should be 100px. Default value is 60px."
margin_top:
default: 0
type: string
description:
en: "Choose the distance in px from the header. Default value is 0px."
avatars_border_radius:
default: 50%
type: enum
choices:
- 0%
- 10%
- 20%
However, it’s probably unintentional considering it returns a 500 error. Previously, it seems the value was converted to a string DEV: Centralise logic for validating a theme setting value by tgxworld · Pull Request #25764 · discourse/discourse · GitHub
3 Likes
Firepup650
(Firepup Sixfifty)
February 22, 2024, 9:45pm
8
Strange, considering it didn’t cause any issues on amc, where I installed it and tested it (hence me asking about plugins)
2 Likes
Thank you. I can do anything in my end?
Lilly
February 25, 2024, 2:43pm
10
when was that Discourse instance updated? The pr above was commited on Feb 19, so perhaps the amc forum hasn’t updated since before that.
No we will get it sorted out when a developer has a look at it.
5 Likes
Firepup650
(Firepup Sixfifty)
February 25, 2024, 6:54pm
12
We usually update every few days, I guess we hadn’t updated recently enough though.
3 Likes
I think this has now been fixed in:
discourse:main
← discourse:fix_integer_liked_value_for_string_type
opened 02:10AM - 27 Feb 24 UTC
### Why this change?
```
some_setting:
default: 0
type: string
```
…
A theme setting like the above will cause an error to be thrown on the
server when importing the theme because the default would be parsed as
an integer which caused an error to be thrown when we are validating the
value of the setting.
### What does this change do?
Convert the value to a string when working with string typed theme
settings.
Could you give it a try and see it if works for you now?
5 Likes
This topic was automatically closed after 4 days. New replies are no longer allowed.