derpunker

Not really, the issue was never seen before the update. (update was installed on Nov. 16) Since the update, the errors are popping up and the root cause is always the same.

The dev environment shows this in both cases. The dev environment shows more details and this system has no language pack installed. The theme is unmodified too.

Looks like there are more texts missing. => rejecting a report => complete a report

I have observed the same issue. There is one kind of parameter which causes the issue for me. I have no idea if this link is coming from the IPS installation itself or somewhere cached in google. Maybe the link was valid in a older version of IPS. Hint: Removing the ' in the URL fixes the issue. After removal the query parameter is correctly translated to page/2/

done 🙂

@Daniel F You mean the code or the UI?

Dear IPS support, affected file: system/Content/Controller.php The function "report()" doesn't check if there is more than one type available. It shows always the selection box with one entry. I have observed this for CMS\records. The function "_report( $commentClass, $comment, $item )" does this check and the dropdown is hidden if there are no custom types defined. Please have a look and add this check in th "report()" function too. Thanks.

Thanks, I had some hope. 😉 Do you have an estimate in which release the fix will be included?

@Marc I guess the fix is not included in IPS 4.7.18, right?

Dear IPS support, there is a bug in the bulkmail logic when using SendGrid as external provider. The unsubscribe link in the send email is not valid. The reason for that is the "ClickTracking" logic. What's happening: applications/core/extensions/core/Queue/Bulkmail.php => function "run" calls "mergeAndSend" in SendGrid implementation. The mergeAndSend calls "compileContent" with member-parameter FALSE "compileContent" creates the mail content, including the unsubscribe link. Later in the code/function the "ClickTracking" is added. IMPORTANT HINT: The place holders for email and unsubscribe key are not yet substituded in href. The "ClickTracking" logic adds an hash value based on the email and unsubscribe key (not yet set). Back in "mergeAndSend" the placeholders are substituded in the content. The substituion is to late for the hash calculation in the ClickTracking function during content creation. As consequence, the unsubscribe link in the email is invalid because of the invalid hash value! Currently, we have multiple support requests because of this issue. This happens only when using SendGrid, the "normal" Email logic is working correctly. The bug invesitgation is done from my end, now it's your turn to fix this bug as soon as possible. 🙂 Hint: There is no need for access to my communitiy suite. The isse can be reproduced in every dev-environment, once SendGrid is activated and you try to send a bulk.

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.

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.