Viewing 30 posts - 1 through 30 (of 69 total)
  • Author
  • #946720

    Hello Enfold team,

    Host environment uses PHP Version 5.6 and finding different outcomes – where one Enfold update was successful and the other is getting a 502 Bad Gateway after upgrading from 4.2.6 up to 4.3 with ALL plugins disabled.

    Looking for direction and solution please.
    Details in private content


    I’m interested in the outcome of this so I’m subscribing to this thread.

    We’re in testing stages of upgrading to Enfold 4.3 and immediately after uploading the new theme into our staging environment 502 errors occur. They don’t occur if I remove our child theme, but that breaks everything. All previous upgrades our theme update went through without breaking errors.



    Thank you for using Enfold.

    One of these steps should take care of the issue.

    1. Deactivate all plugins.

    2. Update the PHP version being used by your hosting server to PHP 7 by getting in touch with your hosting company.

    Access your site with FTP or log in to your control panel and access the site via File Manager and perform the below steps:

    3. Replace the header.php file in wp-content/themes/enfold folder with an updated version of the header.php file.

    4. Access your WordPress site root folder and rename the current .htaccess file to .htaccess.bak. Login to WordPress admin area go to settings > permalinks > select “Post name” and save changes.

    5. Define a higher memory limit in WordPress and if possible increasing the memory on the hosting server.

    To increase the WordPress memory limit please access wp-config.php file and add the below line

    define('WP_MEMORY_LIMIT', '256M');

    More info here:

    Or contact your service provider to increase the memory limit.

    Let us know if none of the above works.

    Best Regards,


    I’m posting an update for the benefit of those waiting to hear how this turns out…
    I’ve tried the following and NONE made any difference – still 502 errors on 3 of our installs. The rest are doing well.
    1) Disabled plugins
    3) Replaced header.php
    4) Renamed .htaccess and updated permalinks
    5) Defined higher memory limit

    RE: #2 – I’m running a PHP Compatibility Plugin to test how all our plugins would do if we moved all of our 18 installs to a PHPv7server. I’ll let you know how that turns out next. Lots of time spent on this….


    Hi welswebmaster,

    Thank you, let us know how the rest worked out.

    Best regards,


    An update…
    All 5 steps you’ve recommended above were taken and still I get a 502. My guess is that something in my functions.php Child Theme is causing the issue. I’ve reverted to state prior to pressing the Theme Update button. Credentials and test site URL are in private content.

    **** IMPORTANT **** I have only a limited time to use this PHP 7 Install. So your expedient response is appreciated. I’m on borrowed time ;-)


    Another note. I tried the update again using only the parent theme (with child theme deactivated to eliminate possible functions.php issues) and still resulted in 502 after successful upgrade.
    Additionally, I tried a manual update SFTPing Enfold parent theme files. Same results. Tried activating JUST parent theme (same result of 502) and then also the child theme (same result).
    I’m out of ideas!

    • This reply was modified 9 months, 2 weeks ago by  welswebmaster. Reason: Additional info

    Hi welswebmaster,

    Here are some more things to look for: (Purchase code hidden if logged out)(Purchase code hidden if logged out)

    What is your hosting provider and what is the server?

    If you need further assistance please let us know.
    Best regards,


    Hi Victoria,
    YES, I NEED HELP. I’ve spent about a week on this 40+ hours.
    Here are answers to your questions.
    1. WP Engine.
    2. See private data sent to you in my earlier response.
    Other WP Engine platform settings:

    Log errors: (hosted on WPengine)

    • This reply was modified 9 months, 2 weeks ago by  welswebmaster.

    Hi welswebmaster,

    The test website is working. There was a closing php descriptor at the end of the child theme functions.php.

    Please check the website.

    Best regards,


    Victoria – Not looking good on the PHP7 I just updated to 4.3.2 and got the error “502
    The page request was canceled because it took too long to complete”. I’ve reverted. Credentials ABOVE should you like to try.

    I’ve tried the update again on our staging site with PHP 5.6 without success. (see private)

    No closing php descriptor present on the child theme functions.php

    I’m still experiencing a 502 issue when Enfold is updates and activated that needs to be resolved. The only way out is to rename the Enfold folders via sftp and switch to a different theme. CREDENTIALS BELOW. Please help.

    • This reply was modified 9 months, 2 weeks ago by  welswebmaster. Reason: added 4.3.2 version

    Hi welswebmaster,

    We too are experiencing what appears to be the same behavior and we are also on wpengine. We have spent a lot of time on this as well and wpengine support cannot provide any logs outside of what we can see in the portal. What we have discovered that we can make the site render somewhat if we:
    -Upload the new enfold theme as enfold-new
    -Rename enfold to enfold-old
    -Rename enfold-new to enfold
    -Go into our enfold-child/ directory and rename style.css to style.css.bad

    Only renaming the child style.css seems to allow the site to render. This obviously breaks all visual styling. Would you be willing to try this on your staging environment and report back it?

    If your install behaves the same as ours, then I’m leaning towards the built-in CSS compression being the issue. It is enabled by default. I’ve attempted to modify register-admin-options.php and setting what I think is the default to none by:

    line 95 “std” => “avia”, changed to “std” => “none”,
    line 112 “std” => “avia”, changed to “std” => “none”,
    line 145 “std” => “auto”, changed to “std” => “load_all”,

    But that did not work.. I’m going to revisit this theory tomorrow when I have some time.

    If the above rename test doesn’t behave the same as ours, I apologize and won’t hijack your thread any further :),



    MBARI-WP Thanks. I’ll give that a try today on a copy of the site and report back here. Stay tuned.


    MBARI-WP I followed your steps which result in the blank white screen. Its an Enfold related issue obviously. I have 20+ installs. 3 of them won’t upgrade. They are the 3 largest installs.


    Enfold team, I really need some direction on what to try next. Sounds like MBARI-WP could benefit as well.

    I’m able to get the frontend to display of my test site when I delete the child theme, but not the backend admin dashboard which causes 502 errors.

    • This reply was modified 9 months, 1 week ago by  welswebmaster.


    The template-builder.php and the helper-main-menu.php file is inside the child theme. Did you update those files after the upgrade?

    Best regards,


    No I did not. What is required of me to make a change on those two files?

    Also – I learned last night that for WP Engine sites using Enfold (if large sites – that explains the 3 remaining sites I have that won’t upgrade nicely) that WP Engine needs to…

    / WP Engine – Danh Nguyen
    After disabling then re-enabling the kill script on the server, the theme is no longer producing the 502 error (at least for activating and updating it).

    I’m about to test the above out on the production site but would like to know more about what you are saying about the template-builder.php and the helper-main-menu.php file is inside the child theme.



    There are a few code changes on those files in the latest version(4.3.2) so you have to update them too. Get new copies of the files from the latest version and replace the ones in the child theme. Or disable theme temporarily just to make sure that they’re not the cause of the issue.

    Best regards,


    Still suffering through this upgrade. WP Engine disables the kill script for our main (and largest) site and when pressing the theme update button, the site resources churn and drag to a halt causing 502 error again. They suggest me trying this yet again in the middle of the night. I did notice that the Google Map API was one process hanging. I’m considering to remove the key prior to update. I’ll try anything at this point. Many many hours without light at the end of the tunnel. Your input would be appreciated.


    Logs attached.


    Hi welswebmaster and kriesi,

    I don’t have good news. It appears the new version of enfold and wpengine are somewhat incompatible. After working multiple times with support one tech has informed me:

    Alex G10:49 am \The core files are in place. I didn’t see anything out of the ordinary within your configuration files. I confirmed that the 502s are triggered by the apache kill script. Unfortunately our logs don’t indicate the exact process on the page that is taking too long to execute. And we wouldn’t be able to remove the kill script since it is in place to protect the health of the server.

    10:51 am Beyond that I can try increasing the PHP memory limit settings.

    The PHP memory increase and setting php max_input_vars to 4000 (max wpengine allows) did nothing. So wpengines kill script (as welswebmaster mentioned above) does not like something about the new enfold, and barring doing some low-level query analysis and/or PHP debugging we can’t say what it is. I can’t devote the time to that, and will most likely have to switch from WPEngine to another provider/selfhost because of this.

    They ended with this:
    Alex G11:04 am Dang okay. Not sure what else we can do from our end at least. You would have to reach out to the theme developer to see what could be causing this.


    I’m getting further with WP Engine / Michael …. I plan to try out his suggestion early AM tomorrow.

    Michael G (WP Engine Level 2 Support)
    May 21, 9:02 AM CDT

    Thanks for the clarification. After further review, this looks like this may be tied to object caching. I found a couple of conflicts known to cause timeouts (502) while investigating the site.

    The first is the Autoloaded data within the database. Generally, you want this below 800K bytes, and really the lower the better. Your site wels is currently using 868,445 which is 68,445. This is known to cause time outs as Object cache is retrieve, or new items are entered into it. This is the current Autoloaded data:
    295323 ws_menu_editor_pro
    112152 wp_installer_settings
    64376 widget_enhancedtextwidget
    63770 rewrite_rules
    28200 _ubermenu_menu_item_styles
    21742 bwp_minify_detector_log
    19252 wp_user_roles
    14406 cron
    13618 monsterinsights_report_data_overview
    12726 wp-mega-menu-settings
    12328 avia_options_enfold_child
    12236 wysija
    11867 wpcf-custom-types
    10204 wp-mega-menu-styles
    8800 teccc_options
    8105 avia_options_enfold
    7057 theme_mods_enfold-child
    6723 sidebars_widgets
    6695 wpseo_titles
    6209 otgs_active_components
    The second conflict I was able to find was with the plugin the-events-calendar. This plugin uses the function wp_cache_add_non_persistent_groups, which is also known to conflict with object caching. What I’d like to try on wels is toggling off object caching, then have you processes the update once again to see if it completes. If it does, we can leave it disabled to give you some time to optimize the database. This article talks more about database operations:
    If that sounds good to you, definitely let us know, and I can get that disabled for you!
    NOTE to MBari-WP – I reached out to conlin last week via email without response.


    Sorry for my ignorance but who is conlin?


    WP Engine Julio D responded to your engineer’s suggestion MBARI-WP after checking my site’s log’s for the same kill script issue….

    Julio D (WP Engine Support)
    May 21, 2:43 PM CDT

    Thanks for the update. I checked the logs for anything being killed by the long process kills script. I’m seeing a few
    /wp-json/posts?type= requests being killed there. Nothing directly with Enfold from the look of it though. I don’t believe the kill script is causing a problem in this case. We could test this by disabling this function on your server. I would first want to test disabling Object cache first since turning off the kill script can cause other problems with the server load. We’d want to monitor the site when the script is off incase we need to enable it again quickly.

    Let us know when it would be ok to disable Object Cache and we’ll start there.


    Ahh, Doug! Our department supervisor is actually, and I’m the primary working on this Doug may have not seen your email or it could have been caught in spam.

    Interesting results with your kill script. Our support engineer said they couldn’t see the requests that were getting killed. I’m interested in the results of your upcoming tests.



    is actually a little but of killer when it comes to such compatibility.
    We will have to dig faster, I have some support tickets with a lvl3 engineer my self.

    Best regards,


    Thanks Basilis for moving forward on our behalf. Just an FYI – that the last WP Engine suggestion to turn off Object Cache prior to the theme update had the same FAIL results. So cross that one off the list too.

    Awaiting your solution!


    Hi all, we’re experiencing same issues as welswebmaster. WPEngine, PHP 7, large site, 502 errors, heavy autoload, same results with or without object caching or parent/child theme. We do not experience these issues with Enfold 4.2.6. We have not found a solution for 4.3.x versions.

    This client is a high value eCommerce site, very eagerly anticipating new options/suggestions for resolution.

    Thanks in advance Basilis and Kriesi crew!


    Enfold team – Basilis
    NOTE: With WP Engine’s info below, Brasilis perhaps you have more info on the TXT file they provided the link for?

    Here’s what WP Engine found last night (now a Level 3 support)

    WP Engine / Level 2 / Matthew C / Yesterday at 16:20

    I’ve been reading over the ticket notes and testing on my end. I think it would be best if we escalate this issue to one of our higher level support techs.

    I have gone through and summarized all of the notes here for them regarding where and when we can test on the site, and things we have already tried to give them a starting point.

    Please let us know if you receive any more information. We will be in contact with you when we have more on our end!

    WP Engine / Level 3 / Brian F / Yesterday at 21:25

    Thanks for your patience as we took a deeper look into this.
    I believe we’ve made some progress and I have some additional information to share with you. Firstly I believe the underlying cause of the problem is related to an interaction between the database, and the enfold theme.

    One other thing I noticed is that when running several wp-cli commands from the staging area, a number of errors were returned which can be seen in this .txt file:
    Although I don’t know for sure if these errors are related to the problem, I think that your development team would definitely want to be aware considering there is a fatal error related to the theme near the bottom of the list.

    Another thing I found was that after I purged the transients out of the wels staging site database, I was able to successfully activate the enfold child theme without issues, so doing the same thing on the live database might help, please let us know if we have your permission to test that.

    If it does turn out that purging the transients resolves this issue, it could suggest that the enfold theme or the associated child theme could have problems related to transients that should be looked into to avoid similar issues down the road. Please let us know what you think.

    —– end

    With that said, Brasilis perhaps you have more info on the TXT file they provided the link for?

Viewing 30 posts - 1 through 30 (of 69 total)

You must be logged in to reply to this topic.