linux4me2
Forum Replies Created
-
I confirmed that it is not the child theme, as the warnings still occur like clockwork with a plain-vanilla default theme.
Oh, I thought you had something in mind. I have a good host, and I’m sure they’ll make an effort, but I can’t imagine they will be helpful in this case. Still, it’s worth a try. If I still see the warning with the plain-vanilla default theme, I’ll see what they say.
Hi @t-p
What hosting-related issue are you thinking may be involved?
It was using a Twenty Twenty Two child theme, but there was nothing in the functions.php that related to WP_MEMORY_LIMIT, just some code to use SMTP mail and enqueuing the parent theme’s and child theme’s style sheets.
However, just to be sure, I switched it to the default Twenty Twenty Two theme using an untouched functions.php, and I’m going to check tomorrow to see if the warning recurs.
Hi @t-p,
Not the end of the file in my wp-config.php, it’s on lines 99 and 100:
// Increase the WP Memory Limit. define('WP_MEMORY_LIMIT', '256M'); /* That's all, stop editing! Happy publishing. */And it’s the only declaration for WP_MEMORY_LIMIT in wp-config.php. That’s the first thing I checked. : )
I just uploaded an updated version of the plugin, version 1.2.0, which includes some options in Settings > Menu In Post to tweak the behavior of the plugin’s handling of JavaScript.
Note that the little JavaScript file it uses on the front end is only required for drop-down-style menus, so one option is to never load the JavaScript, an option you can use if you only use the default, list-style menus to eliminate the HTTP request and the small overhead of the extra JavaScript file.
You can also limit the loading of the JavaScript to specific posts and pages, based on the post/page ID.
I did not see a good method of automagically doing conditional loading of JavaScript since the point at which it is done is prior to running the loop, where the data required to do so would be available. That may be why others are using inline JavaScript. I’m not a fan of inline JavaScript, and in any event, it could cause issues with the script loading on a page more than once if someone were to include more than one menu on a page, which would require yet more code to handle, so I went with the page ID approach.
There is also an option to not serve minified JavaScript if you so choose.
The default behavior of the plugin is unchanged, so if you don’t want to mess with any settings, the plugin should function as it always has, loading minified JavaScript on all pages.
I see that yesterday you released v. 3.17.1, which the release notes say includes “WordPress v6.2 compatibility fixes;” however, the “Compatible up to” still only shows WP v. 6.0.3.
So is it compatible with WP v. 6.2 now?
I’m not sure this is actually a “phase-out” plugin. I no longer use it, but it seems like the number of active installations is higher every time I look. I did consider switching it to a Block, but I didn’t want to leave all the current users of the shortcode version in the lurch, and I have seen no sign of WordPress abandoning the Shortcode Block…yet.
I take your point, though. Limiting HTTP requests is a good thing. Not only that, but the JavaScript is only required if you’re using a drop-down for the menu, so it’s unnecessary for a regular list-based menu. I actually added it to the plugin when someone requested the drop-down version, and didn’t really worry at the time about the overhead since the file is so small.
What I may do is add a Settings page to the plugin where those who are concerned about the overhead can set some options for boosting performance. For example, to limit loading the JavaScript to specific posts/pages by ID, and perhaps to load the JavaScript inline.
Thanks for the suggestion. I will post back here if I end up doing it.
Hi @mrclayton
I went back to the original, problem site which still had the Cart and Checkout Blocks, and switched the card form back to “Stripe Payment Form,” re-checked the Cart and Checkout pages in the back end, and there were no incompatibility warnings. The front end Checkout Page worked just fine.
Next, I reverted to the “Stripe Payment Form” card form, switched back to the shortcode versions of the Cart and Checkout pages, then edited the Cart and Checkout pages to remove the shortcodes and add the WooCommerce Cart and Checkout blocks. This time, I didn’t get any incompatibility warnings, and the checkout process went smoothly without errors.
In summary, I was not able to reproduce the issue, and both card forms I tried worked just fine. I have no idea what the problem was.
Hi @mrclayton
Interesting that you couldn’t reproduce it. The site with the issue is using the Blocks version that comes with WordPress/WooCommerce.
I have a few things I have to take care of first, but I will do some more testing to see if I can give you any more information.
Nope an old card wasn’t the issue. I deleted the existing payment methods and added a new test card, but it failed with the same “No payment method provided.”
I found the problem, though. What led me in the right direction was that there was no way to add a new card from the Checkout page.
In the WooCommerce > Stripe by Payment Plugins > Settings > Credit/Debit Cards, I had to switch “Card Form” from “Stripe payment form” to “Stripe inline form.”
Now, everything works, and I no longer have any incompatibility warnings in the page editor.
Hi @mrclayton
The problem appears to be associated with that particular test site, which is running WooCommerce 7.7.0.
I converted another site using Payment Plugins to the Cart and Checkout Blocks, and it did not show an incompatibility warning in the page editor, and the checkout process went without a hitch.
I’m wondering if the issue with the problem site is with the saved credit cards, which (possibly) could be left over from a previous payment plugin?
I’m testing that now.
Hi @mrclayton
Thanks for the lightning-fast response.
I just converted the Cart and Checkout pages back to the Blocks versions on this site <link removed>, which is set up on test mode for your plugin, so you can try a test card number and see the “No payment method provided” when you submit an order.
I just purged the cache (again) for the Cart and Checkout pages and tested again, getting the same error message on the Checkout page when I submitted the order. Very weird.
- This reply was modified 3 years, 1 month ago by linux4me2. Reason: link removed
Forum: Plugins
In reply to: [WooCommerce] WordPress database error Commands out of syncThanks @xue28,
Actually, WP Super Cache is now another Automattic plugin, but I get your point.
The fix I used was to delete both WP Super Cache and Autoptimize and use LS Cache for my caching/optimization solution. The WP database errors from WooCommerce have not recurred.
Forum: Plugins
In reply to: [WooCommerce] WordPress database error Commands out of syncI can’t explain the lag between the time I deactivated WP Super Cache and Autoptimize, and when the errors finally stopped–a few hours, maybe?–but there have been no more WP database errors since 25-Apr-2023 17:35:30 UTC. Maybe there were some queries in a cron task that hadn’t executed?
Anyway, I’m thinking that the issue was with WP Super Cache and/or Autoptimize, most likely WP Super Cache.