We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 19153
    • 53 Posts
    Hi guys

    Designer here who is not particularly technical but having big issues with my modx websites and client sites on a bluehost server. Please help!

    Only thing i can think is this might be because last year i upgraded php in cpanel - due to a new modx site requiring it when i tried to install - either that or a hack?

    First issue i noticed was that i couldn't login to any of my more recent modx sites (most were updated to latest version of modx in october/november.)

    I got into the databases of a couple and tried to change password but still locked out of all of them.

    Second issue i have noticed is that while the sites are still live, any of them that have getresources calls are not showing the data now even though i've not logged into them for at least a month - for example a blog page is showing no posts.

    Latest update - i manually deleted the cache folder on one site - now that site throws a 500 error...

    Warning: strftime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home2/../public_html/../core/model/modx/modx.class.php on line 2519


    Not sure why this has appeared?

    Any thoughts?

    This question has been answered by fretless. See the first response.

    • There needs to be a timezone setting in php.ini
      https://my.bluehost.com/cgi/help/515
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
        • 19153
        • 53 Posts
        Thanks Susan for your input smiley

        Turns out it was the upgraded php causing the problem... - it was set to php 5.6, reverting back to 5.4 has solved all issues.

        Hope this helps anybody else!

        • Unfortunately that just puts off the proper solution to the issue, which is correcting the problem simply by setting a default date/timezone in your php.ini file.

          For example on my localhost MAMP installation using PHP 5.6.10
          date.timezone = "Asia/Jerusalem"
          
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
          • discuss.answer
            • 10169
            • 24 Posts
            Attention all Bluehost users:

            Since early January, Bluehost has been rolling out a configuration change to all of their shared hosting accounts. They are automatically setting the PHP handler in /public_html/.htaccess to a beta build of PHP 5.6 that does not include PDO and is missing a default timezone setting, among other shortcomings. This breaks the MODX database connectivity and renders the site useless beyond displaying previously cached content.

            To fix this issue, I recommend going into cPanel and setting your PHP version to 5.4 with FastCGI. This will safely change the setting in your .htaccess file.

            Two of my clients running MODX sites recently experienced this issue and it took waiting in a chat queue for 40 minutes to get some answers. Apparently Bluehost does not feel that it is necessary to email account holders and warn them about pending configuration changes.
              • 36816
              • 109 Posts
              Quote from: fretless at Jan 20, 2016, 09:25 PM
              Attention all Bluehost users:

              They are automatically setting the PHP handler in /public_html/.htaccess to a beta build of PHP 5.6 that does not include PDO and is missing a default timezone setting

              It looks like they may have fixed those problems. Over the last 10 days, I've spot-checked a number of Bluehost clients (and my own BH account, for that matter). Each of those that have been auto-upgraded does have PDO compiled in, and the default timezone set. I've not encountered any down sites.

              For what it's worth, the PHP 5.6 they're using (5.6.17), isn't beta, it's a recent (Jan 7, 2016) security release (see http://php.net/archive/2016.php). I really don't know why Bluehost is labeling it as beta.

              Also for what it's worth, PHP 5.4 (and older) is no longer a developed/supported branch of PHP, no matter who hosts it (http://php.net/eol.php). Only the 5.5, 5.6 and 7.x branches are currently receiving updates, including security updates, and 5.5 will not receive security updates after July of this year (http://php.net/supported-versions.php). I really don't blame Bluehost for wanting to clear out versions of PHP older than their end-of-life if they can. [ed. note: clareoconsulting last edited this post 8 years, 2 months ago.]
                • 3749
                • 24,544 Posts
                Good info -- thanks for posting that. Still, a quick email informing us all of the auto-upgrade would have been helpful, as would a follow-up email saying that they were fixing the problems that may have broken our sites.
                  Did I help you? Buy me a beer
                  Get my Book: MODX:The Official Guide
                  MODX info for everyone: http://bobsguides.com/modx.html
                  My MODX Extras
                  Bob's Guides is now hosted at A2 MODX Hosting
                  • 36816
                  • 109 Posts
                  Quote from: BobRay at Jan 21, 2016, 04:29 AM
                  a quick email informing us all of the auto-upgrade would have been helpful

                  We're completely on the same page there. BH's support techs would probably have appreciated it if that had been sent pre-upgrade too. It's puzzling why they didn't; they do send pre-upgrade announcements when they're updating the servers themselves. In my opinion, someone in this case made a bad decision to not pre-announce. Hopefully they do it differently the next time.
                    • 46886
                    • 1,154 Posts
                    Define processes, identify breakdowns, revise processes, rinse and repeat!
                      • 36816
                      • 109 Posts
                      Quote from: fretless at Jan 20, 2016, 09:25 PM
                      PHP 5.6 that does not include PDO

                      In addition to Bluehost learning from problems, here's another possibility that could be site-specific:

                      Possible problem: non-matching versions of php binary and php.ini

                      In a bit of serendipity, I found something that may shed some light on PDO not being loaded for some. First off, this applies in cases where the "single php.ini" PHP configuration is selected in cPanel, in which the php.ini in public_html is the one and only. In the case where Bluehost changed the public_html .htaccess to use PHP 5.6, it also places a new PHP 5.6-compatible php.ini file in public_html.

                      That's all good unless another .htaccess (i.e. one in a subdirectory/subfolder) happens to override the PHP selection using the old PHP (single php-ini version). What happens then is that in that subdirectory, the old PHP is loaded, and it tries to use the incompatible new php.ini in public_html. If you're seeing php error_log lines like those at the bottom of this post, this could be the problem.

                      In the case that I ran into, here's some background. PHP 5.6 being loaded in public_html along with public_html/php.ini, and PHP 5.4 being loaded in a subdirectory with the wrong php.ini (the 5.6 version - public_html/php.ini). As to how it happened, I'd been working on a "staging" copy of a site in a subdirectory, having copied everything from public_html, including the .htaccess - before the auto-upgrade. The auto-upgrade of php didn't change the .htaccess in the subdirectory when it changed the one in public_html, and whammo - running PHP 5.4 with the 5.6 php.ini:

                      Relevant lines in public_html/.htaccess
                      # Changed PHP handler from application/x-httpd-php54s to application/x-httpd-phpbetas on Mon Jan 11 09:54:38 MST 2016.
                      AddHandler application/x-httpd-phpbetas .php


                      Relevant lines in public_html/mysubdirectory/.htaccess
                      # Use PHP54 Single php.ini as default
                      AddHandler application/x-httpd-php54s .php


                      a sample of the php error_log entries when the old PHP tries to use the new php.ini:
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: imagick: Unable to initialize module
                      Module compiled with module API=20131226
                      PHP    compiled with module API=20100525
                      These options need to match
                       in Unknown on line 0
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/56/usr/lib64/php/modules/pdo_mysql.so' - /usr/php/56/usr/lib64/php/modules/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: imagick: Unable to initialize module
                      Module compiled with module API=20131226
                      PHP    compiled with module API=20100525
                      These options need to match
                       in Unknown on line 0
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: pdo_sqlite: Unable to initialize module
                      Module compiled with module API=20131226
                      PHP    compiled with module API=20100525
                      These options need to match
                       in Unknown on line 0
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/56/usr/lib64/php/modules/pdo_mysql.so' - /usr/php/56/usr/lib64/php/modules/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: pdo_sqlite: Unable to initialize module
                      Module compiled with module API=20131226
                      PHP    compiled with module API=20100525
                      These options need to match
                       in Unknown on line 0
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/56/usr/lib64/php/modules/pdo_pgsql.so' - /usr/php/56/usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_handle_error in Unknown on line 0
                      [21-Jan-2016 09:51:12 America/Denver] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/56/usr/lib64/php/modules/pdo_pgsql.so' - /usr/php/56/usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_handle_error in Unknown on line 0