kaggdesign
Forum Replies Created
-
Forum: Plugins
In reply to: [hCaptcha for WP] hcaptcha_events SQL table doesn’t existThanks for the details.
Given that the plugin was installed and updated normally, and the database user has CREATE/ALTER permissions, the most likely cause is the full-site restore from backup. The
hcaptcha_eventstable is a plugin-created custom table, so if the backup/restore did not include it, or restored the database/files from different points in time, the plugin settings could remain while the custom events table is missing.We have hardened this for the next release. The plugin will recreate/check the Events statistics table during activation and maintenance/admin flows, while normal frontend requests will no longer run table-existence checks.
After the next update, if the table is still missing, please deactivate and activate the hCaptcha plugin once. Do not uninstall it; just deactivate/activate. That should recreate the missing table. Existing historical Events statistics cannot be recovered if the table was not included in the backup, but new statistics should be recorded after the table is recreated.
Please let us know if the next update or deactivate/activate cycle does not recreate the table on your site.
Forum: Plugins
In reply to: [hCaptcha for WP] hcaptcha_events SQL table doesn’t existHi @postcd,
Thanks for reporting this.
The
hcaptcha_eventstable is supposed to be created during plugin activation and also checked during plugin maintenance/migration flows. We have added an extra hardening change for the next release: activation will force a physical table check/create, and normal frontend requests will no longer perform table-existence checks when the table is not marked as created. This should be included in the next release soon.To help us understand how your site got into this state, could you please tell us how the plugin was installed/activated or updated on your site?
For example:
- WordPress admin Plugins page
- WP-CLI
- Composer or deployment script
- hosting control panel / auto-installer
- staging/production clone or database restore
- multisite network activation
Also, if you noticed any activation/update errors, or if the database user does not have
CREATE/ALTERpermissions, please mention that too.We’re trying to determine whether the activation hook did not run, or whether the migration/maintenance step was skipped.
The WordPress plugin only loads and integrates the official hCaptcha code “as-is”. It does not control hCaptcha’s API responses, cookies, Cloudflare usage, or load-balancing configuration, so this cannot be changed from the plugin side.
So, unfortunately, I cannot help you.
Thank you, @michitortuga, for testing!
Preparing the release…
Thank you, @seanhybrider, I will collect answers from other users and release 5.0.1 soon.
@seanhybrider please read my last comment.
Forum: Plugins
In reply to: [Cyr-To-Lat] Problem with WooCommerce attributesSome of your earlier diagnostics around WooCommerce attributes were useful, and we used them while working on version 7.0.2.
The known and reproducible WooCommerce attribute issues reported to us were addressed in version 7.0.2. Several users reported WooCommerce attribute problems, tested the fixes, and confirmed their topics as resolved, including this topic’s starter.
If you still have an issue with the current version, please open a separate support topic. I need clear reproducible steps and the System Info from the Cyr-To-Lat plugin’s “System Info” admin tab.
To keep this resolved topic clear, let’s handle any remaining separate case in a new topic with full reproduction details.
Thanks for the detailed report and the update.
Concerning
__cflbcookie warning. The__cflbcookie is not set by the WordPress plugin or by your.htaccess.From your browser screenshot, the cookie is coming from:
https://api.hcaptcha.com/getcaptcha/...and the response is served by Cloudflare.
__cflbis a Cloudflare Load Balancer session-affinity cookie. In your response it is being sent withSameSite=Lax, and the browser rejects it because the request happens in a cross-site/third-party context.This is why browser reports:
Cookie "__cflb" has been rejected because it is in a cross-site context and its "SameSite" is "Lax" or "Strict".If hCaptcha still works, this is a browser warning rather than a functional failure on your WordPress site. It cannot be fixed by the WordPress plugin, CSP, or
.htaccess, because theSet-Cookieheader is returned byapi.hcaptcha.com.Only hCaptcha/Cloudflare can change that behavior on their side, for example by changing the Cloudflare load balancer cookie settings for that endpoint or by using a cross-site-compatible cookie policy such as
SameSite=None; Securewhere appropriate.If you want, you may report this to hCaptcha directly via hcaptcha.com and include the screenshot, the request URL, and the
Set-Cookie: __cflb=...; SameSite=Laxresponse header.Thanks,
I have found the issue and fixed it. Please try 5.0.1-RC1 and let me know.I was not able to reproduce the issue on my test site. Could you share System Info from the plugin and the link to the problematic page?
Hi @michitortuga,
Thank you for the detailed report. I will check the issue and come back with the update soon.
Forum: Plugins
In reply to: [Cyr-To-Lat] Проблема с заменой транслитерацииПлагину все равно, он должен менять. Но вообще-то он не для этого создан…
Forum: Plugins
In reply to: [Cyr-To-Lat] Проблема с заменой транслитерацииЕсли слаги уже сконвертированы, то откуда взяться кириллическим символам, подпадающим под конвертацию? У вас в текущих слагах уже нет “й” – конвертировать нечего.
Можно, конечно, предпринять рискованный шаг, если вы уверены, что все символы “j” – это следствие конвертации кириллических символов и вы хотите заменить “j” на “y”, например. В таком случае добавьте в таблицу пару “j” -> “y”, сохраните базу (!) и запустите конвертации в фоне с вкладки Converter.
P.S. А вообще, конвертация “й” -> “j” правильная, согласно стандарту ISO9. При разработке плагина мы уделили большое внимание точному следованию утверждённым стандартам.
Forum: Reviews
In reply to: [hCaptcha for WP] very goodThank you for your feedback!
Forum: Plugins
In reply to: [hCaptcha for WP] Glitch with Gravity FormsHi @goldenagemedia,
Thanks for the additional details.
This is an internal hidden field added by the plugin. Its position in the form markup is intentionally dynamic, so seeing it appear in different places is expected.
However, the empty label should definitely not become visible or affect your Gravity Forms layout. In your case, it looks like the custom styling for Gravity Forms labels is also being applied to this internal label.
I will make this more defensive on the plugin side so the label remains hidden even with aggressive custom form styling.
For now, you can use this CSS workaround:
.gform_wrapper label[for^="hcap_hp_"] { display: none !important; }A better long-term approach in the custom CSS would also be to scope the radio/button label styling only to actual Gravity Forms choice labels, for example:
.gform_wrapper .gfield_radio .gchoice label { /* custom radio label styling */ }instead of styling all labels inside the form.