David Anderson / Team Updraft
Forum Replies Created
-
Forum: Plugins
In reply to: [UpdraftCentral Dashboard] White Dashboard Page@momo2005 Version 0.8.31 had a bug; 0.8.32 was released a few minutes after you posted this, so please update to that and try again. If you still have a problem, then please open a new topic, as your problem may not be related to Greg’s, and he doesn’t need to see email alerts for someone else’s issues.
Forum: Plugins
In reply to: [European VAT Compliance Assistant for WooCommerce] Custom VAT ratesHi,
You can put in whatever VAT rates you like. The plugin, in its reporting section, will inform you that the rates look strange, if they’re not the main rates or most common reduced rates, but you don’t have to do anything with that information if you don’t want to.
David
Forum: Plugins
In reply to: [SSH SFTP Updater Support] Errors when attempting to update all pluginsHi,
The first error is the underlying SSH library, phpseclib, having a problem with the data its seeing. I’ve updated the bundled version (from 3.0.48 to 3.0.52 – https://github.com/phpseclib/phpseclib/releases), so, please update to today’s 1.1.2 version of the plugin, and try again.
The second error is a bug in your installed version of WooCommerce; it has code which attempts to set up a filesystem link, but does not check whether doing so succeeds or fails, and then it tries to use it to ask about a file. That attempt fails, because the question it asks can’t be answered either way in the case of a failed setup of the link. If that’s the latest version of WooCommerce, then you should report that to them.
David
Hi,
You can tell your development team that the fix they sent us appears to work – from having many fatal errors logged each day, there have now been none in the last 24 hours.
David
Hi,
You can use the contact form at http://www.simbahosting.co.uk. Presumably the test site is in sandbox mode? Can you supply me test payment credentials at the same time in order to be able to run through it all? Please also give me the details I need in order to see the problem in action, e.g. tell me which product to buy, and what address to enter at the checkout, etc.
David
Hi,
Thanks for this. For Stripe, that’s specifically (i.e. only) if one uses the “Express Checkout Element”, is that right? For payments where the checkout is ultimately off-site, then in general it’s not likely to be possible to comply with EU VAT regulations…. though *some* of the data can be gathered, since you can’t control the user experience on an off-site checkout, the plugin’s settings generally can’t be enforced.
For WooCommerce PayPal, for the button which it adds on the checkout page, they generally try to make WooCommerce go through the same code. Our plugin has some special code to integrate in order to handle the slightly different flow. So, as far as I know, it fully works with our plugin. Please do let us know if you discover something else.
I confess that I’ve never tried WooPayments. If you have a dev site that’s using it and things aren’t working, I’m happy to take a look.
In summary, the most important point as I see things is that off-site checkouts can’t be controlled, so generally, it’s difficult to support them. I’m reluctant to add “partial” support that leads site owners into falsely believing that things are working properly, and then having to discover by experience that some part of the regulations isn’t being adhered to. (Related to this,, I note the list of situations at https://woocommerce.com/document/stripe/setup-and-configuration/express-checkouts/ where express checkouts can’t be used). But I’m also fine with handling different gateways on a case-by-case basis, as they’re all different – hence, as I say, I believe the PayPal one works as it should.
David
(I re-opened the thread just so that you can see what the final solution was, in case that will be useful for anyone else in future. Though commenting out part of the theme’s code did also un-break things, since I had no other known problems and it was hard to decipher what all the consequences of disabling those parts of the theme were – it had stuff that hooked in to filter its own output buffer and make modifications to it – I’ve not done that).
Hi,
Thanks for getting back. It took me some time to work through this.
Ultimately I concluded that the most recent post from Nebu John is hallucinated (whether by him or by the developer he asked for help, I cannot say, and it does not matter to me!). The lines of code quoted from inside WordPress do not exist – either in the mentioned file, or any other file, in any recent version of WordPress (I didn’t check years-old ones!). Moreover, the description given of output buffering does not make sense (it assumes throughout that there is a single output buffer, whereas output buffers in both PHP in general and WP in particular are nested – for example, page caches use them); if something else nests inside WP’s buffer-handling, then that would be invisible to the relevant WP code and thus couldn’t itself cause a problem.
The problem is somewhere inside the theme, and relates to WordPress core’s code to “hoist” outputted styles from the footer into the header, which is where output-buffering does come in. I don’t have time to investigate exactly how it clashes, but the theme’s code contains assumptions that clash with the assumptions WP makes about how enqueued resources can be moved around; the comments in the function
wp_start_template_enhancement_output_buffer()give some clues as to what the theme might be doing wrong, but being short of time, I’ve just short-circuited it all with:add_filter('wp_should_output_buffer_template_for_enhancement', '__return_false', 999);I expect that this slightly hurts browser rendering performance, by leaving CSS in the footer instead of the header. I can live with that!
Thanks for your help.
David
Hi,
Thanks for this report. At this time, the plugin hasn’t made any attempts (i.e. we haven’t written any code to) support orders placed through the store API; we only support orders made through either the WooCommerce checkout (both the shortcode checkout, and the Gutenberg checkouts are supported). When placing an order through the store API, it’s not possible to support several of the plugin’s features. For example, if the VAT country and IP address country conflict, on the checkout, this can be resolved by asking the customer to self-certify. You’re not necessarily, of course, using that feature.
Perhaps you can explain more of your use case so I can understand more of what you’re trying to achieve? Evidently customers don’t use the checkout page to place orders.
David
Forum: Plugins
In reply to: [SSH SFTP Updater Support] PHP warning in sftp.phpHi,
Thank you for the report. This is fixed in today’s release of version 1.1.1.
David
Hi Nebu,
Please can you clarify – are you asserting that a theme is not allowed to do this, that in some way it’s incorrect? As a WordPress developer, there’s nothing invalid that I’m aware of, and it is not preventing every other plugin on the site from enqueuing its resources. Why does it prevent Forminator? Will you be documenting this somewhere so that theme authors can be aware of what you don’t allow them to do – or is it something that Forminator will in future fix?
David
P.S. And, as you’ll be able to see in the theme source, yes, the theme uses a shutdown hook and buffering.
Thank you; I have emailed the requested information.
Hi,
Thanks for the reply.
I added a PHP filter to switch to the TwentyTwentyFive theme on that page. This has fixed the layout there. So, it must be something in the theme. What sort of thing should I look for? Note that the CSS file in
wp-content/uploads/forminator/*is* being enqueued on the page after changing the theme (as you can see by visiting the page previously mentioned and viewing the source), whereas on the default theme, it wasn’t. So, in some way, there is a conflict whose consequence is that Forminator does not enqueue its resources on the page.David
P.S. The ww.wp.xz.cn forum rules do not allow either requesting or sharing of login credentials.