Hi @giushite,
You will need to change your PHP ini file’s memory_limit option. It is probably at 32M or so but you can bump that up to 64M or 128M.
Kind Regards,
Clayton
Thanks for reply,
but I have 256M in my PHP ini and 512 in wp_config.
I’m not sure, but problably it’s a query on users (70k record in my case).
There’s some query like these during the init of the plugin?
Looking for solution, I’ve been discovered that the problem is in Braintree_Install::update(). More precisely on include once of all value of Braintree_Install::getUpdates().
We have about 170k orders and 70k users. And a query with -1 parameter on these entities cause the bug.
@giushite Thank you for the reply. We will be adding a better solution for that update method in our next release so many records are not called at once. This update is not needed for new installs anyway but rather for merchants that were converting over from an old version of the plugin.
Thanks,
Clayton
Update; a patch has been added to the current version (2.5.2) so that new installs do not call the updates which are needed for sites using previous versions.
Great! Thank you very much 🙂
Which files are changed?
P.S. (OT) I’ve implemented a feature to store user with payment method in the Vault, and then proceed with the “::sale()” with the user’s vault id.
If you want I can open another topic for this feature (or by email).
Thanks again
Hi @giushite,
class Braintree_Install was changed.
Our plugin already stores the vaulted customerId against the usermeta table and uses it for transactions.
Kind Regards,
@mr.clayton I forgot to specify that we store data in vault even if in Woocommerce is enabled anonimous checkout.
When someone proceed to checkout without login, we create a Vault entries (only with payment method) and store there info in an order meta.
When and if the user log in, we update the Vault entry, and add a meta to user with is Vault id.
