The site is experiencing technical difficulties

A support ticket was opened yesterday regarding production and staging showing the message “The site is experiencing technical difficulties.” – yesterday it was doing this just for the admin console, but now I am seeing this on the staging public website

Im worried that this will soon appear for live production website.

  • Kris
    • Support

    Hi Richard Hill

    Hope you are doing good today.

    I escalate this issue to our SLS Team so they could take closer look on this. We will post an update here as soon as more information is available.

    Please keep in mind that our SLS Team deals with more complicated issues, so it may take a little longer for them to reply here. Thank you for your patience while we look into this further.

    Kind Regards,

    Kris

  • Panos
    • SLS

    Hey Richard Hill !

    It seems that the number of assets is almost 6000 this is why it’s timing out when Asset Optimization is active. In the following days we will have some input from he main dev too. For the time being I have deactivated Asset Optimization so you can continue working on the staging site until we have an update from the main dev.

    Kind regards!

  • Richard Hill
    • Recruit

    Hi Panos

    Im very confused as to why there are 6000 assets… This is really odd because our website is very new and very small (in its current form). So I really dont understand why there would be so many assets. Can you shed some more light on this particular issue? If possible please send me a list of all the assets the website is using in a CSV or something so I can review.

    Thanks

  • Panos
    • SLS

    This is indeed odd. Actually that is not the assets number, but a number of posts that gets created for each asset. I am positive that I can delete those and run the Re-check files again but I am still waiting for instructions from main dev.

    In the mean time I have added this mu-plugin on your staging site:

    https://gist.github.com/wpmudev-sls/772a253d066a9b36bdab7c99aa0cfe31

    so you can view the list of those posts in this page :

    https://yoursite.staging.wpmudev.host/wp-admin/admin.php?page=mphb-minify-group-posts

    Will keep you updated once I have a response.

    Kind regards!

  • Richard Hill
    • Recruit

    Hi Panos,

    Im guessing your team is working on the issue currently because I just took a look at the “Minify Group Posts” tool and there seems to be only 35 entries, so not sure if this is an issue any more?

    Do you know if there is an ETA for fixing this issue? Reason being is I need to do work on the site and this is blocking me and my team (i.e. we cant install/uninstall plugins, etc).

    Thanks in advance

  • Panos
    • SLS

    Sorry for taking so long! Deleting those seemed to work however for some reason it doesn’t find any assets. We’re looking into that. You can do any work on the site in the meantime and we’ll keep you updated once we get this sorted out.

    Kind regards!

  • Panos
    • SLS

    So it seems to be fine now :slight_smile:

    All needed was to delete those posts and re check files. As for that assets not showing up, it was related to scanning some page(s) that would return some error, but that is something that can be bypassed by simply visiting a page.

    We can do the same on your live site if you are OK with that. We specifically want to delete those posts, clear cache and recheck files. We can do that as soon as you confirm it’s OK with you :slight_smile:

    Kind regards!

  • Richard Hill
    • Recruit

    Hello Again,

    I just updated staging from live (because Hummingbird was working). I made a few changes and successfully applied. But I just started seeing this issue again:

    “The site is experiencing technical difficulties. Please check your site admin email inbox for instructions.”

    So something is broken it appears. If you can take a look that would be much appreciated…

    Regards

  • Panos
    • SLS

    Just noticed something was different, did you also restore the live site from a backup? One mu-plugin I was using to delete those minify_group posts was gone. It’s a bug number so it takes time for them to be deleted. I’m starting over on both sites, production and staging but it will take a while. I’ll update you once done and will have a look at the issue you mentioned moving that file to the footer too.

    BTW – do we know what the root cause of these issues was? Or is it a case of if this happens again let you know?

    That’s really strange, if I remember correctly something similar had been reported in the past once. It was related to a security plugin conflict and there was a specific option that was causing this.

    Will keep you updated once done deleting those.

    Kind regards!

  • Panos
    • SLS

    Hi Richard Hill !

    It seems that the issue where you were not able to position the avada-stylesheet 169.7KB — style.min.css asset to the footer was related to the same large number of those posts. Once those were deleted I could position that asset to the footer without any issues.

    Could you do a few tests and let us know hoe it goes?

    Kind regards!

  • Richard Hill
    • Recruit

    Hi Panos,

    I ran a few tests and it seems… to be ok. I cant say for sure because last time things went wrong was when I was making lots of tweaks to “asset optmisation” – I have completed this process now, and TBH I dont want to mess with it because it can (and has) caused all sorts of visual corruption on the website.

    I did experiment a little with Hummingbird and I received no crashes (whereas before it was crashing when I even tried to open the tool). So I think… this issue has been resolved now.

    Thank you and everyone who looked into this issue, the support has been A++ as per usual.

  • Panos
    • SLS

    Hi again Richard Hill ,

    We’ve still been looking into this. What we found is that there are specific files repeatedly increasing in the db. Those use different hashes each time so they get included again and again on each page visit.

    Let me try explain why this happens. Hummingbird tries to check js/css files and will also re-scan them if there is any change on the hash of the enqueued asset:
    themes/Avada/md/md-config.js?1568813788
    the 1568813788 is changed on each visit, so Hummingbird sees that and “supposes” that it has changed and so it includes it again.

    This happens in the theme’s functions.php at the very end of the file. Specifically this part:

    
    function md_ajax_init() {
    	wp_enqueue_style('loading', get_bloginfo('template_directory') . '/md/loading.css');
    	wp_enqueue_style('loading_btn', get_bloginfo('template_directory') . '/md/loading-btn.css');
    	wp_enqueue_style('md_styles', get_bloginfo('template_directory') . '/md/styles.css?'.time());
    	wp_register_script( 'blowfish', get_bloginfo('template_directory') . '/md/blowfish.js');
    	wp_enqueue_script( 'blowfish' );
    	wp_enqueue_script( 'js-cookie',  "https://cdn.jsdelivr.net/npm/js-cookie@2/src/js.cookie.min.js");
    	wp_enqueue_script( 'md-config', get_bloginfo('template_directory') . '/md/md-config.js?'.time() );
    	wp_enqueue_script( 'md-ajax', get_bloginfo('template_directory') . '/md/md-requests.js?'.time(), array( 'jquery', 'blowfish' ), time() );
    }
     
    add_action('init', 'md_ajax_init');
    

    There are some enqueues that use time() as hash. Is there a specific reason that his is required? If it is not that important to use the time(), you can use some version number instead so we can avoid ending up with so many records in db.

    Let us know what you think :slight_smile:

    Kind regards!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.