I can't set default backbround or default theme and a lot of html tags in instance pannel no longer work.

Something between bbb91d8a...391f796c broke my ability to set default background, set default theme, and have HTML tagss in my instance panel.
I use /static/config.json to set the defaults for my instance.

I have background: set to "/media/4dbe80b15103267c727f0ff2c4ea90e911abde8966c5993a5f1c10ba431634be.jpg?name=neon_city.jpg" which then returns a 302 to my object storage.

I have theme: set to "wavemaster"

And I have an <iframe>, a <table>, and an <h3> in /instance/panel.html that no longer work and result in a broken af panel.

Now instead of looking like this:

screenshot

It looks like this:

screenshot

I have no clue why it's displaying my "retro" theme by default.

Update: Had wrong commit.
Update 2: Nevermind I'm retarded. I forgot about merges for a sec.

changed the description

looks normal to me, maybe it fails to load image that is too big?

That wouldn't really explain the html tags in the panel or not setting the correct theme. The background image is only like 700~800 kB.

My instance currently looks normal because I've reverted back to bbb91d8a where everything still works.

instance panel, too huh? that's weird. is your BE up to date?

Yep. BE is more up-to-date than FE at the moment because I've had this issue for a day or two now.

changed the description

is it possible the static dir is pointing to the wrong place?

No. Apparently updating the FE pulls config settings from pleroma's config file even though config :pleroma, :instance, managed_config: is set to false. That explains the background and theme but I think the html in the instance pannel is a different issue entirely.

Not sure why current FE is pulling settings from pleroma's config instead of the /static/config.json.
I really doubt it's a BE issue because if it was checking out a previous commit of FE and rebuilding it without even restarting Pleroma wouldn't fix it but it does so I'm pretty sure this problem is limited to FE.

then it's most likely the recent statusnet config deprecation branch that has changed how it works

I can investigate to see what differences there are but man we have way too many things to configure shit lol

Thanks m8
This also needs to be a test

it's tricky because the configuration stuff doesn't have clear responsibilities between the BE and FE, and the dev server works differently than live servers, but I'll try to see what can be done

Yeah, I know. It doesn't boot up a pleroma server to put behind the fe so testing stuff like that is hard and testing FE against BE isn't a great idea. At least you have people like me testing this on live servers in prod before it gets pushed to stable.
However, now that we have the whole /instance/ dir in Pleroma I don't really see a reason to manage this stuff on BE as admins can just put all their settings in /opt/pleroma/instance/static/static/config.json and still use the bundled FE without having to edit tracked files.

I'm not sure but I thought the config.json was being deprecated in favor of storing settings in the backend, which allows for things like being able to change them in the admin FE etc. regardless I wish it was simplified, I'm currently trying to figure out the conditions to use the static/config.json at all apart from testing scenarios lol

Oh, that makes sense. That'd also allow being able to change stuff without downtime which is the main reason I use the config.json
Still, admin-fe needs an easy way to define custom settings as I have a few things custom in my config.json and prod.secret.exs and I don't really want to maintain a fork of admin-fe just for a few minor changes I've made.

@lambadalambda @rinpatch I'm not sure but if I'm reading the BE code right, managed_config param only seems to affect the old statusnet/config.json response?

yes, that's true.

do we want some sort of compat with '/api/pleroma/frontend_configurations' so that either BE omits the pleroma_fe specific stuff when managed_config is disabled, or just make it set a flag "useStaticconfig: true" or something?

mhh... yeah, something like the latter sounds like a good idea.

if i understand correctly BE doesn't honor the disabled managed_config when inlining resources, so if you used to use /static/config.json in FE, that won't work anymore, and FE's code is such that it will only give priority to static/config.json in dev server mode if you cofigured it so.

ideally BE should also inline the /static/config.json into the preload data, at least if managed_config is disabled

if managed_config worked with api/v1/instance then I don't think inlining or not would make any difference if I understood how it works correctly. basically that option seems to change statusnet/config to not return any actual configuration, forcing the FE to fall back. if the setting worked, the the inlined configuration should be just as empty as the one fetched via the endpoint manually

I think the panel issue might be there because of the preloading stripping out stuff it shouldn't strip out. I'll take a look at it.

the wrong panel is preloaded, fixing.

Fixed in pleroma!2692 (merged)

Thanks bby

Didn't fix it. It just seems to have changed the brokenness.

Edit: This is with current fe develop and this issue hasn't been fixed yet so that could also be the issue. Not sure.

There were two bugs, second one was also fixed just now.

mentioned in issue #885 (closed)

closed

This was marked as closed but it still isn't pulling the default theme or the background image from the config.json

screenshot

The instance panel now works correctly though

I guess in the mean time I can just copy my config.json into my prod.secret.exs for the time being now that the panel works again. Not ideal but it should be good enough for now I suppose.

reopened

added Bug label