Forum Replies Created

Viewing 15 replies - 1 through 15 (of 17 total)
  • It’s the new Woocommerce block checkout. It works perfectly on the old checkout but the block checkout hides all of the payment gateways, and the non-Pro version of the plugin has been updated to support it but the Pro version (inexplicably) still doesn’t have that support. I really hope that the developer will update the Pro version because I’ve never seen anyone keep their premium customers waiting like this before πŸ™

    Thread Starter baffled

    (@baffled)

    Thank you, understood!

    Thread Starter baffled

    (@baffled)

    Thank you and apologies for the delay in response. Our host only supports PHP 7.4 or 8.2 and our payment processor is blocking sites still using 7.4 in its next update, so unfortunately our hand has been forced. This isn’t a big deal as it doesn’t seem to have any ill effects; I just wanted to report the warning.

    I’ve figured out how to trigger it but can’t work out why it’s happening. If a site visitor goes to:

    /faqs/single-faq/FAQSLUGNAME/faq-category/FAQCATEGORYNAME/

    Where FAQSLUGNAME is a valid UFAQ slug and FAQCATEGORYNAME is its valid category, the error appears in the log multiple times. The displayed content is just our existing /faqs/ page (which is a curated Page full of 14x UFAQ category shortcodes which doesn’t trigger any error when visited normally via /faqs/). Significantly, the PHP warning appears 14x in the log at this moment, implying that it’s visiting /faqs/ via the /faqs/single-faq/FAQSLUGNAME/faq-category/FAQCATEGORYNAME/ referrer which is causing the problem.

    What I haven’t worked out is why anyone would ever visit an address in that format in the first place. Our FAQs are all organized with pretty permalinks under /ufaq/FAQSLUGNAME so /faqs/ shouldn’t be happening. Is this because we have pretty permalinks enabled? The link doesn’t exist anywhere in our site db content so I’m trying to work out where it’s being generated to allow people to reach it. If I can find a way of disabling this behavior then nothing needs fixing.

    Thread Starter baffled

    (@baffled)

    Yes, apologies – PHP 7.4 to 8.2. I can’t tell what action causes it as it seems to be intermittent, so I’ll keep an eye on it and update if I can narrow it down.

    Thread Starter baffled

    (@baffled)

    Thank you, perfect answer.

    Thread Starter baffled

    (@baffled)

    Thank you very much, here’s the report:

    https://quickforget.com/s/8186f7bc333d362eeed4dbb2b7758a09460770c5ded278cd

    It worked correctly until the date I mentioned which is the truly baffling part!

    Thread Starter baffled

    (@baffled)

    Thank you; I thought I’d fixed it by enabling the setting β€œHide shipping costs until an address is enteredβ€œ but today we had another order with the issue, so it may be that my ‘fix’ is only working by discouraging people to checkout blind and the behaviour is still incorrect. It didn’t do this until recently. It’s worked perfectly for years.

    DHL have asked me to revert to Woocommerce as it shouldn’t be possible to check out with no shipping line irrespective of what their API returns. We don’t need any of the other functionalities like label printing as DHL automatically import our orders, we just use the integration for shipping prices; would the other plugin still serve a purpose? I’m happy to install it if it will prevent people from checking out without a shipping line but that doesn’t seem to be its function. We don’t have any free shipping on offer so I don’t know why the checkout is allowing people to buy physical items without adding the shipping (intermittently – it’s working for most orders now).

    I’m having this issue too. Is it caching my old Twitter settings (even though I deleted the connection multiple times and cleared all of its settings)? I have gone through the API connection steps and tried functions.php for the extra code – nothing – and then I finally figured out what you meant by creating a site specific plugin (inserting just the extra code line into the custom plugin, right?) but that did nothing either even when the plugin was activated and running. There’s nowhere obvious to enter the API credentials we generated. Where are we supposed to see the options? Could it be that we’re just missing it? Can we add it directly to the database?

    Thank you for trying to keep up with Twitter’s nonsense, I feel very silly for being unable to finish the connection process at the very last step!

    Update: APOLOGIES, I just figured it out – didn’t notice the screencast link right at the end of the instructions post! I’m deaf so I don’t usually click videos anyway but I was only seeing one button when I tried to add a Twitter connection: “Sign in to Twitter”.

    Then I realized that the code I copied/pasted straight from the pinned post had ‘smart’ single quote marks, which was picked up when I edited functions.php (which didn’t work) but I didn’t remember to fix the quote marks when I edited my custom plugin. After doing that, finally, it’s working!

    • This reply was modified 2 years, 4 months ago by baffled. Reason: I'm dumb

    Thank you very much, this seems to prevent the issue.

    I’ll reply here instead of on https://wordpress.org/support/topic/9-6-update-destroys-my-website/ to keep everything in one place as the issues seem really similar.

    It looks like something went wrong during the plugin update, and some files were then missing from your installation of Jetpack.

    It may be worth trying to update again, either via the update button in your dashboard, or via FTP by deleting the whole wp-content/plugins/jetpack folder and replacing it by a fresh installation of Jetpack.

    Let me know how it goes.

    I have tried deleting the whole plugin folder then installing Jetpack 9.6 fresh. It lasted only until I was halfway through reconnecting Jetpack to my account and then the same thing happened – thousands of plugin settings and customizations wiped out. I do believe that an automated process is killing all of my settings minutes after I install each time so it’s plausible that the cron job identified in the thread is affecting me too. I have a WP logging plugin installed to try to drill down further into the sequence of events in case I was missing something but unfortunately when its settings wipe I can’t pull anything reasonable out of the history there.

    9.5 still working beautifully. Every time I try to install 9.6 my site explodes.

    Thread Starter baffled

    (@baffled)

    Just wanted to say ‘wow!’ – already fixed and working perfectly just a few hours after it was reported. Thanks πŸ™‚

    Thread Starter baffled

    (@baffled)

    Thank you! I’ll install new updates as they come out and look forward to seeing the option returning in future πŸ™‚

    Thread Starter baffled

    (@baffled)

    Thanks! That works perfectly, I didn’t realise they worked with search too. I’m a very happy user πŸ™‚

    baffled

    (@baffled)

    Thank you very much, I think the options are working now, it’s just a few things not working as I expected are confusing the issue πŸ™‚

    I’ll experiment as discussed in the other thread.

    Thread Starter baffled

    (@baffled)

    Excellent, thank you very much. I see there’s a new update to install which tweaks permalinks so I’ll get that loaded up and test your suggestions. The post_count tip is very good, it would be great if it was also on the FAQ page here πŸ™‚

Viewing 15 replies - 1 through 15 (of 17 total)