thisisbbc

Hey Jeff,

Thanks for the quick reply.

If I understand well, if we have configured a “PAGE” post-type setting and mysite.com/showcase/ is a page, the checkbox “Also Affect Children” just won’t do anything, because all child page would be targeted by the post-type setting, is that right?

I’m not sure I understand how to use this checkbox or the plugin filters. It looks to me as if, if you use post-type settings, then you can’t use “Affect also children” or the Plugin Filters.

My understanding is that post-type settings are very broad and target many pages/posts at once.

Then going into each individual post/page we can override these settings. I was under the impression we could enable the affect children checkbox and have all pages in the subset mysite.com/showcase/* use a different configuration compared to the global page post-type setting.

Apparently this is not the case, which is a bit of a bummer.

I would have used a plugin filter with the permalink mysite.com/showcase/* (combined with setting “Also Affect Children”, but again, post-type settings take priority.

Is it possible at all to have a “global” post-type setting and replace a subset of pages using one single rule instead of going into each individual post/page and override the rules?

Thank you!

• This reply was modified 6 years, 10 months ago by thisisbbc.

Hey Jeff,

That’s definitely a way to achieve what we need.

As long as we can hide the column in the screen option settings that should be fine!

Thanks for your consideration.

Hello Slava,

Thank you for the quick reply.

We found the culprit, we use an optimization plugin called Plugin Organizer.

We had set WP Mail SMTP to be disabled globally as we were under the impression all the magic happened in the back-end but apparently you still need to call something from the front-end to fire your function.

Since I was not able to pinpoint which WooCommerce page(s) needs WP Mail SMTP to be enabled to work properly, can you tell me what hook your plugin is using to replace the wp_mail() function?

To fix our issue we have to:
-> Disable WP Mail SMTP globally (optional, but good for optimization)
-> Enable WP Mail SMTP on all “page” post_type
-> Disable WP Mail SMTP on all “post” post_type (optional, but good for optimization)

When we do this it works.

Since we do not need to send an e-mail on every pages, we’d like to enable WP Mail SMTP strictly for the required pages like the checkout page. This is what we tried:

-> Disable WP Mail SMTP globally
-> Disable WP Mail SMTP on all “page” post_type
-> Disable WP Mail SMTP on all “post” post_type
-> Override “page” post_type rule and enable WP Mail SMTP on site.com/checkout/*

Did not work.

We also tried to add the following rules:

-> Override “page” post_type rule and enable WP Mail SMTP on site.com/cart/*
-> Create plugin filters permalink rule and enable WP Mail SMTP on site.com/wp-admin/admin-ajax.php*

Did not work as well.

If we can pinpoint the right page / permalink structure to enable WP Mail SMTP, we will be able to only enable it when it is needed.

Appreciate the help!

Thank you.

Thank you for the quick reply!

Looking forward to the next update 😉

Have a great day ahead.

@danieliser – Clever suggestion indeed. Unfortunately I’m afraid this doesn’t work, bummer.

I did some further tests and managed to get something working by using UberMenu special element “Custom Content“, then added our <a> tag in here. I’m not sure exactly how differently UberMenu handle those elements but I guess the important thing is that it works!

Thanks for your help!

• This reply was modified 9 years, 3 months ago by thisisbbc. Reason: Wrong markup

I agree that I may have been a little harsh with my review here and I’m bumping this to three stars for the quick reply which is something we don’t see enough nowadays.

The thing here that is important to note is that our page did load fast before we installed SBP. We were only looking to follow some suggestions indicated by GTMetrix (which should in return improve the performance). A page load of ~1.8s and ~75 requests for logged in users is satisfying. It’s not bleeding-edge fast, but fast enough. For logged out users, the page was loading very fast as well, probably even closer to the 1s range.

After the plugin was installed and we started deferring JS files, this increased drastically to well over 5s and the numbers of requests spiked to ~800. The overall performance of the website also decreased significantly.

Unfortunately it looks like there may be some incompatibilities with other plugins in our environment. I realize the challenge it is to ensure compatibility across the WP ecosystem so I may as well just remove this review unless you want to investigate further on the issue.

Kind regards,
B