HF Board Update questions/issues thread

  • Xenforo Cloud will be upgrading us to version 2.3.5 on March 3rd at 12 AM GMT. This version has increased stability and fixes several bugs. We expect downtime for the duration of the update. The admin team will continue to work on existing issues, templates and upgrade all necessary available addons to minimize impact of this new version. Click Here for Updates
@SniperHF IMHO reactions (aka "likes") are a significant part of how people interact with each others on boards like this one and the "wow" and "angry" custom images ruin that part significantly.

I understand the motivation behind the change but it's not working.
Disagree, I love them and I think more ways to express emotions is better

Anyways, if they take them away I can just reply to you with:

:turkeygirl:
 
I've made forums using templates and base software, but it didn't involve much coding. You could change icons just by modifying the picture file. Definitely doesn't sound that easy.

So we're using Xenforo and with a custom theme based on UI.x which is an add on. From what I understand xenforo doesn't really conform to best practice css scripting/layout. If I had to guess it's because the xenforo developers are super high up their own asses and think their shit doesn't stink.

Bit anyways, so every color is assigned a name and every object on the screen is assigned one of those. BUT only around half of the objects are actually affected by changes in the. Control panel the other half are hard coded.....

So like the red "new post" button might be XFCCENTCOLOR1. But if I make xfaccentcolor1 yellow, it all the sudden turns alerts yellow too. I could change what color affects alerts to XFACCentcolor2, but this is hard coded in one of 2000+ template files somewhere. It's like constant whack a mole.
 
Difficult in the sense that you don't know if making a tiny cosmetic change will somehow cause major infrastructure failure lol

Those are load-bearing colors.

One example of this is hyperlinks. So originally the links in the alerts drop down were the same color as regular text. Fixing this caused ALL links on the forum main page to be colored including headers and forum names.

There's a file called extra less where you slap random fixes like this but it's not good practice to add to many customizations in here

It's like the script reads:
Do x to links
Then do y to links


Instead of changing what x is.

So I try and change what x is to do it properly and not bog down the script but that's when I start hitting these cascade effects.
 
One example of this is hyperlinks. So originally the links in the alerts drop down were the same color as regular text. Fixing this caused ALL links on the forum main page to be colored including headers and forum names.

There's a file called extra less where you slap random fixes like this but it's not good practice to add to many customizations in here

It's like the script reads:
Do x to links
Then do y to links


Instead of changing what x is.

So I try and change what x is to do it properly and not bog down the script but that's when I start hitting these cascade effects.
I think I get it now. Basically what you're saying here is that you're a powerful sorcerer, and that you've been having to perform complex and often dangerous rituals in a constant battle with this evil shadow entity known as "Xenforo"... That's how I will interpret what you've told us.

Thank you wise magus 🙏
 
I think I get it now. Basically what you're saying here is that you're a powerful sorcerer, and that you've been having to perform complex and often dangerous rituals in a constant battle with this evil shadow entity known as "Xenforo"... That's how I will interpret what you've told us.

Thank you wise magus 🙏
I'm getting this mental image of @SniperHF seeing an update has occured....
a man with a necklace that has the word fuck on it


He grimaces at the coming headache but cracks his fingers... cues up the playlist and turns back to his codes...


Just thought you needed some pump up music big guy.
 
First off, thank you for everything you do here!

The biggest lingering issue for me personally, is when refreshing the page on mobile, it doesn’t hold the post you were on so you then need to scroll to find where you left off at and it’s quite frustrating because I refresh a lot to see new posts,
 
I'd be more than willing to give up emojis and custom themes entirely in exchange for the board not vapor-locking under high volume use.
I've been here for 19 years and it's been like that for 19 years regardless of how much board members have been complaining about it (and trust me, we have).

That's never, ever, going to get fixed. Whenever something important happens in the hockey world HF is going down. That's the way it is.
 
  • Like
Reactions: Foppa2118
I've been here for 19 years and it's been like that for 19 years regardless of how much board members have been complaining about it (and trust me, we have).

That's never, ever, going to get fixed. Whenever something important happens in the hockey world HF is going down. That's the way it is.
Imagine what will happen when the Leafs end up winning the Cup.

Thank God that will never happen. And sorry! I didn't notice you said "Important".
 
As a back end web developer and infrastructure architect, I can tell you that things are not quite as simple as throwing more resources at the problem. That is especially untrue when it comes to the mythical "bandwidth". Bandwidth refers to the amount of data transferred over a connection over a period of time. The site going down is 99.999% unlikely to be a "bandwidth" issue as the connections are more than capable of handling more traffic. The problem will be a bottleneck somewhere. On a site like this things like CSS and JavaScript, as well as media assets usually do not change very often, so they can be heavily cached. They are often referred to as static assets, because they are shared across all or a subset of users on the site and they do not change. But on a forum, there's a lot that cannot be cached for long, or under some circumstances at all. For example, what threads and messages etc have been read by each user. Therefore there's a bunch of overhead to do database lookups to check when the last time a thread was accessed by the logged in user vs the last time the thread was posted to. Also the active user list. Any direct messages. Your individual user account menu. etc etc. There's a lot of reading from and writing to the databases for every user as they navigate the site. Scaling databases is do-able, but hard. You end up in a situation where more than one database connection is trying to write to the same database table, or even row. In cases like this you typically lock the row for writing until the previous transaction is complete. Subsequent requests then have to sit waiting being blocked by earlier requests. This is likely where this site falters. Now you can get around this using various techniques, but technically it can become difficult if for example you have multiple database servers handling different requests because keeping those servers in sync is a challenge. Also reliable, db scaling is not super cheap. Especially if you are load balancing across different geographic zones (like having servers in the western and eastern US, Europe and Asia).

In front of this site is Cloudflare which is a service which does things like DDoS protection, DNS, and reverse proxy caching to help with attacks and handle spikes in traffic, but if the underlying servers struggle to keep up, Cloudflare can only do so much. As stated earlier, my hunch is blocking at the database level causing the site to struggle during high traffic times when lots of people are posting.
 
  • Like
Reactions: CharlesPuck
As a back end web developer and infrastructure architect, I can tell you that things are not quite as simple as throwing more resources at the problem. That is especially untrue when it comes to the mythical "bandwidth". Bandwidth refers to the amount of data transferred over a connection over a period of time. The site going down is 99.999% unlikely to be a "bandwidth" issue as the connections are more than capable of handling more traffic. The problem will be a bottleneck somewhere. On a site like this things like CSS and JavaScript, as well as media assets usually do not change very often, so they can be heavily cached. They are often referred to as static assets, because they are shared across all or a subset of users on the site and they do not change. But on a forum, there's a lot that cannot be cached for long, or under some circumstances at all. For example, what threads and messages etc have been read by each user. Therefore there's a bunch of overhead to do database lookups to check when the last time a thread was accessed by the logged in user vs the last time the thread was posted to. Also the active user list. Any direct messages. Your individual user account menu. etc etc. There's a lot of reading from and writing to the databases for every user as they navigate the site. Scaling databases is do-able, but hard. You end up in a situation where more than one database connection is trying to write to the same database table, or even row. In cases like this you typically lock the row for writing until the previous transaction is complete. Subsequent requests then have to sit waiting being blocked by earlier requests. This is likely where this site falters. Now you can get around this using various techniques, but technically it can become difficult if for example you have multiple database servers handling different requests because keeping those servers in sync is a challenge. Also reliable, db scaling is not super cheap. Especially if you are load balancing across different geographic zones (like having servers in the western and eastern US, Europe and Asia).

In front of this site is Cloudflare which is a service which does things like DDoS protection, DNS, and reverse proxy caching to help with attacks and handle spikes in traffic, but if the underlying servers struggle to keep up, Cloudflare can only do so much. As stated earlier, my hunch is blocking at the database level causing the site to struggle during high traffic times when lots of people are posting.
Wizard! 🧙‍♂️
 
  • Haha
Reactions: expatriatedtexan
As a back end web developer and infrastructure architect, I can tell you that things are not quite as simple as throwing more resources at the problem. That is especially untrue when it comes to the mythical "bandwidth". Bandwidth refers to the amount of data transferred over a connection over a period of time. The site going down is 99.999% unlikely to be a "bandwidth" issue as the connections are more than capable of handling more traffic. The problem will be a bottleneck somewhere. On a site like this things like CSS and JavaScript, as well as media assets usually do not change very often, so they can be heavily cached. They are often referred to as static assets, because they are shared across all or a subset of users on the site and they do not change. But on a forum, there's a lot that cannot be cached for long, or under some circumstances at all. For example, what threads and messages etc have been read by each user. Therefore there's a bunch of overhead to do database lookups to check when the last time a thread was accessed by the logged in user vs the last time the thread was posted to. Also the active user list. Any direct messages. Your individual user account menu. etc etc. There's a lot of reading from and writing to the databases for every user as they navigate the site. Scaling databases is do-able, but hard. You end up in a situation where more than one database connection is trying to write to the same database table, or even row. In cases like this you typically lock the row for writing until the previous transaction is complete. Subsequent requests then have to sit waiting being blocked by earlier requests. This is likely where this site falters. Now you can get around this using various techniques, but technically it can become difficult if for example you have multiple database servers handling different requests because keeping those servers in sync is a challenge. Also reliable, db scaling is not super cheap. Especially if you are load balancing across different geographic zones (like having servers in the western and eastern US, Europe and Asia).

In front of this site is Cloudflare which is a service which does things like DDoS protection, DNS, and reverse proxy caching to help with attacks and handle spikes in traffic, but if the underlying servers struggle to keep up, Cloudflare can only do so much. As stated earlier, my hunch is blocking at the database level causing the site to struggle during high traffic times when lots of people are posting.
in-english-please-5b81347800.jpg
 
  • Haha
Reactions: expatriatedtexan
I've been here for 19 years and it's been like that for 19 years regardless of how much board members have been complaining about it (and trust me, we have).

That's never, ever, going to get fixed. Whenever something important happens in the hockey world HF is going down. That's the way it is.

I don't find it terribly inconveniencing either. 2-3 times a year, the board goes down for an hour or two. Not that big a deal for me personally.

If we can't find something else to do for an hour or two, a couple times a year, than complain about our hockey teams and trades, and get in arguments online, we might be in trouble as a society. Wait....
 
I don't find it terribly inconveniencing either. 2-3 times a year, the board goes down for an hour or two. Not that big a deal for me personally.

If we can't find something else to do for an hour or two, a couple times a year, than complain about our hockey teams and trades, and get in arguments online, we might be in trouble as a society. Wait....
You see, they need to get it fixed as a service to society. You see, society isn't ever really threatened, until this place shuts down and all of lunatics have nothing better to do than to go out into society.
 

Ad

Upcoming events

Ad