also: removed [censored] from censor list!
Edit: ok! that's broken too... Leaving it because jeez.
also: removed [censored] from censor list!
Edit: ok! that's broken too... Leaving it because jeez.
This is totally fair criticism. I'll bring it up with the other admins to see what can be done. For the chat example though, you should flag those chat messages.
It seems for some reason an https version of the landing redirect is being requested, I added a fallback that re-redirects it back to the BDNS homepage. This should fix the problem, but doesn't explain why it started happening. The security issue warning you got was right away after connecting to DNS?
That's weird, it's an internal page that serves no purpose but you shouldn't end up there... Is this on the 46.101.65.164 DNS? Or any of them?
It sounds like you're describing https://dragonite.fortheusers.org ? (Which is a dragonite). Where do you see this?
It turns out that the post queue was not being properly applied to some categories. This meant that all someone had to do to circumvent it was choose a different category. This has been fixed now and should help reduce the number of spammers.
We're also still working on the bot problem, the plan is to add a captcha-like check that doesn't impact DNS users. Right now, almost half of the traffic to this site is from bots and crawlers. If you see any bot users, please continue to flag them.
Are there any pages in particular that seem slower than other ones? And does changing to one of the other DNS addresses help at all? Typically my benchmark for a "good website" on the Switch browser is opening Wikipedia and clicking around to various articles.
The bot hit token limits, should be reset now, if you try now: @browsegpt
If it breaks again, I'm going to need to try a new approach, because this keeps happening!
I'm going to look into this, seems there are solutions to adding it to NodeBB as a plugin: https://community.nodebb.org/topic/14466/ignore-and-block-user-functions
:visited applies when the target link (the href attribute in the <a> tag) is in the browser's history. If you're in private browsing mode, or the link isn't in the history, then it won't apply. It could also be a css priority issue: https://www.w3schools.com/css/css_specificity.asp (the order that the rules get applied in).
The parent page can also override some styles. You could prove if the visited state is working by removing all styling, observing that it's Blue, then visiting it, and observing that it's Purple (these are the defaults, for most browsers). If that's working, then you should be able to test your custom style. I'm happy to answer more questions about this: HTML can be fun to work with!
Added a fallback too in case it happens again (like: a "We have a 'Go Home' button at home" simple link), but it should be fixed.
Also 
Indeed the sidebar icons are gone, checking now
For the past year or two, we've been dealing with excessive notifications, weird wrong counts, hidden notifications, etc. And we may have finally gotten to the bottom of them! Please let me know if the notification system seems less laggy and more accurate than usual.
The fix involved deleting over 140,000 old unread shoutbox message notifications, all of which were taking up space in memory. We've gone from 13.35 GB usage to 6.32 GB with just this one change.
I apologize again for the slowness and crashiness of the forum over the last few weeks, and hopefully this helps make the site faster and more responsive. I'm especially interested to hear from users that were experiencing issues before, to see if this has helped.
That's really interesting, and is definitely why they broke! For future reference, here's a list of all html color names: https://htmlcolorcodes.com/color-names/
I just had a script go through the DB though and convert any groups using color names to their hex values. Thank you for reporting (and debugging) this! Let me know if any other groups are still having the issue.
As for why this behavior changed, NodeBB added stricter color code validation on August 5, likely as a security measure, which defaulted non-hex values to #000000 (all black, no color). Previously, the these color names were passed directly into the CSS of the page, which can cause problems.
More background info on how to work with these color hex codes, if anyone reading is interested:
Anyway this became a longer post, but I wanted to explain it because I remember also stumped by these color codes for probably way too long when I first started seeing them on the Internet. And I hope this explanation doesn't just make them seem more confusing... The list of full color names mapping to these codes is actually really old, like from the 80s on early computer systems, and it was re-used in HTML in the 90s.
For even more info, this Vsauce video goes into much deeper detail about how screen pixels work using RGB subpixels to create other colors. The hex percents (eg. 23% red, 70% green, and 44% blue for MediumSeaGreen) directly control the brightness levels of these subpixels, creating the optical illusion of one solid color:
I pushed an update that should fix the icons not loading, however the site overall is still really slow. Looking into other solutions still to make it faster for Switch users.
Over the last 24 hours, the server has been experiencing high memory usage, leading to crashes and extended periods of downtime. We're in the process of trying several different approaches to fix this. Sorry for the inconvenience!
The version of NodeBB has also been updated to v4.16.0, so on top of the attempts to fix the memory issue, you may notice other site functionality broken, especially on console clients like the Switch 1.
Please report any and all new issues, slowness, broken features, missing functionality, etc, either in this thread, or in your own topic (depending on how bad of an issue it is).
We will work on fixing reported issues as soon as possible. In the future, to see if the site is up or not, you can check the status page here: https://status.browsedns.net/
@Malfa The best and easiest way to prevent the captive browser from being displayed is to enable Parental Controls on the device. This prevents the user from editing their settings, and so they cannot enter the DNS to configure it in the first place.
For the Switch, this can be done in Settings. You don't actually need to block any ESRB content, just having parental controls enabled is enough to block access. A PIN will be prompted for when they go to change the DNS settings.
If you're tech-savvy, blocking all three of our DNS IP addresses at your router's configuration page will also fully block them from resolving DNS requests:
I can also recommend: 1.1.1.1 for families, which can be used to allow or disallow categories of websites, even across other devices on your network. It's a good way to filter all Internet requests without having to set up extra hardware. More info here: https://one.one.one.one/family/
That's normal for forums! The new post 'bumps' it back the top of the Recents list: https://www.quora.com/What-does-bump-mean-in-an-internet-forum
Instead of Facebook, try this:
I got the "Feature is not available" screen with the DNS yesterday on my Switch 2, and can confirm that starting to watch a video (w/o the DNS) in the News applet removed it!
So in total:
- Set DNS to automatic, or to Google DNS (8.8.8.8)
- Watch a video in the News app, or open Facebook via the Album share applet
- Set the DNS back to one of the BrowseDNS addresses
The theory is that that the browser needs to connect "normally" every so often, otherwise it refuses to be displayed. This is likely a security measure to make sure the device is properly up to date before connecting to external websites.