It’s showing me below error. hot to fix it?
btw, after I add TOC in a topic, I need to refresh the page, otherwise the TOC link is not working. is this a normal behavior?
It’s showing me below error. hot to fix it?
btw, after I add TOC in a topic, I need to refresh the page, otherwise the TOC link is not working. is this a normal behavior?
Hey @Yt.w, thanks for the report. I couldn’t reproduce the issue you mentioned. Do you still observe this behavior? If so, could you please provide more details on the steps to reproduce it?
From what I can see, refreshing the page to rebuild the HTML is expected behavior. While it might be possible to avoid this, it would require changes to how the component currently works.
Hello, I still observe this behavior, and it actually occurred immediately after I installed my current instance. I didn’t make any changes.
My other instance doesn’t have this issue, so it’s quite confusing for me.
From a UX perspective, I believe it’s better to avoid refreshing the page to keep the TOC active.
@Yt.w can you show me your browser console when you have this error please? Expand the error too.
I have this exact same error on one of the three sites I am hosting in a multi-site set up which leads me to believe one of the settings I have in that site is making this happen. I have not yet determined which setting but when I track it down I will circle back and update the post, I just wanted to add that I am also seeing this in the wild on the latest tests-passed release.
This is what is in my console and it is all things I am used to seeing for better or worse
thanks, we are still struggling with an exact repro, we are unable to make this happens on our multisite hosted sites.
This may or may not be a red herring, I haven’t had enough time to dig but when I remove and re-install the component I consistently get the following error:
The field number changes I presume because it is being installed as a different component number on every re-install of the component. I will continue to dig but this doesn’t happen when I do the same with any other components…
My current suspicions is that the failure is in part due to me backing out some S3 changes I made specifically on this site at some point. @Yt.w any chance you also used S3 at some point on your install?
Alright I was able to get the error to go away and reproduce it.
DISCOURSE_USE_S3: false
does not stop Discourse from using S3 paths, this feels like a bug or this setting doesn’t do what I think it does.Initially what I did was revive my minio setup, uncommented the config options in my app.yml, rebuilt the app, and made sure to run the s3:upload_assets task. Once the site was back up I navigated to the components section. The already installed DiscoTOC component still showed the error, however, when I deleted it and re-installed it the error did not resurface. During the DiscoTOC component installation sprite.svg was requested from my S3 server.
As part of trying to reproduce the problem I ran into an interesting issue. It seems when l leave all the S3 directives in my app.yml active, i.e. not commented out, but set ``DISCOURSE_USE_S3: false``` the site frontend will not load if minio is not running.
Perhaps DISCOURSE_USE_S3: False
is not meant to disable all S3 access, I assume it does based on the name but clearly it doesn’t. As soon as I restart the minio service and refresh the frontend everything works fine. I also am able to uninstall and install the DiscoTOC component without reproducing the error in this state. This seems like at least potentially one bug.
Here is the third state that lead me to the reproducible error.
In order to get my site to work without minio running again I commented out all of the entries that had anything to do with S3 in the config. Then I rebuilt the app and now with minio not running the frontend loads without a problem. However, if I uninstall and re-install the DiscoTOC component the error shows up again. I also tried just starting up minio in this state but the error showed up again on re-install. Most likely due to the fact that there were no S3 directives anywhere set in app.yml and so even if it was trying to reach out to S3 behind the scenes it would do it using default values rather than a working set up. It does, however, seem that some images are still trying to be served from S3 even after a posts:rebake. (e.g. 1531a70abda0d81d1a4039b6f3fa38bea79ef0de_2_180x180.png/xl.meta)
Yes, The forum that had issues was using S3(B2), while the forum that had no issues was not using S3.