Ruman Ahmed

Hello @sevenseconds777,

Thank you for reaching out and sharing the detailed information.

You’re absolutely right that Japanese Yen (JPY) is a zero-decimal currency, and it should typically be displayed as ¥1,000 rather than ¥1,000.00.

In FluentBooking, the “.00” you’re seeing is due to the default global currency formatting: https://prnt.sc/QC4mtNbkhPjp, which uses two decimal places. This is only a display issue and does not affect how the amount is actually processed.

For Stripe payments, FluentBooking already handles zero-decimal currencies like JPY correctly. That means an amount such as 1,000 JPY is sent to Stripe as 1000 (not 100000), so the decimal formatting itself should not be the cause of the payment failure.

If you’d like to fix the display format, you can use the following filter to remove decimal points for JPY by using the code snippet plugin like FluentSnippets:

add_filter('fluent_booking/global_currency_settings', function ($settings) {
    if (($settings['currency'] ?? '') === 'JPY') {
        $settings['decimal_points'] = 0;
    }

    return $settings;
});

If payments are still failing after this adjustment, the issue is likely related to something else, such as:

• Payment gateway currency support
• Account or country restrictions
• Payment method limitations
• Minimum/maximum transaction limits
• A specific error returned by Stripe or PayPal

To investigate further, we would need to check the exact error message or logs from the payment gateway. Please share any error details you’re seeing, and we’ll be happy to help you pinpoint the issue.

Thanks again, and looking forward to your update.

Best regards!
Ruman Ahmed.

Hello @3yq9nfgnvh,

Thank you for sharing the detailed information. This issue is most likely caused by a stale error flag in FluentSnippets rather than the current snippet code.

FluentSnippets stores runtime errors in the generated index file located at:

/wp-content/fluent-snippet-storage/index.php

Within this file, errors are tracked in the error_files array. If a snippet previously triggered a fatal error, that error state may persist even after the code has been corrected. Recreating the snippet may not resolve the issue if the same filename or cached index entry is still being used.

Recommended Fix:

1. Navigate to:
   /wp-content/fluent-snippet-storage/
2. Create a backup of the folder.
3. Delete only the following generated file:
   index.php
4. Reload the FluentSnippets admin page:
   /wp-admin/admin.php?page=fluent-snippets#/

This will force the plugin to rebuild the index file based on the current snippet files. If the underlying issue has already been fixed in the code, the previous error (e.g., related to trim()) should no longer appear. Additional Step (if needed)

If the issue persists or the site behaves unexpectedly, you can temporarily enable Safe Mode by adding the following line to your wp-config.php file:

define('FLUENT_SNIPPETS_SAFE_MODE', true);

After enabling Safe Mode:

• Reload the FluentSnippets page
• Review or reactivate the snippet safely
• Remove the Safe Mode line once everything is confirmed to be working correctly

This approach ensures a clean reset of the cached error state without affecting your actual snippet files.

Best regards!
Ruman Ahmed.

Hello @postcd,

Thanks for the detailed report and the investigation you’ve already done, which really helps narrow things down.

What you’re experiencing is usually caused by a mismatch between the snippet files in storage and the internal registry that FluentSnippets builds for performance.

Why this happens: FluentSnippets does not rely on the database for snippet listing. Instead, it scans:

/wp-content/fluent-snippet-storage/ (actual snippet files)
/wp-content/fluent-snippet-storage/index.php (generated registry/cache)

When snippet files are manually renamed, removed, or partially restored, the registry can become out of sync with the filesystem, which results in:

1. “Ghost” snippets still appearing in the admin UI
2. Snippets show as active even when the file is missing
3. Deletion messages are succeeding, but the UI is not updating correctly

Important clarification: Renaming files with a leading underscore (e.g. _snippet.php) is not enough, because the plugin still scans all .php files in the directory. Those files will still be indexed.

To fully exclude a snippet, it must:

1. Either be removed from the folder entirely, OR
2. Has its extension changed so it is no longer .php (for example, .disabled or .bak)
   Recommended recovery steps

Please follow these steps carefully:

Enable Safe Mode: Add this to wp-config.php:

define('FLUENT_SNIPPETS_SAFE_MODE', true);

This prevents any snippet execution while you repair the state.

Back up snippet storage: Make a backup of:

/wp-content/fluent-snippet-storage/

Disable all scanned snippets: Inside the storage folder:

Rename all .php snippet files so they no longer end in .php
Example: snippet.php → snippet.php.disabled

OR move them temporarily outside the directory.

Reset the registry cache: Delete this file:

/wp-content/fluent-snippet-storage/index.php

This forces FluentSnippets to rebuild its internal registry from scratch.

Reload the admin screen: Go to:

/wp-admin/admin.php?page=fluent-snippets#/

The snippet list should now be rebuilt based on the actual current files.

If the issue persists: If old snippets still appear:

Flush any object cache (Redis/Memcached if active)
Clear browser cache / hard refresh
Ensure no duplicate storage directories exist from reinstall attempts

Hopefully, this might help you in this matter. Please let me know if you have any further questions or if there’s anything else I can assist you with.

Best regards!
Ruman Ahmed.

Hello @postcd,

Thank you for sharing the detailed information.

For FluentSnippets, snippet groups are not stored as separate editable records. Instead, the group list is dynamically generated from the Snippet Group value assigned to each individual snippet.

So, to correct a typo in a group name, please follow these steps:

1. Go to FluentSnippets > Snippets.
2. Open each snippet that contains the incorrect group name.
3. Update the Snippet Group field to the correct spelling by adding new Group Name.
4. Save/update the snippet.
5. Repeat this process for all snippets using the incorrect group name.

Once no snippets are using the old (typo) group name, it will automatically disappear from the group list.

Please let us know if you have any further questions or if there’s anything else we can assist you with.

Best regards!
Ruman Ahmed.

Hello @fossist,

Thank you for sharing the detailed information, and apologies for the delayed response.

Regarding the 2FA issue, could you please update FluentAuth to the latest version (v2.1.2) and test the behavior again? There have been recent improvements and fixes, so updating might resolve the issue.

After updating, kindly clear your site cache and browser cache, then retest the One Tap Login functionality.

If the issue persists, please share a short screen recording or a few screenshots of your setup. This will help us take a closer look and assist you more effectively.

Please let us know the update.

Best regards!
Ruman Ahmed.

Hello @marcoh2021,

Thank you for reporting this and for sharing your setup details.

FluentAuth currently supports 2FA reliably when using the default WordPress login flow as well as FluentAuth’s own login shortcodes/forms. If a custom login form, such as one built with Bricks, handles authentication via its own AJAX or custom login process, the 2FA step might be skipped. This happens because the flow does not pass through FluentAuth’s 2FA handler.

As a workaround, we recommend using FluentAuth’s login shortcode on your Bricks page, for example: [fluent_auth_login] or [fluent_auth]. Alternatively, you can configure your custom login form to use the standard WordPress authentication flow instead of a custom/AJAX handler.

Regarding Authenticator Apps: at the moment, FluentAuth supports email-based 2FA. Support for TOTP/Auth apps (such as Google Authenticator, Authy, 1Password, etc.) is not available yet. However, we’ve noted it for consideration in future updates.

Please let us know if you have any further questions or if there’s anything else we can assist you with.

Best regards!
Ruman Ahmed.

Hello @deepblue5,

Thank you for your detailed question.

I would like to inform you that FluentAuth is designed to provide strong authentication and login security for WordPress sites. It effectively covers key areas such as 2FA/MFA, login hardening, brute-force protection, and improved access control. This makes it a solid choice for protecting user accounts and reducing risks related to unauthorized access or weak credentials.

However, it’s important to note that FluentAuth focuses specifically on the authentication layer. WordPress security is a broader, multi-layered concern that also includes areas like malware scanning, firewall protection (WAF), vulnerability monitoring, file integrity checks, and server-level hardening.

Because of this, FluentAuth should not be considered a complete replacement for full security solutions like Wordfence, Sucuri, or similar tools that provide these additional layers.

For the best overall protection, we recommend using FluentAuth alongside other security measures such as a WAF (e.g., Cloudflare), regular backups, and a vulnerability or malware scanning solution.

In short, FluentAuth is excellent for authentication security, but it works best as part of a layered security setup rather than a standalone, all-in-one security solution.

Hopefully, this might help you in this matter. Please let us know if you have any further questions or if there’s anything else we can assist you with.

Best regards!
Ruman Ahmed.

Hello @heval1,

Thank you for sharing the detailed information. However, I will take this as a feature request and forward it to our R&D team for further investigation. Hopefully, they will conduct a thorough review and pass it on to our development team for future implementation.

Best regards!
Ruman Ahmed.