Redirect issues with www domain and language URLs from Google

Hello,

I have encountered two unexpected redirect issues that may be related.

### 1. Incorrect redirect on the www domain

When accessing the **www** version of the website, Osclass returns:

`302 → https://domain:/`

Notice the unexpected colon before the slash (`:/`).

The non-www version redirects normally to the homepage (or the default language), but only the **www** version generates this malformed URL.

I have already verified the following:

* `WEB_PATH` is configured correctly.
* HTTPS is enabled.
* `osc_base_url()` returns the correct URL.
* SEO and PWA plugins are disabled.
* The issue still persists.

### 2. Incorrect redirect from Google for translated URLs

I also noticed another issue when using language URLs such as:

`https://domain.com/en`

where the default site language is different from English.

This issue only occurs when users open the page from Google Search:

* Clicking an English page from Google redirects the user back to a Google page instead of opening the website.
* If the user clicks the same result a second time, the English page opens correctly.
* If the exact same URL is copied and pasted directly into the browser address bar, it opens normally without any redirect.

So the problem only occurs on the first visit when coming from Google Search.

Could you please advise where these redirects are generated, or whether they are known issues?

Thank you.

waiting for reply.

The cookie issue and the redirect back to the Google page is a known problem, and I had the same issue.

It was fixed in version 8.3.1. I don’t remember the exact details, but ChatGPT found the place in the theme’s index.php file that was responsible for handling cookies. I modified that part to make it compatible with the new Osclass version, and after that everything started working correctly.

Thank you for your reply.

I upgraded to Osclass 8.3.1, but the issue was still present on my installation.

After investigating, I noticed that the relevant code is not in the theme, but in the main Osclass `index.php` file located in the root directory.

It appears that after updating the user's locale, the code redirects to `HTTP_REFERER`. When the visitor comes from Google, the referer is a Google URL, which seems to cause the redirect back to Google on the first visit.

For testing, I modified the redirect so it only happens when the referer belongs to the same website (ignoring the optional `www` prefix), instead of redirecting to any external referer.

Since making this change, the behavior seems much better. However, this is only based on my own testing.

I think it would be good if the Osclass developers could review this logic and confirm whether this is the correct fix or if there is a better solution.

Let's wait for their confirmation.

Original code (`index.php`):

// Update os812
if($original_url != '' && osc_get_current_url() != $original_url) {
    osc_redirect_to($original_url);
}

For testing, I changed it to:

$original_url = filter_var($original_url, FILTER_VALIDATE_URL);

if ($original_url) {
    $refererHost = strtolower(parse_url($original_url, PHP_URL_HOST));
    $baseHost = strtolower(parse_url(osc_base_url(), PHP_URL_HOST));

    $refererHost = preg_replace('/^www\./', '', $refererHost);
    $baseHost = preg_replace('/^www\./', '', $baseHost);

    if (
        osc_get_current_url() != $original_url &&
        $refererHost === $baseHost
    ) {
        osc_redirect_to($original_url);
    }
}


It most probably cannot get your url into proper format, were you able to identify why? maybe some trailing slash in url being removed?

It most probably cannot get your url into proper format, were you able to identify why? maybe some trailing slash in url being removed?

Thank you for your reply.

At the moment, I believe these are actually two separate issues.

1. **The Google redirect issue** appears to be improved after I modified the redirect logic in `index.php` so that it only redirects to an internal referer. Since making that change, I have not been redirected back to Google during my tests. However, this is only based on my own testing, so I would appreciate it if you could review whether this is the correct approach.

2. **The malformed redirect (`https://domain:/`) on the `www` domain is still present.** I have not yet identified its cause.

Regarding your question about the URL format or a missing trailing slash, I checked the following:

* `WEB_PATH` is correct.
* `osc_base_url()` returns the correct URL.
* HTTPS is configured correctly.
* The problem only occurs on the **www** domain.
* The non-www domain redirects correctly.

So at the moment I have only managed to improve the Google redirect issue. The malformed `https://domain:/` redirect is still unresolved, and I have not yet found where that colon is being introduced.

I will continue investigating it, but if you have any suggestion about where this redirect is generated, I would be happy to test it.

 Following up on my previous posts regarding the redirect issues.

I have been investigating further and successfully mitigated the Google search redirect issue by adjusting the redirect logic in the root index.php file to verify that the HTTP_REFERER matches my domain host. This prevents the system from blindly redirecting to external referrers.

However, I am still facing the following unresolved issues, and I would appreciate any guidance from the developers or the community:

1. Malformed Redirect on 'www' domain:
I am still getting an incorrect redirect when accessing the www version of my site: 302 → https://domain:/. It seems a colon is being erroneously appended to the domain. I have verified that WEB_PATH and osc_base_url() are configured correctly. Has anyone identified which function or file might be responsible for generating this malformed URL string?

2. Duplicate entries in Admin Dashboard:
Since updating to 8.3.1, searching for items (ID/Content) in the admin panel returns each result 3 times. This suggests a potential issue with SQL queries joining tables incorrectly after the update.

3. Unstable View Counter:
The automatic view counter in the statistics is behaving erratically—it increases and then decreases unexpectedly. It seems to be suffering from a synchronization issue, possibly related to how the counter is updated in the database or cache.

Has anyone else encountered these specific issues post-upgrade to 8.3.1? Any advice or pointers on where to look for the SQL/logic errors would be greatly appreciated.

Thank you.

You have started to mix various issues into one thread.
1) never heard about anyone having such issue, you will need solid technical skills to analyze this. Forums will not help.
2) analyze queries, do not ask chatgpt to write question to ask on forums
3) item views are increased on publish and decreased on deactivation and similar actions.