arcaswebdesign

Understood, thanks for clarifying!

Rather than starting a new thread I thought I’d reply to this as this is one feature I think would be useful – either having a “select all” for the options which often have multiple tickboxes within (ie Disable Gutenberg and Disable Comments) or, ideally, applying to all *unless* you check some of the boxes in which case it only applies to them.

At present I’ll often choose to disable, then have to tick all the boxes, then have to come back and tick additional boxes as and when additional post types are created. Ideally it would be great to just disable all in one fell swoop?

The default Siteground caching mechanism is in place however previously I tested clearing this first before attempting to get past the PW screen but no joy. I’ve now added “?protected-page*” as an exclusion to their caching then used their test to confirm it wasn’t being cached but still had the same issue.

There’s no error message or anything, I simply get sent back to the same page with the password prompt again.

Given that you have a filter already there, might it be better for me to just write a function to hook into that and append it myself?

If you login via wp-login.php then no, you don’t, as the site lock is only in place for guests/non-logged in users.

The issue is purely in trying to access the site whilst not logged in. So it would be more about the page to which we are redirected after switching users needing to have the keyword appended to it.

So rather than choosing SWITCH TO USER and it reroutes you to the previous page or homepage or whatever it does, it would reroute you to that page with the passphase appended to the URL.

I guess if we were able to enable such an option then enter this somewhere in the plugin settings (so I would put “cmp_bypass=mykeyword” then the plugin would know to append that to the redirection URL after switching user)?

As mentioned it’s not a HUGE issue as might be rarely used but whilst this membership site is in development we need to lock it to general access but also test the user accounts.

Also experiencing the same issue.

No problem, it was my misunderstanding, I just find it easier if I’m going to be adding lots of code to use SASS and the plain text boxes are hard to control layouts for anything other than a few simple styles, it was my misunderstanding however.

Instead I’ll enqueue the file myself as detailed in https://www.intelliwolf.com/add-custom-css-wordpress-admin-area/

Oh wait, I think I was misunderstanding. I saw that bit to manually enter CSS overrides but thought the bit beneath that with the link to the custom stylesheet was so that I could put custom styles into that stylesheet instead, however is that just for the editor?

So there’s no option to provide a CSS *file* rather than entering all the overrides into that box?

That’s great, thanks Niklas and yeah we’re using Elementor to build that page.

Will leave it in place for now as it does no real harm!

Yeah they are showing up with this filter in place – should I just leave the filter there or does this simply guide us toward another adjustment we can make?

Confirmed I’m also getting this which unfortunately makes the plugin unusable for me.

Thanks for the reply Joost.

Firstly, yeah I can confirm we have enabled the “enable on single product” option checked but we have not checked this option for Google Pay hence why it doesn’t appear on the product page, however if I enable it and refresh then GPay *does* appear as expected.

I’ve also switched to the Storefront theme and confirmed that the button/text still doesn’t appear there either.

Let me know if you need any other info from me.

If it’s of any help, we had an issue recently whereby we were getting lots of links reported as broken which appeared to be fine, however there was an underlying issues.

The links were being reported as 500 (server error) faults rather than not founds, not sure if it’s the same as in your case @henrikfriis14a but there was a bug in a plugin we used to create WooCommerce pages, however the pages themselves displayed just fine when we checked them. Using a crawler tool, however, got the same error message as BLC. So whilst the links weren’t broken as such, there was an underlying issue.

We fixed the issue then cleared the link checking and it’s been fine ever since.

Just to say that I believe I have gotten to the bottom of this, at least in terms of getting rid of the errors – looks like an issue with the WooCommerceBuilder plugin as we noticed errors coming from it in the error log and rolled back to a previous version then confirmed they went away, re-checked using Uptrends and confirmed all okay – then rechecked using your plugin and the errors fixed themselves.

Still not sure why the page was displaying fine for users but showing errors for your plugin and for Uptrends but that seems to have been what was causing it.

Thanks for this. The error only seems to show for the product pages themselves, the main pages and category pages all show as responding fine.

One thing I noticed is that the URLs your plugin notes are long the lines of https://www.pinnaclefitness.org.uk/product/blitz-fitness-3in1-soft-foam-plyo-plyometric-jump-squat-box-block-fitness-new/ whereas the actual URLs on the site (and in the code of the page, as far as I can see) is https://www.pinnaclefitness.org.uk/blitz-fitness-3in1-soft-foam-plyo-plyometric-jump-squat-box-block-fitness-new/ (there is no /product/ part in the URL path)

The permalink structure under Settings>Permalinks is set to include that path but only because we are unable to remove it entirely, so we have another plugin called Permalink Manager which can and does.

Not sure if this matters as this has always been the case and your plugin has never erroneously flagged pages before? FYI I’m also checking things with the host.