Ryan Ashbrook

The error codes are mostly for our reference. If, for instance, there is a bug causing an error to show inadvertently (such as a user not allowed to view a topic, however all of their permissions say that they can), then it gives us an easy and direct starting point for debugging. This is why we recommend contacting support if a user is experiencing an error and you’re not sure how to resolve it - we can either instruct on what to do, determine if there is a bug, or sometimes even determine the experience resolving the issue can be improved in the software itself. For day to day cases, the error message that is displayed should suffice. As Marc said, in your specific example, that is a generic 404 page indicating a page does not exist in the software at all. The previous error code database really only contained the codes and the same message that was displayed or something generic like “user did not fill in all required fields”, with a few exceptions. In many cases, this is already handled within the software itself - if you encounter an error as an admin, it will sometimes give you instructions on what to check to resolve, if it’s relatively simple to do so (such as if there are no payment gateways set up). If a specific field is required, the form will not submit and tell the user, etc.

It was changed to BIGINT.

This should be fixed now. A couple days ago, Google Tag Manager was enabled, however the the GTM Body Snippet simply had <noscript> in it, which was causing the issue. I've adjusted that to <noscript></noscript>, which resolved the issue. Note, this isn't likely correct - if you are using Google Tag Manager, then there is additional code that needs to be added there. Unfortunately, that code is unique, so I cannot add it myself. Only the administrator of the site, with access to GTM, can do that.

This should be fixed now.

This should be fixed now.

It was definitely a while ago, because mine is long again lol

This should be fixed now.

Not a problem. 🙂

Those should be fixed now.

Sorry about that! This has been fixed.

Computer, mobile phone, etc. Whatever the user is using to browse the site.

I am not seeing this issue, currently - and wouldn't be related to the maintenance earlier. This appears to be newer emoji that are not supported on that device. Emoji are not static files (which is what the maintenance was pertaining to) but are actual characters.

This should be fixed now.

This should be fixed for you now.

Yes, but this only controls cookies IPS4 itself sets (so anything prefixed with ips4_, or your prefix if you've changed it previously). Cookies from external sources will follow their own rules. If you do this, make sure you use two dots as that's what allows the cookies to be read by subdomains: define( 'COOKIE_DOMAIN', '.brfcs.com' );