Math Vault
Forum Replies Created
-
The Settings page display issue seems exclusive to FlurentCRM V3 built on the Vue V3 framework. To troubleshoot further, we have gone incognito under both Brave and Chrome Browser, but the Settings page appears blank by default. We also run the same WordPress setup under Oracle Cloud hosting, but despite using only 1/6 of full RAM capacity the issue still remains.
Basically, for some reason the Settings page “disappears” when the device width exceeds 782px (probably related to @media). This explains why on iPhone the Settings page is displayed correctly—save some hiccup where the Settings page’s sidemenu is appended to the page’s bottom (instead of to the left).
New development. We’ve looked at all errors in the console but they turned out to be red herrings. With WP_DEBUG_DISPLAY set to false there is no actual error in the log. However, when WP_DEBUG_DISPLAY is enabled the displaying issue causes the Settings page content to come out.
And when the font size is increased far enough it’s technically possible to see all content in the Setting page. Even when WP_DEBUG is turned off one can increase the font size to make the Setting page come out, suggesting that the blank screen is actually a display issue.
Some record keeping: this is replicated with Google Cloud hosting, Ubuntu 24.04.03 LTS, OpenLitespeed 1.9.1, MariaDB 10.11.14 (Server) and lsphp84 (8.4.23). It’s reproduced in Troubleshotting Mode with WordPress 7.0.2, the Twenty Twenty-Five theme and the FluentCRM 3.1.8 plugin only.
The debug.log being generated doesn’t look very relevant to the issue:
“[25-Jul-2026 07:30:00 UTC] PHP Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the
health-checkdomain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at theinitaction or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6170
[25-Jul-2026 07:30:03 UTC] PHP Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for thehealth-checkdomain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at theinitaction or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6170″We got the same problem. For any FluentCRM version from 3.0.0 onward, the Settings page displays blank screen. Setting the theme to Twenty Twenty Five and removing all plugins in Troubletshooting Mode doesn’t help.
However, downgrading to FluentCRM to V2 would work, but this obviously should not be the way forward. The blank screen persists whether we use PHP 8.3 or PHP 8.4, suggesting that it may be a compatibility issue.
Thanks for the quick heads-up. Definitely aware of the possibility of caching issue getting in the way. To be sure, I only discovered the issue yesterday, but have since then tried changing the browser, purging the cache from plugins and Cloudflare. Also tried the elimination method by disabling the theme and plugins one by one. The link redirection seems unaffected though (and this even when BestAzom is disabled).
Actually, I’ve made some progress along the way, and here’s the backstory: I usually edit a page through Thrive Visual Editor, and I would link a book to its untagged Amazon US product page. With the page saved this way, when BestAzon is off the book will link to the original untagged Amazon page, and when BestAzon is on it would be redirected to Amazon’s tagged page (depending on the BestAzon setting being used). I actually just tested it and it shows that BestAzon is functionally properly.
Interestingly, I just discovered that the reason why the links on the book page became uncorrectable was because I edited the page in Thrive Visual Editor while BestAzon was activated, so that when the page is saved, all the books are now officially linked to something starting with http://lnks.io (i.e., the redirection is now hard-baked into the page itself). Once that happens, it seems that no amount of honoring existing tag or deactivable BestAzon would recover the link back to its original state.
So I guess the lesson here is to always deactivate BestAzon before editing any page with Amazon links. Yeah, sounds like a chore I know, but is well worth the effort especially for folks with hundreds of Amazon links on their site.
Thanks for the help!
- This reply was modified 9 years, 1 month ago by Math Vault.
- This reply was modified 9 years, 1 month ago by Math Vault.
- This reply was modified 9 years, 1 month ago by Math Vault.
Cool. Thanks for the explanation and the efforts put into the development!
Actually, recently we had to change to new affiliate IDs, and no matter what we do in BestAzon setup the link redirection just keep redirecting to the old affiliate IDs. That was finally resolved by redoing all the links so that they are clean. Maybe Amazon changed something on their end too, but that is just something worth considering if you recently change your affiliate IDs and are having redirection issues.
- This reply was modified 9 years, 6 months ago by Math Vault.
Oops. For some reason there is no notification sent about your replies. Thanks for the quick response by the way. Yeah, the issue seems to have completely disappeared. Perhaps it was due to a caching problem with the browser. It’s gone by now. Cheers and thanks a bunch!
Forum: Plugins
In reply to: [Shortcodes by Angie Makes] Tabs and Accordions no longer work in WPAll right. After more research, figured out that it’s jQuery incompatibility with the theme version we’re using. Updated the theme and now everything is fine. Kudos guys. 🙂
Forum: Plugins
In reply to: [Shortcodes by Angie Makes] Tabs and Accordions no longer work in WPJust an update. Still haven’t manage to solve it yet. But just want to say that the tabs and accordions do work in the backend when we preview the posts — just not when we log out of the dashboard though.
Also, dig into the HTML code a bit, and identified that the reason why tab/accordion links are taken to the top of the page, is because tab/accordion content isn’t loaded in the first place — Hence the empty links.