inspiredmind

Thanks Abwaita,
I completely overlooked that. Yes, makes perfect sense.

I was going to ask a similar question. We had issues with loading our login page within WP Customizer. It was generating a 502 error on Nginx.

The hosting company looked into it for us, and noted that the DB Autoloaded Data is relatively high on our site. It’s coming in at 1,469,478 bytes, when 800,000 bytes is the recommended maximum.

An analysis showed that ws_menu_editor was loading the most, by a big margin.

+----------------------+---------------------------------------+
| LENGTH(option_value) | option_name                           |
+----------------------+---------------------------------------+
|               416009 | ws_menu_editor                        |
|               141378 | bfwc_default_settings                 |
|               108348 | wp_installer_settings                 |
|                63109 | fs_accounts                           |
|                58246 | asp_updates                           |
|                53651 | judgeme_widget_all_reviews            |
|                48781 | rewrite_rules                         |

etc.

I will test out the compression option. Is it likely to make a big difference?

Is there any way you can optimize the plug-in itself (in a future release), to require less DB Autoload Data? Perhaps there would be a way to save the menu order to a static file? As you know, the menu can be rearranged with a relatively small amount of code in functions.php file. So it seems it could be more efficient to cache the menu order settings to a static file, rather then having to read such a large amount of data from the DB every time a back-end page is loaded.

Regards,

Jonathan

• This reply was modified 4 years ago by inspiredmind.

Turns out it was the “Shield Security” plug-in causing the problem. Nothing to do with AAM at all. Closing this ticket.

I don’t have an answer to this, but want the same answer myself. If you find one elsewhere, please take a moment to post it here. I’d be very grateful.
Thanks… Jonathan

Thanks Job.

I’ve now created a ticket on woocommerce.com re this issue. Details are included in there.

Ticket number 1179825

Regards,

Jonathan

This exact same error message shows up very intermitently on my site too. It seems to only be when I view a particular product (which happens to be a “gift card” product type, generated with the YITH Gift Cards plug-in). So I was suspecting it had something to do with code in your plug-in not handling this custom product type correctly.

I’ll apply the changes you have suggested, and see if it goes away. I’ll let you know.

Also this link:

More info is here: https://currency-switcher.com.com/

and the “plugin codex” link:

Shortcode – just add in text widget [woocs width=’100px’] OR [woocs width=’50%’], all of them are in the plugin codex

Looks like you need to check ALL links on your description page.
Perhaps this is an issue of www.ads-software.com getting hacked? I suggest you report it to www.ads-software.com, because unless you set up your links to be this way (I hope not), then it would seem www.ads-software.com has been hacked.

• This reply was modified 7 years, 6 months ago by inspiredmind.

Another issue I don’t personally like about this plug-in, is that it renames the images. This broke images loading from Divi theme.

Hi Tom,

Thanks for the reply. I’d find it much easier to get support through your ticketing system. Is that system no longer working? Logging into public forums is far less convenient.

I will try out the dev version. Thanks for coding that solution so quickly.

The other issue I’ve raised (by email on your support ticket system, and in the comments of the plug-in page on your booster.io website) is that the currency conversion doesn’t get applied to coupons. Is any work being done to resolve that?

Cheers, Jonathan

Regarding the quantity option… and your comment…

I don’t see any option in the Stripe API that allows the customer to select a quantity in their payment window.

This could be accomplished with some javascript that will check on the value entered into a form field. That value would then be passed to the script that is handling the API interaction.

There’s a good example of this here:
https://goo.gl/LbVgZH

Any chance of your implementing something like that? It’s the #1 limitation I find in pretty much every Stripe plug-in I’ve looked at, including all donation plug-ins that support Stripe. In my opinion it makes all such plug-ins inadequate for taking donations, because it’s better if the end user has the means to specify exactly how much they wish to donate.

Thanks for this excellent plug-in.

I’ve also sent you the above via email (to [email protected]). I’ve receive no reply (in three days), and also no reply to another email I sent to your support address on June 15th, which I sent again on August 21. Is this plug-in still being supported? Since I have raised numerous issues with the Multi-currency functionality, and I’ve not heard back, I am thinking perhaps I should not rely on Booster for that function. Would you agree, or can these issues be resolved?

In the spirit of WooCommerce improving its suitability to more professional (high-end) e-commerce companies (which is a market Magento, and various other options make a point of catering to), I would also like to see core support for these basic product identifiers.

I have just give a couple of votes to this on the ideas.woothemes.com page.

Here is the comment I put on the idea: https://ideas.woothemes.com/forums/133476-woocommerce/suggestions/13639959-upc-field

As EAN/UPC codes are a universally recognised product identifier both online and offline, and are generally applied to any product being sold through multiple channels (e.g. sales occurring from channels other than directly from the manufacturer) I would like to see a field for this added to WC core, under Inventory. The overhead of this extra field, for those not needing it, will be completely inconsequential. Whereas the overhead of having to use a plug-in for such basic functionality is potentially much higher.

The most common globally recognised product identifies are EAN, UPC, and ISBN.

It was mentioned earlier in this discussion that there are very few requests for this feature. That surprises me. One possible explanation for that, to some extent, may be that the kind of companies who rely on things like EAN/UPC codes, are also the kind of companies that skim right past platforms like WooCommerce when considering their options for an e-commerce solution. Having been developing e-commerce solutions since 1998, I can say that in my experience options like WooCommerce (and the various other WP e-com plug-ins) where not typically considered by companies wanting a solid e-commerce platform.

I’ve seen that change, to some extent, in the last couple of years. But I think there is still much more potential for WC to expand into that market. Small additions, such as built in support for EAN / UPC / ISBN may be the very thing that would prevent a large company from skimming right past WC, thinking “Well, it doesn’t even support something so basic to the retail industry (as a universal product identifier)… how can it be a serious player?”

Whilst that line of thought is all hypothetical, I suspect there’s very likely some elements of truth to it. Again, I say that as someone who have been developing e-commerce solutions for nearly 20 years.

I suspect this plug-in has been abandoned.
At some point I might look into figuring out what’s wrong with it, and branch it to a new release. But for now, I don’t have the time. So, I’ll consider it missing in action, for now.

I am also facing this issue.
Just “switching to another hosting provider” is not always easy or convenient. In my case (as a reseller with my particular host, with over 30 sites, a billing system, etc., all tied into that host) changing hosts would be a mammoth task.

I would like to suggest the Jetpack developers add an option for the user to specify their API Endpoint URL on each blog they use WordPress.com app with. I suspect adding such as option would be a relatively simple thing to do, and it would make it possible for those of us who can’t directly access xmlrpc.php (without renaming it) to still make use of the WordPress.com app.

So often the case. Right after I asked this question, I thought to try using this:

echo get_stylesheet_directory_uri();

.. and it works.

It is still not clear to me why bloginfo('stylesheet_directory_uri') doesn’t return the full uri. Can anyone explain?

Thanks.