salmanjaveed

Hi @mrdaro

I have a temporary login link for the test site, can’t figure out how to send it to you.

@mrdaro

I did that and still the same problem persists. This is not a payment module problem. Making Paypal the default payment does show the personal info fields and then changing it to a different payment (radio button) hides the personal info form.

Tried this with “Test Payment” gateway too and the problem is still there. You can check the link now – I have made Paypal the default payment, changing it to credit card hides the personal info form.

Hi @mrdaro

I tried the health checkup – but couldn’t actually ‘catch’ a plugin. I think it is a problem with the Paypal Module in GiveWP.

I have removed the Paypal Option again for now.

Hi @mrdaro,

Thanks for your response. Yes, I have for now disabled the payment. Sorry, I missed the previous message.

I had temporarily removed paypal payments from the page. Now, I have activated it again to show you, please check it out soon, I have to disable it again, if it doesn’t work ??

The url is https://sheikhkafumbafoundation.org/donations

Regards,
Salman.

Hi @maykato

I resolved this with the Subaccounts & Multiaccounts plugin.

Posting it here, just to help some one who may require this in future.

Thanks for your help, helped a lot.

regards,
Salman.

Hi @maykato,

Thanks for the suggestion, looks like this will work for me. I’ll try it out and let you know.

Yes, you are correct about the load timing. But, in a limit starved shared hosting for a simple site like this could be a problem if the database size goes beyond a certain limit. I think, the option for caching for attachment pages would be a good idea, similarly, if there was an option to toggle on/off for tags (particularly in this case) it would almost resolve this issue.

Or could that be done by code?

There are 9347 records in the wp_posts table now and most of the ‘urls’ in guid are for ‘attachment’ post_types.

The site’s sitemap shows around ~7000-8000 attachment ‘urls’ and a considerable amount of ‘urls’ for ‘post tags’ (here I think it could be the post tags which could be the problem).

Hi,

Update:

Count	MB	Hours
Form Selects:	2	0.5	720.0
Head Markup:	10309	72.4	168.0
Image URL Info:	7	0.0	24.0
Schema Indexes:	29	0.1	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	10351	73.1

Updating the plugin seems to have ‘slowed’ down the bloat, but it keeps growing.

I am not worried about the 20mb or the even the 170mb+ getting created, I am more worried about the limits (150mb/table) imposed by the host. It makes the site unusable.

But, I will like to wait it out for a day or two and see what the size of the table is after that.

Count	MB	Hours
Form Selects:	0	0.0	720.0
Head Markup:	967	19.5	168.0
Image URL Info:	676	0.0	24.0
Schema Indexes:	8	0.1	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	1656	19.7

This is the latest count and keeps growing. And, we are not using any add-ons only the WPSSO.

I was wondering if we can just disable the db transients? What would be the downside of doing that?

There are 1329 records for ‘_transient_wpsso_%’ and 1362 ‘%_transient_timeout_wpsso_%’ records and in the next 1 or 2 days the total count will run upto 50k+ and after that the web-host denies permission to write to the database.

Salman.

Hi,

The below is ~1 hour after clicking the refresh button:

               Count	MB	Hours
Form Selects:	0	0.0	720.0
Head Markup:	646	17.7	168.0
Image URL Info:	675	0.0	24.0
Schema Indexes:	8	0.1	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	1333	17.9

But, the actual records in the wp_options table:
Showing rows 0 – 49 (2664 total, Query took 0.0056 seconds.)
SELECT * FROM wp_options WHERE wp_options.option_name LIKE ‘%_wpsso_%’

and, this too keeps increasing.

WPSSO Core Database Transients
               Count	MB	Hours
Form Selects:	0	0.0	720.0
Head Markup:	0	0.0	168.0
Image URL Info:	0	0.0	24.0
Schema Indexes:	0	0.0	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	0	0.0

This is the info. But, I had run clear caches from the plugin and there are no transients in the database for now.

But, they will be back in a day or two.

@wpscholar can you tell me if uninstalling and re-installing the plugin remove the ‘marker’ data from the database.

I think that removing the plugin and installing it again may clear the issue, I have tried various options with the dev site and I am unable to replicate that issue myself too. But, I did check that removing the plugin left the data in the postmeta table untouched. Can you confirm this, please?