Forum Replies Created

Viewing 15 replies - 1 through 15 (of 20 total)
  • Thread Starter oshika35

    (@oshika35)

    Update :

    I’ve been able to solve the issue after removing the auto_preprend line from a file called alt_php74.cfg

    After that, PHP 7.4 loaded successfully, everything works again.

    However after enabling WordPress again I’m asked to do the firewall optimization that consists in adding this exact line that makes my website crash.

    Any way I can solve that?

    Edit : It was my mistake, I copied the whole line instead of just the path in the UI for PHP options.

    Everything works now. sorry.

    • This reply was modified 2 years, 7 months ago by oshika35.
    Thread Starter oshika35

    (@oshika35)

    Thank you for your answer, it works now after enabling the REST API again ?? !

    Thread Starter oshika35

    (@oshika35)

    Hello @niklasinpsyde

    I was using 7.0.1 and I just updated to 7.0.2. After that, the problem seems to be gone.

    If this can help you, find the log below:

    An error of type E_ERROR was caused at the line 48 of the file /home/private/website.com/wp-content/plugins/mollie-payments-for-woocommerce/src/SDK/Api.php. Error message: Uncaught TypeError: preg_match() expects parameter 2 to be string, bool given in /home/private/website.com/wp-content/plugins/mollie-payments-for-woocommerce/src/SDK/Api.php:48
    Stack trace:
    #0 /home/private/website.com/wp-content/plugins/mollie-payments-for-woocommerce/src/SDK/Api.php(48): preg_match('#^(live|test)_\\...', true)
    #1 /home/private/website.com/wp-content/plugins/mollie-payments-for-woocommerce/src/Payment/PaymentModule.php(406): Mollie\WooCommerce\SDK\Api->getApiClient(true)
    #2 /home/private/website.com/wp-includes/class-wp-hook.php(309): Mollie\WooCommerce\Payment\PaymentModule->cancelOrderAtMollie(980)
    #3 /home/private/website.com/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array)
    #4 /home/private/website.com/wp-includes/plugin.php(474): WP_Hook->do_action(Array)
    #5 /home/private/website.com/wp-content/plugins/woocommerce/includes/class-wc-order.php(364): do_action('woocommerce_ord...', 980, Object(Automattic\WooCommerce\Admin\Overrides\O

    (Some parts were in my langage, I translated them in English)

    You can mark the thread as resolved.

    Best regards,
    Oshika

    Thread Starter oshika35

    (@oshika35)

    Update :

    Sorry for the thread, I misunderstood what was going on. The problem seems to be caused by Mollie, I’ll contact their support.

    Best regards,
    Oshika

    Thread Starter oshika35

    (@oshika35)

    Merci pour votre suivi

    Thread Starter oshika35

    (@oshika35)

    Thanks!

    Unfortunately after testing it a bit more, yes I’m sure I can’t. The widgets are not loaded in the editor. But at this point I’ll contact the plugin’s author

    oshika35

    (@oshika35)

    Hello,

    I’ll post an update here, thanks to help of @giuse I was able to solve the issue.
    The culprit was the plugin OXYULTIMATE WOO.

    Solution :

    -> Downloading https://www.ads-software.com/plugins/editor-cleanup-for-oxygen/
    -> Going to the settings of the plugin in the Editor Loading Cleanup
    -> Disabling OXYULTIMATE WOO

    Thread Starter oshika35

    (@oshika35)

    Thanks a lot for your detailed answer!

    I was finally able to find the culprit! After following your recommandations. I disabled all the plugins and then searched the one causing the issue, it was OXYULTIMATE WOO in the Editor Loading Cleanup.

    Well now, I can’t really disable it, because it’s providing e-commerce widgets and disabling it would cause issues in the editor. But at least now I can contact the plugin author and let him know about this conflict.

    I’m quite new on wordpress forum so I wonder if I should post a reply in the original thread too?

    Thread Starter oshika35

    (@oshika35)

    Hello @giuse

    Thank you for your answer,

    Unfortunately I already tried all of that, I’m using litespeed so I totally disabled litespeed and cleared the cache. I also logged into cPanel and disabled LiteSpeed LsCache there too. I don’t use a CDN so nothing to try there too. I cleared my browser’s cache too to see if it could help.

    This issue is quite frustrating, the only thing that works is disabling Complianz.

    I’ll continue to investigate and report here if I can find the solution, if I’m unable to solve it I’ll mark the thread as resolved.

    oshika35

    (@oshika35)

    Hello @giuse

    Thank you for your answer ?? !

    I just installed your plugin and disabled Complianz in the inner/outer editor as well as during the loading but it didn’t solve the issue. I’ll open a thread on your plugin support forum.

    oshika35

    (@oshika35)

    Hello,

    Sorry to bump this topic, actually I was never able to get rid of the error message even with the workaround.
    This is really weird, I tried to disable it with many different URLs but it never worked.
    I tried both Front-end/back-end urls, I tried with *ct_builder*, but also with */ct_builder*, I even tried the full link but the error is always there.
    I’m also using Freesoul Deactivate Plugins for another plugin that executes somewhere it shouldn’t and it is working perfecty there.

    It seems it’s not disabling Complianz properly since the opt-in message is still in the console while in Oxygen page builder (as well as the error messages mentionned previously in this topic)

    Thread Starter oshika35

    (@oshika35)

    Thank you for your answer, as I prefer not sharing the log publicly, I’ll open a ticket with your support, or probably use the premium support as I’m running out of time.

    Thanks a lot for the support your provided.

    Thread Starter oshika35

    (@oshika35)

    Hello,

    Thank you for your answer, unfortunately, I already checked this page before posting.
    I have some questions about it that I forget to ask in my original post.

    At first I thought this was the reason:

    The plugin can only perform WebP replacement on the HTML tag. If the image is loaded via CSS, JS, or some other means, LSCache may not be able to correctly insert the WebP file.

    But then why would the homepage background images successfully return the webp versions?

    I also checked the ‘Some WebP Load, Some do Not’ part, but all the images were prefaced with the correct site address.

    Finally, I used the debug log in advanced mode to see what was going on. I’ll try to sum up my findings, please note I’m always talking about the grid builder images.

    In the homepage, everything works, the images are displayed as .webp both in the source dev tool menu and in the slug (.jpg.webp).
    In the /catalog/ page, the images are displayed as .webp only in the source dev tool menu. The slug only ends with .jpg.
    Finally, in another page related to a category, they are not displayed as .webp both in the source dev tool menu and in the slug.

    However, for all those pages (including the last one) the log says it replaced successfully the image with a webp version.

    Any ideas of what is happening ?

    Best regards,

    Thread Starter oshika35

    (@oshika35)

    Aux futurs lecteurs cherchant un workaround :

    Il faudra installer ce plugin puis se rendre dans la page backend -> backend singles

    Trouver la page où Colissimo s’exécute et rentre en conflit avec la page du plugin tiers, puis tout simplement décocher et sauvegarder la configuration.

    oshika35

    (@oshika35)

    Hello Aert,

    Sorry for the late answer, I didn’t get the email notification for your message.

    I’ll use the workaround you provided,

    Thanks a lot for your support,

    I wish you a good day

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