TryAllTheThings
Forum Replies Created
-
Hello,
Thanks for taking a look.
- Timezone behavior
With the plugin timezone set to “Default,” events import at the correct times. When I select the correct explicit timezone (e.g., Europe/Berlin), the same events appear +2 hours off. This looks like a bug. - ICS files
I’ve uploaded both.icsfiles and included the links at the end of my initial post. - Free/Busy handling
Events marked as free are currently treated as busy and block the slot. From a user perspective, “free” shouldn’t block availability. If these items need to be imported for other features, could they either be ignored for availability by default or controlled via a setting?
Happy to share anything else that helps. Thanks again for your support.
- This reply was modified 8 months ago by TryAllTheThings.
- Like I mentioned, this is already set correctly to Europe/Berlin. Sorry for the German, didn’t want to change my user profile language to not introduce additional issues.
It is because in your initial .ics feed the bookings defined as:
RRULE:FREQ=WEEKLY;UNTIL=20251231T080000Z;
DTSTART;TZID=W. Europe Standard Time:20250127T090000
DTEND;TZID=W. Europe Standard Time:20250127T110000and it’s means that it’s time slots from 09:00 to 11:00 started on 2025-01-27 and repeated weekly and ended on 20251231
2. Sorry, I don’t understand. From the imported .ICS, the only time slots that should be blocked on 6.10.2025 are 9:00 to 11:00 and 11:00 to 12:00, but instead there are other, full day events that shouldn’t be there on this date. Here’s what it looks like in Outlook. Notice, that there is no full day event on 6.10.2025, only 2 busy events. One of which is recurring “Occurs every Monday, Tuesday, Wednesday, Thursday, and Friday effective 27.01.2025 until 31.12.2025 from 09:00 to 11:00”, one single busy event and 1 free event.
And here’s the what’s shown in WP booking manager after importing. The event marked as “free” is blocking a time slot, and recurring events are counted as full-day despite all of them having fixed from-to times.
Same week in Outlook.
Your other booking in your .ics feed has the other conditions
DTSTART;VALUE=DATE:20251010
DTEND;VALUE=DATE:20251013Yes, but the busy status is free for that event but isn’t treated as such.
X-MICROSOFT-CDO-BUSYSTATUS:FREEThere were a few new versions released, but I don’t find this issue in the changelog. Is this fixed now?
Forum: Plugins
In reply to: [Social Login] Critical vulnerability (CVSS 9.8)Judging by the amount of spam I receive on some of the admin email addresses, there is most certainly a way to retrieve the email address of an account without being logged in. But as far as I understand retrieving the address is not the point of the CVSS but being able to log in with any other account instead of the one just authenticated.
The Social Login plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 5.9.0. This is due to insufficient verification on the user being returned by the social login token. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the email and the user does not have an already-existing account for the service returning the token.
I’d recommend contacting the original Researcher for more details or a PoC.
Forum: Plugins
In reply to: [hCaptcha for WP] hCaptcha blocks WooCommerce checkoutI did some more testing today. I enabled hCaptcha for the checkout page and was prompted with the captcha as expected and could complete the order. After disabling it for the checkout page, the issue is back.
I just emailed you the shop URL.
Forum: Plugins
In reply to: [hCaptcha for WP] hCaptcha blocks WooCommerce checkoutThank you for your reply. Why should we turn it on if we don’t want to use it in the checkout form?
From what I can see, the only thing on the checkout page is the Elementor checkout element. No other shortcodes are implemented. We would also see the clear text shortcode at the moment, as hCaptcha is disabled. As we don’t see it, I would assume that there isn’t one added to the page. I even checked the content of post_content in the database. The shortcode is not present in the checkout.
Any other ideas?
Great to hear. Thank you!
Will this bug be fixed, though?
Hey!
We checked on this and it seems you used constants to set a password.
Yes, that is correct.
Can you please disable constants, set the password via settings, and check if you still have an issue with such a configuration?
I tried, and the issue is gone if I set the password via the settings instead of a constant. While doing so, I think I found the issue:
WP Mail SMTP uses the password set via the settings instead of the one set via constant for password resets. I set different values for SMTP username and password on the GUI, re-enabled the constants and this is the output for the password reset:
SMTP Credentials Host: smtp-mail.outlook.com Port: 587 Username: potato Password: NotAPasswordSo the plugin indeed uses different credentials for the password reset. The values above were set via settings. The correct ones are defined via constants.
I will switch to setting the password via settings for the time being. I’m not sure why I set it via constants in the first place. Might have been suggested as a workaround for another issue or recommended in the FAQ. The site is running for a couple of years already. Can’t remember 🙂
The issue persists with the latest version (4.0.1)
The error you shared usually occurs when there is an issue with your SMTP password. And because of this, the SMTP server you’re trying to connect to is rejecting it.
Yes, that’s what the error message said. But unless WP Mail SMTP is using 2 different sets of credentials for different mails, this error doesn’t make any sense. (by the way: Only a single SMTP server is configured – no alternate ones)
Is there a way to show the credentials in the log? I would like to verify which credentials are being used.
CLIENT -> SERVER: [credentials hidden]I’m pretty sure the email hosting provider would say the same that you just said: Wrong credentials. The type of message shouldn’t matter at this point since all mail details (recipient, subject, body, etc.) will only be transmitted after the AUTH.
I also just tried another plugin (Post SMPT https://ww.wp.xz.cn/plugins/post-smtp/) and with that it works right away. So I’d assume WP Mail SMTP does something odd here.
Update: I was able to send a password reset email successfully when I initiate it through the backend (Users -> Username -> Send password reset). It just doesn’t work when done via the frontend. There is nothing special going on with the front end page. The user visits domain.com/my-account (which is the default WooCommerce page integrated via shortcode [woocommerce_my_account]), clicks password reset and ends up on https://www.domain.com/my-account/lost-password. The page is default WooCommerce without any modifications.
Who is your hosting with?
Not really a webhoster. Just at IT company offering hosting services as well while just renting the server somewhere else. Complicated story.
Two sites were fixed by the method described earlier. For the third site I switched to PHP 8.1 and the issue was gone as well. Configuration for PHP 8.1 was almost identical to 8.0, so I have no clue where this issue came from and why it magically solves itself.
Can you ask your host your host enable that function since it’s part of the PHP core https://www.php.net/manual/en/function.disk-free-space.php
As per the webhoster, no changes were made and the PHP function was disabled for a long time already. They have no interest in enabling it. I couldn’t get any other information or clarification from them.
But from what I understand it shouldn’t matter if this function is enabled or not since you have error handling for this in place.
Can you ask your hosting for details of why updating the php version fixes this and ask them what they believe the underlying cause is?
They told me they had the same issue with UpdraftPlus with other customers as well, and “fixed” it by changing PHP to version 8.1. Couldn’t get any more information from them besides repeating this over and over.
Meanwhile, I was able to “fix” the issue for one site by disabling UpdraftPlus via FTP and re-enabling it via the WordPress plugin management. No code or configuration changes were made.
On another site (on the same server), I could “fix” the issue by disabling UpdraftPlus via FTP, updating it to the latest version (1.23.16) and enabling it again.
The only idea I got for this issue is something within WordPress itself, as both sites did an automatic update as soon as the error was fixed by disabling UpdraftPlus.
Like I wrote already a couple of times: This is all that is inside the backup logs. There is nothing else following the “header”.
- Timezone behavior