derpunker

I found a solution for my IPS systems and everything is working fine.
My new users will be happy about the improvement.

2024-02-24 22-18-21.mkv

Many thanks for the friendly, helpful and very cooperative support today.

Do what you want with the error report. It's a problem in your code.

The hCaptcha script sets a global variable.

window.hcaptcha

As long as this global variable set, the hCaptcha doesn't load/render.

Resetting the variable (window.hcaptcha = undefined) let the hCaptcha load again.

Calling explizit "window.hcaptcha.render" brings it back too.

Please refer to the video:

2024-02-24 21-46-53.mkv

Now it's your turn.

Resetting the global variable should be the easierst solution.

To get further here:

• only hCaptcha is affected by problem
• the "google" captchas are working fine

Looking into the IPS code make the probleme clear. The problem is how hCaptcha works and how it's integrated.

This IPS code part loads the js file from hcaptcha.com and this javascript code responsible for showing the hCaptcha.
The IPS hCaptcha template is simple and no data-controller is involved.

The external javascript code is doing some magic stuff, among other things, it is searches for an element with the class "h-captcha" and adds the iframe for the hCaptcha.

Summary:

As long as the registration form is hosted in the popup, no browser will load the external javascript file again and the captcha is not created.
For the browser, the js-file is already available and no need to load it again.

The registration form as a page (no popup) reloads everything, including the hcaptcha.com script. That's why it works there.

After adding the .htaccess credentials which are available for you, there is no cricitcal console error shown.



Tested with latest Edge and Chrome browser.

I really don't see any problem that should block you.
 

Just now, Jim M said:

Yes, please remove that. 

No chance.

The permissions are not set and the content can't be public.

You have the credentials for the .htaccess and it's not blocking you.

The whole website is under .htaccess.
The credentials are the same as for the AdminCP, which are available in the client area.

There is only one 401 error and this is the manifest, which doesn't harm.

I just installed the latest patch.

4 minutes ago, Jim M said:

This is indeed what I have set on my installation which I mentioned above so we would need to see this on your live site to provide support.

Please tell my why this investigation can't be done in a 1:1 copy?!

Investigations and analyzes in a live system is a no go for me!
You should be happy that the problem can be reproduced in a test system and does not pose a risk to the live system.

As I already mentioned above disabling the plugins is not possible, because the website is live and won't work for my customers!

----

Use my other subscription, it's the same there.
This URL is the live URL you insist on.
Access Information just update in the client area.

If you are not willing the have look into my test system, activate the quick registration in your system and have a look.

You will see the effect.

The test system is a 1:1 copy from the live system.

I can't disable the 3rd party plugins in the live system.

Please have a look.

Ah, I guess I know what has happened.

Looks like you are using die LIVE system (forum.****)
The account is only enabled in the test system.
Please have a look on the AdminCP URL.

Account was banned because of too many failed logins. (why ever)

It's enabled again and the password is reentered in the Access Information.

@Jim M

Access information are updated.

Access to AdminCP should be possible now.
FTP access is still not possible, because the FTP account is disabled and I can't access the server managment console at the moment.

The FTP account will be enabled as soon as I have reached the server admin.

For having a first look, I hope AdminCP access is enough.

Dear @Jim M

Thanks for your suggestions. I did all your recommended steps, but the situation doesn't change.

• Latest IPS version is installed (patch included)
• No IPS files are changed
• All plugins are disabled, only "System" and "Forums" are enabled
• IPS default theme (unchanged) set as default

2024-02-24 16-02-16.mkv

The redirection to the registration page doesn't happen in my case.

As soon as the registration form is not hosted in a popup, the hCaptcha is working as expected. This I can confirm.

Dear IPS support,

we are currently facing the issue that the registration of new users doesn't work in every case.
It was hard to find out what's the background, but the root cause is the behavior of hCaptcha.

Repro steps:

• Open the registration form => hCaptcha is visible
• Make some invalid input or leave all fields empty and press the "Create my Account" button
• Form is reload but hCaptcha is missing => problem, no registration possible

The video shows the issue.

Please have a look and fix this issue with your next maintenance release.

The issue is really a hurdle for some users.

Thanks and best regards.

9 minutes ago, Grafidea said:

For me, beta is beta and stable is stable.  Not every forum owner is a programmer.  So IPS developers should keep this in mind.

Absolutely my opinion!

Luckily I'm a developer and was able to change the IPS code in a way that the login for the users was working again.
Without knowing the IPS code in parts I would have been lost last night.

I would never use an alpha or beta version on a productive website, but I should be able to rely on a stable version. The cookies are basic functionality and they should be tested well in all possible configurations.

2 minutes ago, Nathan Explosion said:

You upgraded early too though so...

When IPS releases a version, I expect it to be tested and to work like the previous one.
I am not a paying beta tester. 😉

1 hour ago, Stuart Silvester said:

I suspect that's related to the other item you posted, As a work around you could use the standard cookies tag and translate the 'cookies_message' string instead: 

Unfortunately no solution. Currently I can decide between a not working guest banner for guest (customized text with only on button) or permanent popping up banner for registered members (default text {cookies} with 2 buttons).

Other options are not possible and I have to decide which evil has lower impact for my community.

1 hour ago, SeNioR- said:

but please test the new release properly - before releasing it. Too many bugs and omissions for one release.

14 minutes ago, Nathan Explosion said:

Test. Test again. Test further.

Oh yes!!!

Quality management has completely failed here!!

I can confirm this error. Same behavior in my community suite.
This is most probably the next cookie bug.

What the hell has IPS done in 4.7.11 update 😠
This is not normal that such problems occur after an update.

Install the latest patch. This logout topic is discussed in a parallel topic.

Regarding the cookies in IPS 4.7.11, I would say they are a little bit broken...

@Stuart Silvester

Patch installed but still not working!

Login iusse fixed => I can confirm.

But the banner for guests keeps popping up unintentionally!

For logged in Users:

• Cookie banner pops up for an part of a second which is really anoying. Happen ins Chrome/Edge with mobile view.

For guests:

• If anything else than {cookies} is added in the AdminCP as text, the banner pops up after every reload.
• Using only {cookies} as content helps in this case.

Please fix and provide another patch.

Thanks.

30 minutes ago, SeNioR- said:

For me, after rejecting cookies, the banner appears for 1 second each time the page is reloaded. Irritating 😖

I have seen this too, but only in Chrome/Edge with mobile view.

This behavior was changeable with using more than {cookies} in the hint text for guests.

Sorry to say this, but the latest IPS update is really buggy. 😞

Thanks for the quick feedback.

I found another "hack" which seems to be working.

=> Disable the skipCookie check.

I know that's only a workaround but better than the current situation.

14 hours ago, Grant_B said:

Reverting system/Request/Request.php seems to have resolved this so hopefully this helps you guys work out the issue and release an updated patch.

Could you please share the delta so that I can change it in my community too?

I would like to have a weekend without defect reports 😉

The cookies seems to be available but handled wrongly during the first load of the page.

• Close all browser instances
• Open browser in normal mode (not incognito)
• Navigate to the IPS site
• => not logged in
• Click on any link inside the IPS side so that the side reloads
• => logged in

Reproducible in localhost environment with all customizations disabled.

Enabling the DEV-Mode changes the behavior and the login is working as expected.

System cache cleared, but no change.

Latest IPS 4.7.11 is installed.

Is this check really wanted?

Instead of "==" contains would work too.

With this implementation, there is no chance to customize the guest banner with additional text.