Hi,
Thanks for the report, and sorry for the trouble.
There are two separate things happening here:
1) Why it’s showing on your site
That line is a PHP notice, not an error — it doesn’t break anything. It’s only appearing on your live site because debug display is currently switched on in production, which normally should be off on a live site. The quickest fix (and best practice) is to open wp-config.php and either set:

define( 'WP_DEBUG', false );

or, if you’d like to keep logging but stop notices from showing to visitors:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Once debug display is off, this notice — and the WooCommerce ones — will no longer appear at the top of your site for visitors.
2) The actual cause
The notice comes from the theme registering a Tutor LMS–related stylesheet (interioz-tutor) that declares tutor-frontend as a dependency. WordPress 6.9.1 introduced a stricter check that warns when a declared dependency isn’t registered — which happens when the Tutor LMS plugin isn’t active on the site. So:

If you don’t use Tutor LMS: the notice is harmless, and turning debug display off (above) is all you need.
If you do use Tutor LMS: please make sure the plugin is active and up to date, which registers the tutor-frontend handle and clears the notice.

Either way, I’ll log this with our developer so the theme only declares that dependency when Tutor LMS is actually active — that’s the proper long-term fix and will come in a theme update.

Let me know if you’d like me to apply the wp-config.php change for you, or if anything still shows after debug display is turned off.
Thanks,
Serkan

Hi,

Thanks for the update — good to hear the button is showing again. Let me take both points in turn.

1) The missing payment button (and the CSS you added)

When the button disappears intermittently like this, on both mobile and desktop, the cause is almost always a JavaScript conflict on the checkout page. The usual suspects, in order of likelihood:

– A caching / speed / optimisation plugin that minifies, combines or defers JavaScript. This very commonly breaks WooCommerce checkout. If you have one (WP Rocket, LiteSpeed Cache, Autoptimize, W3 Total Cache, SG Optimizer, etc.), exclude the cart, checkout and my-account pages from the cache and turn off JS combine/defer — or temporarily switch JS optimisation off to test.
– A JavaScript error from a plugin (often the payment gateway itself, or another plugin clashing with it). Quickest way to catch it: open the checkout page when the button is missing, press F12, open the Console tab, and look for any errors in red — they point straight to the script causing it.
– A plugin/theme conflict. The standard WooCommerce test is to deactivate every plugin except WooCommerce and your payment gateway, confirm the button stays put, then reactivate them one at a time until it breaks — ideally on a staging copy so the live shop isn’t disrupted.

To help me narrow it down, could you let me know:
– Which payment gateway(s) you use (Mollie, Stripe, iDEAL, etc.)?
– Whether any caching/optimisation plugin is active?
– And paste the exact CSS you added, so I can confirm it isn’t causing any harm in the meantime.

If you’d rather, I can take a look directly with the admin login from your first message and check the console and plugin side myself.

2) The site being slow

Slowness almost always comes down to one of two things — the server taking too long to respond, or too much weight loading in the browser — and the fixes are quite different, so the first step is to measure rather than guess. Could you run the site through one of these and share the result?

– https://pagespeed.web.dev
– https://gtmetrix.com

The figure to look at is the server response time (TTFB). If it’s high, it’s a hosting/backend matter — worth checking you’re on PHP 8.1 or newer under Tools → Site Health. If the server response is fine but pages are still slow, it’s front-end: usually large unoptimised images and render-blocking scripts.

For a WooCommerce shop the highest-impact improvements are normally:
– A proper caching plugin — but set to exclude cart/checkout/my-account from the cache and from JS combine/defer. (That’s the same setting that protects your checkout button, so the two issues are linked.)
– Image optimisation and lazy loading.
– PHP 8.1 or newer.
– Removing any unused plugins.

Send me the PageSpeed or GTmetrix output and I’ll tell you which of these will give the biggest win first, in priority order — and I can apply the safe ones for you if you’d like.

Apologies for any back-and-forth, and thanks for your patience. Send those details over and I’ll get this sorted.

Thanks,
Serkan