Unread content? Bugged? Or how to use it?

[aFrInaTi0n]

Ok, thanks for the update - at least I wanted to test the low hanging fruits 1st for success..

[Kalais]

Nothing has changed since I made this topic. I just went thru unread content and it shows only old topics with new posts (from today and yesterday). New topics are never shown.

Topics creations dates from unread content i see on the list:

December 19, 2015

October 9, 2014

Posted October 9, 2014

August 28, 2018 

July 21, 2025 <- this one is kinda newish 

https://www.eurobricks.com/forum/forums/topic/208445-2026-technic-sets-discussion/

September 30, 2024
November 28, 2020
May 1, 2011

[MKJoshA]

@aFrInaTi0n I've noticed old content consistently showing up in my stream the way it is supposed to since yesterday. Did something change to make it start working?

[Black Falcon]

1 hour ago, MKJoshA said:

@aFrInaTi0n I've noticed old content consistently showing up in my stream the way it is supposed to since yesterday. Did something change to make it start working?

I can confirm that it seems to be working again. I´ve looked through all posts in unread content and all what is left after nothing is shown there anymore are three topics where the last post is from 21 hours ago.

[aFrInaTi0n]

lol, since yesterday working for both of you?!

I did nothing at all unfortunately.

[Kalais]

I did some quick test and indeed looks like it working they way it should :D

[aFrInaTi0n]

Those are the moments I am asking myself of being stupid to not get what may have changed for this to happen... 8[

Only theory which may come to my mind: Something bugged the whole thing up and that item may have gotten out of the way by age / superseeded with newer items.. Thing is I have not seen anything in the backend error logs which would indicate such in any ways.

So still a super strange case to me - but happy it autohealed itself somehow.

Edit: Wait a second... I did work in our test environment the last days and brought the environment to a complete halt / non useable state around two days ago...

The test environment is a technically strictly separated environment, so both are not sharing any stacks - instead they were set up with the clear separation in mind.

Could your do me a favor and trying to check if your browsers hold cookies for "test.eurobricks.com"? (the domain won't work). If so I would recommend to clear / delete all cookies for the "test.eurobricks.com".

If there are no cookies in your browser for the test domain, it is also an important information to me.

[aFrInaTi0n]

Not sure if AI is in a confirmation bias here, but at least it sounds like my theory may be a valid one:

Quote

Yes, it is absolutely possible—and actually highly probable—that client-side cookie issues caused this.

Even though your live and test environments are perfectly isolated on the server side (separate databases, directories, etc), they share a critical piece of real estate on the user's browser: the parent domain (eurobricks.com).

Here is exactly how a collision between www.eurobricks.com and test.eurobricks.com happens and why shutting down the test site "fixed" it.

The Culprit: Cookie Domain Scoping

Browsers determine which cookies to send to a server based on the cookie's Domain and Path attributes.

1. The Wildcard Effect

If your Invision Community configuration on the test site (test.eurobricks.com) was set up to save cookies to the root domain .eurobricks.com (note the leading dot), those cookies are treated as wildcards.

• The browser will automatically send those test-site cookies to any subdomain, including www.eurobricks.com.

2. Cookie Overwriting and Corruption

Invision Community relies heavily on specific cookie names for session handling, member validation, and security tokens (like ips4_IPSSessionFront, ips4_member_id, or CSRF tokens).

If both sites used the default cookie prefixes, visiting the test site would overwrite or append cookies with the exact same names as the live site. When the user went back to the live site:

• The live site received the test site's session ID or member ID.

• Because the live database had no record of that test session, the live site would throw errors, log the user out, or break specific functionalities (like posting, notifications, or AJAX-heavy features) due to failing security/CSRF checks.

Seems there are ways to split the cookies apart, I will further check this to get implemented..

[Kalais]

4 hours ago, aFrInaTi0n said:

Could your do me a favor and trying to check if your browsers hold cookies for "test.eurobricks.com"? (the domain won't work). If so I would recommend to clear / delete all cookies for the "test.eurobricks.com".

If there are no cookies in your browser for the test domain, it is also an important information to me.

Opera here. No "test.eurobricks.com" cookie, only for "eurobricks.com" here.

[aFrInaTi0n]

Good thing is, we can test again if TEST being avaiilable is making it worse again... I like mysteries! :)

[Black Falcon]

5 hours ago, aFrInaTi0n said:

Not sure if AI is in a confirmation bias here, but at least it sounds like my theory may be a valid one:

Seems there are ways to split the cookies apart, I will further check this to get implemented..

If cookies were the issue shouldn´t deleting them have fixed it anyways? Unless the test-server cookies were added right away again ofc.

No test-cookies here either.

[aFrInaTi0n]

Again, I am reaching for straws here.. in theory there may be truth to the scenario described from AI.

Thing is: Nowadays the "www." prefix is recommended to be left out, as all modern browsers are just showing the domains themself, even if they have a prefixed "www." - for allowing the "www." still to work, we have a DNS entry for that so called "subdomain" - on the server-side all requests originally trying to reach "www." will get a HTTP 302 permanent redirect to the main domain without any subdomain prefixed. And here things theoretically could go wrong somehow - as a cookie for the domain "eurobricks.com" may be considered applicable for subdomains as well. And there some shenanigans may happen.

At least we / I have some little clue into any direction.