No posts in WordPress after server/php migration due to obsolete/broken plugin

The scenario is that you restore you files and database to a new host and then when you access the dashboard (as well as the front end) you see no posts. They are listed i.e. All (nnn) Published (x) Draft (y), but there are none displayed.

Equally, you upgraded the current server to a new version and this upgrades the php version.The site may work (with blank list of posts) or the site may break and the frontend or administration cannot be accessed.

We had this and for us it was a very stale plugin that should have deleted years ago (Psychic Search) !.

If this happens to you and you have back-end access to the administration interface then deactivate all plugins that are old until the site comes back correctly.

If the site is so broken that you do not have access to the administration interface then you can use FTP to go to wp-content/plugins and then go through the change date and from the oldest dated plugin, download it (to take a backup) and then delete the plugin. When WordPress tries to load the now-deleted plugin then it can’t and the plugin becomes deactivated. This should get you back into the site and you can then use the administration interface to either install a updated version of the broken/obsolete plugin or an equivalent that does have support for your host/php version.

vTiger with PHP 5.4 ( session_unregister function removed)

With PHP 5.4 onwards the session_unregister function is removed. This means that you will get a “Fatal error: Call to undefined function session_unregister()”

vTiger 5.4 (the version number is just happen stance and has no relation to the PHP version number) code needs the following cludge to get around this. In /modules/Users/Authenticate.php around about line 69 then do the following change,

//Security related entries end
// TODO: session_unregister was removed in php 5.4.0 so must remove this backwards compatibility switch.
if (function_exists('session_unregister')) {
    session_unregister('login_password');
    session_unregister('login_error');
    session_unregister('login_user_name');
} else {
    unset($_SESSION['login_password']);
    unset($_SESSION['login_error']);
    unset($_SESSION['login_user_name']);
}

Kohana 2.3 (used by blue.box) and PHP 5.4

If you are using Blue.box to configure your FreeSWITCH softswitch then blue.box uses Kohana 2.3 and this has a quirk with PHP 5.4 which means that you will end up with a blank page (even after a clean git pull) plus a spurious array to string conversion error.

For the BLANK screen issue then the fix is,

See https://gist.github.com/kemo/2881489 for a working fix. Note that that patch isn’t exactly lined up on the line numbers – my git diff is,

diff --git a/system/core/Kohana.php b/system/core/Kohana.php
index 56b44af..ee6c832 100644
--- a/system/core/Kohana.php
+++ b/system/core/Kohana.php
@@ -677,7 +677,7 @@ final class Kohana {
                if (ob_get_level() >= self::$buffer_level)
                {
                        // Set the close function
-                       $close = ($flush === TRUE) ? 'ob_end_flush' : 'ob_end_c
+$close = ($flush === TRUE) ? 'ob_end_flush' : 'Kohana::_ob_end_clean';

                        while (ob_get_level() > self::$buffer_level)
                        {
@@ -686,7 +686,7 @@ final class Kohana {
                        }

                        // This will flush the Kohana buffer, which sets self::
-                       ob_end_clean();
+Kohana::_ob_end_clean();

                        // Reset the buffer level
                        self::$buffer_level = ob_get_level();
@@ -1604,6 +1604,30 @@ final class Kohana {

                return $written;
        }
+ /**
+ * Ends the current output buffer with callback in mind
+ * PHP doesn't pass the output to the callback defined in ob_start() since 5.4
+ *
+ * @param callback $callback
+ * @return boolean
+ */
+ protected static function _ob_end_clean($callback = NULL)
+ {
+ // Pre-5.4 ob_end_clean() will pass the buffer to the callback anyways
+ if (version_compare(PHP_VERSION, '5.4', '<'))
+ return ob_end_clean();
+
+ $output = ob_get_contents();
+
+ if ($callback === NULL)
+ {
+ $callback = arr::get(ob_list_handlers(), ob_get_level() - 1);
+ }
+
+ return is_callable($callback)
+ ? ob_end_clean() AND call_user_func($callback, $output)
+ : ob_end_clean();
+ }

 } // End Kohana

For the array to string conversion error you see the sort of useful orange trace back Kohana error page and this,

An error was detected which prevented the loading of this page. If this problem persists, please contact the website administrator.

bluebox/libraries/doctrine/lib/Doctrine/Query/Abstract.php [1103]:

Array to string conversion

To fix this you need to do changes to Abstract.php and Lib.php which is basically making a new function arrayDiffSimple and then adding that new function to the Lib.php.

diff --git a/bluebox/libraries/doctrine/lib/Doctrine/Lib.php b/bluebox/libraries
index 26c796d..d6b5c94 100644
--- a/bluebox/libraries/doctrine/lib/Doctrine/Lib.php
+++ b/bluebox/libraries/doctrine/lib/Doctrine/Lib.php
@@ -268,6 +268,45 @@ class Doctrine_Lib
         }
     }

+
+    // Code from symfony sfToolkit class. See LICENSE
+    // code from cto at verylastroom dot com
+    /**
+     * arrayDiffSimple
+     *
+     * array arrayDiffSimple ( array array1 , array array2 )
+     *
+     * Like array_diff
+     *
+     * arrayDiffSimple() has exactly the same behavior than array_diff, but can
+     * only 2 arrays. PHP versions > 5.4.0 generate some NOTICE if you use arra
+     * sometimes because of array_diff internal behavior with (string) casts.
+     * This method solves the problem.
+     *
+     * @param array $array1
+     * @param array $array2
+     * @static
+     * @access public
+     * @return array
+     */
+    public static function arrayDiffSimple($array1, $array2)
+    {
+        $diff = array();
+
+        foreach($array1 as $key => $val) {
+            if(!isset($array2[$key])) {
+                $diff[$key] = $val;
+            } else {
+                if(is_array($array2[$key]) && !is_array($val)) {
+                    $diff[$key] = $val;
+                }
+            }
+        }
+
+        return $diff;
+    }
+
+
     /**
      * Makes the directories for a path recursively.
      *
diff --git a/bluebox/libraries/doctrine/lib/Doctrine/Query/Abstract.php b/bluebo
index 981603d..6bc2820 100644
--- a/bluebox/libraries/doctrine/lib/Doctrine/Query/Abstract.php
+++ b/bluebox/libraries/doctrine/lib/Doctrine/Query/Abstract.php
@@ -1098,9 +1098,9 @@ abstract class Doctrine_Query_Abstract
         $componentsAfter = $copy->getQueryComponents();

         $this->_rootAlias = $copy->getRootAlias();
-       
+
         if ($componentsBefore !== $componentsAfter) {
-            return array_diff($componentsAfter, $componentsBefore);
+               return Doctrine_Lib::arrayDiffSimple($componentsAfter, $componen
         } else {
             return $componentsAfter;
         }
@@ -2070,4 +2070,4 @@ abstract class Doctrine_Query_Abstract
     {
         return $this->getDql();
     }
-}
\ No newline at end of file
+}

vTiger 5.4.0 enable backup quirk

I use the vTiger CRM product and it has a unusual quirk with enabling backups. Whilst the user interface (CRM settings -> Backup server) has check boxes to enable local and FTP backup the script actually tries to alter the following file, /user_privileges/enable_backup.php and in that set the two flags to a value of either true or false,

$enable_local_backup = 'true';

$enable_ftp_backup = 'false';

As the script has no permissions to do that then it gets a fopen() permission error (Warning: fopen(/*****/user_privileges/enable_backup.php): failed to open stream: Permission denied in /****/modules/Settings/SaveEnableBackup.php on line 43) and so when the ajax refreshes the screen it looks as if nothing has been done.

Without messing with your directory permissions then you can edit the /user_privileges/enable_backup.php manually.

Even if you manage to get the directory details into the local backup it will not work unless that enable local backup flag is set to true. It will say that it has done a backup but it will not save any file.

PHP Warning: Invalid argument supplied for foreach()

If you get a Warning: Invalid argument supplied for foreach() but the code looks and seems to work fine then the issue is that foreach() needs an array but you are passing a Boolean due to an error in a previous function.

You will see this problem where you have something that is returning an array or false e.g. glob() and then you pass the returned value to the foreach() without checking if the variable isn’t false. e.g. in this case glob() can return false if it can’t see the path,

        foreach( $paths as $path ) {
            $filenames = glob( $path['path'] );
            if ( $filenames != false ) {
                foreach( $filenames as $filename )

In that example if glob() failed on one of the paths then it would return false. In my example above I check that $filenames is not false before I use it with foreach(). You can also use is_array() as well. To confirm your theory on your code you can add in var_dump() before the foreach() on the variable that you pass to confirm the type of the variable of what you use in foreach().

 

Using error_log() with print_r() to gracefully debug PHP

When debugging php code (especially Open Source code you have not written yourself) then to get a feeling of what is passed around when it doesn’t work I find that the print_r() function is very useful.

Trouble is that if you just throw in print_r() into the code where you think it is faulty then you can upset json, AJAX or your web page layouts as the print_r() splatters stuff to your displayed web page or in some cases the PHP file is not going to a browser (e.g. the PayPal IPN notify).

The trick is to throw it at the error log as follows e.g. if I was tracing what $number was being set to then I would use….

error_log(print_r($number,true));

note that you MUST set that print_r() option to “true” so that it returns a string. This string is then sent to the error_log() function which formats it with referrer details and puts it into the Apache error log.

Where does it end up ? Well on my test system on a non-vHost it is /var/log/apache2/error.log and on a vHosted server it is :/var/www/vhosts/<domain name>/statistics/logs/error_log so on your own system it will be a similar Apache error log file. Just tail that file to see what the messages are which will be something like this (in this example the $number was “2008” so the output for that error log message was,

[Sun Jan 01 13:21:12 2012] [error] [client 192.168.2.2] 2008, referer: http://19
2.168.2.250/bluebox/index.php/numbermanager/index

To synchronize the log messages with your testing then just look at the logging time.