RafaelDeJongh

Yea doing it per code is for me a whole lot faster as I then do not have to recreate existing shapes. As this is just slightly adjusting the look and feel of the admin panel to modernise it, it won’t take much other than changing various colours to give it a fresh new look. I’ll stick with the basic BPS blue but I’ll most likely will go in the ways of flat or material design use ages when it comes to colours and shadows.

I’ll also be honest the last time I actually made a mockup in photoshop was 6 years ago. These days it’s a lot easier to utilise other tools which are more precise and fitted for this kind of work IF the design of it would completely change rather than what I have in mind to just modernise the current theme.

But yea that’s something for in the future.

To be honest it’s faster for me to create a mockup design with code than with Photoshop.

It’s not for the near future as my agenda is piling out, but it’s something that I actually had on my personal todo list for some time.

But yea, I’ll get back to you once I’ve got something to show ??

Seems I did not get the first announcement that there was a reply. But nice to hear I can utilise the Wizzard to utilise code from there to do what I require.

My theme suggestion would be merely a visual change, so just basic CSS that would change the appearance of it. I could provide some mockups if wanted of course.

Thanks either way for the reply!

@suzannepinchin

I currently put a sort of fail safe in place until I get further support which till now I haven’t gotten. But the code I used pretty much removes the whole #payment area (including the buy button and what not) on the actual checkout page as the warning for that you still don’t have enough in your cart is still present when this happens (or it should at least). So based on that I wrote this code snippet to be put in your functions.php

add_action('woocommerce_after_checkout_form','amount_add_jscript_checkout');
function amount_add_jscript_checkout(){echo '<script>(function($){if($(".woocommerce-error span").hasClass("woocommerce-Price-amount")){$("#payment").remove();}})(jQuery);</script>';}

Pretty simple code snippet that will just remove like mentioned before the whole #payment section when it finds a woocommerce-error with the class woocommerce-Price-amount on the page.

Hope it will also help you in the mean time before we actually can get some reply from the original author(s).

@bizswoop

That sounds awesome, I’ll keep an eye out for it ??

Hi there

Thanks for your reply, I currently have somewhat solved it by adding a cron job to clear the cache a couple minutes after your plugin takes into effect:

//Cache Clearing on time
function shopHoursCacheClear(){
	Swift_Performance_Cache::clear_all_cache();
	Swift_Performance::prebuild_cache();
}
add_action('cronCacheClearOpen','shopHoursCacheClear');
add_action('cronCacheClearClose','shopHoursCacheClear');
wp_schedule_event(strtotime('14:02:00'),"daily","cronCacheClearOpen");
wp_schedule_event(strtotime('02:02:00'),"daily","cronCacheClearClose");

It therefore might be interesting perhaps to have a hook or so where we can add a specific function to when the plugin triggers its functionality. Like here clearing and prebuilding the cache.

@bizswoop

Most definitely, thanks a bunch for the great support and development of your plugin!

@bizswoop

Thanks I just managed to check the update, while the new features are there it is still lacking the feature request regarding the body class that I am after. Placing the bar itself is handy but I was actually more referring to having a body class enabled when the bar is active so that I can move the cookiebar up rather than the alert bar.

So how I would love to see it is that when the zhours alert bar is active and working that there is a specific zhours class added to the body classes so that I can say to alter anything like hide specific stuff and change other parts of the site whenever the bar is active and the store is closed.

This certainly would come in handy, and while the custom positioning is handy, it is not directly something I require as I would be able to modify this part as well easily with CSS but I wouldn’t be able to modify other parts AROUND the alert bar when it is active as there isn’t any class to select a specific element based on the alert bar being there or not.

So if anything I’d love to see that when the bar is active and the store is closed that there is a general class added to the body which we then can utilise to modify other elements on the site in the way like body.zhoursActive #cookieBar{top:30px} for example, currently this is not really possible without a lot of tweaks and that’s a bit of a shame.

Either way thanks and I do hope to see this in a future revision!

Cheers! Just updated!

Awesome to hear! Thank you in advance, such a body class would really help with altering different parts on the site whenever the store is closed!

Thanks in advance, and especially for the fast reply!

Alright not a problem, I am using the latest PHP7.3 on my server but other sites that are also on it are running between 7.0 (which is the server’s default) and 7.1/7.2.

As these are still shared web servers I can’t directly go into editing any apache mods myself or enable/disable any.

I’ve made a complete fresh install with only BPS installed and I directly get the error when I activate the plugin.

So I am pretty sure it has something to do with my hosts server security mod configuration as they also have some additional recaptcha verification when logging into the back-end which is completely done by the webhost rather than something you can configure (or even disable).

So yea this is certainly a very specific unique and isolated hosting environment problem rather than BPS, I still do not know why disabling BPS would make it work though.

But I can confirm this is not the plugin itself as well as I tested this on a different webhost and it didn’t had this problem at all.

So for me the htaccess code fixes it for me, but this is really something isolated and not an actual problem of the plugin itself.

Thanks a bunch @aitpro for the continuous assistance and perhaps if anyone ever has a similar issue then I guess they also just require to white list it like I’ve done.

Either way thanks and I’ll mark this as resolved.

Yea exactly that’s also why that didn’t really make sense to me as the htaccess doesn’t change even if the plugin is deactivated, yet it does work when the plugin itself is deactivated.

And as you can see there’s really nothing in the htaccess file referring to restricting xmlrpc.

And yea with the code I’ve written it works without problem, as if I add my own IP to the allow list I can access it without any problems either. So it seems to be restricting it to some degree but when white listed it does work.

As mentioned the other sites that are also getting those 403 pages on the xmlrpc page don’t even utilise Zapier, so it really doesn’t have anything to do with Zapier. It might have something to do with Mod Security but then again then I should still receive a 403 error page when the plugin is disabled as well right? But it only appears when it is activated.

If you want I can setup a custom Cpanel/WP on one of the servers and provide you with all the login details if you want to spend the time to look into it for future problems like this?

In general for me I pretty much fixed it by writing that htaccess code, so I can proceed with what I need it for, but perhaps for other users that aren’t that familiar with htaccess or server settings in general might not get to that same realisation.

Feel free to pass me an e-mail I can send you the info to if you’re interested. Else I just put this on “resolved” even though I am also still very confused to why this is happening only on this host and only with BPS plugin active.

Thanks either way for your assistance in this!

@aitpro

The htaccess code is something I’ve wrote myself when I was troubleshooting, I’ve actually never experienced this before and when testing on all the websites that I’ve got this installed on (which are on various different servers) I get the same problem with them as well and they’re not even using Zapier but that’s pretty much just the connection/access to XMLRCP, example:

https://www.rafaeldejongh.com/xmlrpc.php
https://www.sandhillsstudio.com/xmlrpc.php
https://www.boaztimmermans.com/xmlrpc.php
https://mrj.agency/xmlrpc.php

These are all on different servers and with all different kind of themes/plugins the only thing they have in familiar is BPS. The first link for example doesn’t use Swift rather uses WP Rocket.

I’ve tried without caching plugin but that didn’t change anything either, it is only when activating BPS that the blocking starts.

The only thing I can imagine is that it has something to do with server configuration? As while they all are on a different shared webhost, they are on the same webhost seller being NeoStrada.

I just checked a site from one of my clients with BPS installed on another webhost and for some reason there it doesn’t seem to have any conflict.

So I am really not entirely sure to why it would behave such a way on this particular server. I also tried this on a complete clean install WP site on Neostrada and it indeed had the same problem.

Would any of the security modules or so affect BPS to block it when the plugin is activated? If you need any testing account I am happy to provide you with one.

That said however with the htaccess code I’ve mocked up I could possible just Allow All if needed but on the other side it’s not a bad thing to restrict XMLRPC either to prevent brute force attacks I assume.

So yea really not sure what’s going on here, but it does seem localized to the webhost as a whole even if all the sites linked above are on different shared hosting accounts.

@aitpro

Zapier pretty much just gets posts via XMLRCP and then uses it to distribute it to other platforms like Facebook, Twitter, Instagram, Linkedin, Discord, etc. It doesn’t require plugins or any other kind of integration just an account that you setup on their site and yours and that XMLRCP is accessible, so there’s not really a conflict directly with BPS as far as I know.

Even when I try to access the file via my browser instead of getting the normal message: XML-RPC server accepts POST requests only. I also get:

nendoaddicts.be 403 Forbidden Error Page

If you arrived here due to a search or clicking on a link click your Browser's back button to return to the previous page. Thank you.

IP Address: X.X.X.X

I’ve checked all settings and I’ve not changed anything other than using the Wizard and adding the security headers/swift caching code via the custom code. I also couldn’t find anything related to this and when I actually white list either my direct IP or via useragent on that specific file in the htaccess then it seems to work without any problem.

If you’d like to have a look on the site I can always provide you a temp login if that helps you find out the problem? As now that I am checking this on all my other sites where I am using BPS I am also receiving this access 403 error page when trying to access xmlrpc.php directly.

So it doesn’t seem to be an isolated problem for this particular website?

@aitpro

The actual plugin to be honest via the dashboard to be honest, and I do think the htaccess files are kept even when disabling the plugin. So I can connect to XMLRPC.php when the BPS plugin is disabled with both the root and admin htaccess files still in tact, but not when I have the plugin activated.

Currently I’ve been troubleshooting and came up with the following htaccess code:

<FilesMatch "xmlrpc\.php$">
SetEnvIfNoCase User-Agent Zapier xmlrpc_access
Order Deny,Allow
Deny from All
Allow from env=xmlrpc_access
</FilesMatch>

As Zapier uses a specific User Agent this seems to actually work pretty well, I have placed this under block 13 (13. CUSTOM CODE DENY BROWSER ACCESS TO THESE FILES:) and that does make it work.

However that doesn’t explain why BPS itself (as the plugin) is blocking the access to it right?