Title: Fatal Error: PLL_Model::_languages_list()
Last modified: August 22, 2016

---

# Fatal Error: PLL_Model::_languages_list()

 *  [Daseb](https://wordpress.org/support/users/daseb/)
 * (@daseb)
 * [11 years, 7 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/)
 * We’re trying to move our site to a Go Daddy WordPress managed hosting and get
   the following error caused by the Polylang plugin:
 * Fatal error: PLL_Model::_languages_list(): The script tried to execute a method
   or access a property of an incomplete object. Please ensure that the class definition"
   PLL_Language" of the object you are trying to operate on was loaded _before_ 
   unserialize() gets called or provide a __autoload() function to load the class
   definition in /home/content/p3pnexwpnas03_data02/52/2358252/html/wp-content/plugins/
   polylang/include/model.php on line 200
 * Go Daddy support described the Polylang plugin as “broken”. Could give no more
   specifics on what they meant by that, but advised we contact you guys.
 * Any thoughts?
 * [https://wordpress.org/plugins/polylang/](https://wordpress.org/plugins/polylang/)

Viewing 14 replies - 1 through 14 (of 14 total)

 *  Plugin Author [Chouby](https://wordpress.org/support/users/chouby/)
 * (@chouby)
 * [11 years, 7 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5652838)
 * Hi!
 * > Go Daddy support described the Polylang plugin as “broken”. Could give no more
   > specifics on what they meant by that,
 * I would be extremely happy to know what they meant by that. As far as I know 
   Go Daddy is the only host conflicting with Polylang with this error.
 * Put this
 *     ```
       define('PLL_CACHE_LANGUAGES', false);
       ```
   
 * in your wp-config.php
    *above* `/* That's all, stop editing! Happy blogging. */`
   See also [https://polylang.wordpress.com/2014/07/12/polylang-1-5-3/](https://polylang.wordpress.com/2014/07/12/polylang-1-5-3/)
 *  [MatVanRhoon](https://wordpress.org/support/users/matvanrhoon/)
 * (@matvanrhoon)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653169)
 * I can safely say that this solution fixed the problem on my website (which is
   also hosted on GoDaddy). All GoDaddy customers who may still be experiencing 
   the issue must be sure to clear the website cache after applying the fix. Failing
   to do so will cause the error to remain on the servers.
 *  [happyfrogtravels](https://wordpress.org/support/users/happyfrogtravels/)
 * (@happyfrogtravels)
 * [11 years, 5 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653192)
 * Hi guys,
 * I have read several topics regarding this issue, and I still don’t know what 
   to do! In my case there are two tipes of errors.
 * The first one ocurrs when entering my website happyfrogtravels.com. It happens
   whenever anything needs to be updated (any theme, plugin, etc..), and at those
   moments I can’t access the site:
 * Fatal error: PLL_Model::_languages_list(): The script tried to execute a method
   or access a property of an incomplete object. Please ensure that the class definition"
   PLL_Language" of the object you are trying to operate on was loaded _before_ 
   unserialize() gets called or provide a __autoload() function to load the class
   definition in /home/content/p3pnexwpnas03_data03/81/2398881/html/wp-content/plugins/
   polylang/include/model.php on line 199
 * The second error ocurrs when I want to access a specific post, or in the case
   of changing from one language to another. For instance if I change from Category
   Belgium to category Bélgica by clicking on the Spanish flag (The same category
   in different language):
 * Fatal error: Cannot use object of type __PHP_Incomplete_Class as array in /home/
   content/p3pnexwpnas03_data03/81/2398881/html/wp-includes/functions.php on line
   3185
 * I see that Chouby recommends changing the wp-config.php directory, but I simply
   can’t do that. I’ve talked to Go Daddy, they gave me instructions to access it,
   but I can’t even install FileZilla. Gor some reason my computer doesn’t respond
   to that.
 * So that option is out of the question.
    Is there anything I can do inside my 
   Dashboard, like editing a component of the plugin itself?
 * I am using the latest WordPress (4.1.1.) and Polylang plugin 1.6.5
 * Thanks in advance,
    Milos
 *  Plugin Author [Chouby](https://wordpress.org/support/users/chouby/)
 * (@chouby)
 * [11 years, 5 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653193)
 * I am sorry but if you can’t edit your wp-config.php and want to stay with Godaddy,
   you won’t be able to use Polylang.
 * I am unable to fix this issue with Godaddy without penalizing all other users
   which are hosted elsewhere, because Godaddy does not provide any hint.
 *  [captin411](https://wordpress.org/support/users/captin411/)
 * (@captin411)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653198)
 * I was running into this problem as well. It turns out it has to do with hosting
   providers using object caches.
 * Here is how it breaks.
 * 1) polylang writes cached languages to cache as a transient
    2) another http 
   request comes in to some apache/fastcgi (whatever) process that has no cache 
   info 2a) the cache is loaded from the db (before the poly lang plugin is loaded)
   2b) polylang tries to deserialize the object and it doesn’t quite work when it
   tries to access properties 3) explosions
 * My patch to fix this (diff against 1.7.2).
 *     ```
       --- model.php	2015-03-23 16:21:56.000000000 -0700
       +++ /Users/davidbartle/dbartle_model.php	2015-04-03 10:16:26.000000000 -0700
       @@ -5,6 +5,13 @@
         *
         * @since 1.2
         */
       +
       +function _pll_maybe_fix_object($object) {
       +    // Thanks google, stackoverflow and 23hush for the technique
       +    // http://stackoverflow.com/questions/965611/forcing-access-to-php-incomplete-class-object-properties
       +    return !is_object($object) && gettype($object) == 'object' ? unserialize(serialize($object)) : $object;
       +}
       +
        class PLL_Model {
        	public $options;
        	protected $cache; // our internal non persistent cache object
       @@ -173,6 +180,10 @@
   
        		$args = wp_parse_args($args, array('hide_empty' => false));
   
       +        foreach ($languages as $k => $v) {
       +            $languages[$k] = _pll_maybe_fix_object($v);
       +        }
       +
        		// remove empty languages if requested
        		$languages = array_filter($languages, create_function('$v', sprintf('return $v->count || !%d;', $args['hide_empty'])));
   
       @@ -190,6 +201,7 @@
        	public function _languages_list() {
        		if ((defined('PLL_CACHE_LANGUAGES') && !PLL_CACHE_LANGUAGES) || false === get_transient('pll_languages_list')) {
        			foreach ($languages = $this->cache->get('languages') as $language) {
       +                $language = _pll_maybe_fix_object($language);
        				$language->set_flag();
   
        				if (!defined('PLL_CACHE_HOME_URL') || PLL_CACHE_HOME_URL) {
       @@ -202,6 +214,7 @@
        		}
   
        		foreach ($this->cache->get('languages') as $language) {
       +            $language = _pll_maybe_fix_object($language);
        			if (defined('PLL_CACHE_HOME_URL') && !PLL_CACHE_HOME_URL)
        				$language->set_home_url();
   
       @@ -259,7 +272,7 @@
        			$return = $this->cache->get('language:' . $value);
        		}
   
       -		return $return;
       +		return _pll_maybe_fix_object($return);
        	}
   
        	/*
       ```
   
 * Thing I’ve personally learned:
    – I’ll probably avoid storing objects in wp transients
   just to avoid this all together – and instead just use associative arrays
 *  [captin411](https://wordpress.org/support/users/captin411/)
 * (@captin411)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653199)
 * I should note that the “no cache” option did not work for me either.
 *  Plugin Author [Chouby](https://wordpress.org/support/users/chouby/)
 * (@chouby)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653200)
 * Hi!
 * Thanks a lot for your interest in helping me to sort out this problem and your
   proposed solution.
 * However, I am not sure to understand the problem in the step 2.
 * If there is no cache info, get_transient should return false and thus the PLL_Language
   object and recreated from ground zero.
 * If the cache is found, thus the object should be created when unserialized thanks
   to the autoload function. Is it this step which break?
 * > I should note that the “no cache” option did not work for me either.
 * PLL_CACHE_LANGUAGE set to false should always bypass the object construction 
   from the transient. Why does it not work for you?
 *  [captin411](https://wordpress.org/support/users/captin411/)
 * (@captin411)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653201)
 * In this case, get transient does not return false – and it should not.
 * The bug comes when an unprimed intermediary object cache doesn’t have the object
   in memory and in turn loads it from the database (via get transient).
 * Maybe I can ASCII picture it out:
 * Pretend each thread has no knowledge or shared data from the other threads
 *     ```
       [Thread A]
         -> WordPress loads
           -> APC object cache loads
             -> polylang is loaded
               -> PLL_Language include is loaded
                 -> PLL save cache languages
                   -> save transient as object
                     -> transient is saved in mysql
       [Thread B]
         -> WordPress loads
           -> APC object cache loads (it actually loads all transients and options from mysql and HERE is where the problem is, the object exists, but the polylang includes have not yet been loaded and thus deserialization fails)
             -> polylang is loaded (classes are loaded but too little too late)
               -> language loaded from object cache (incomplete deserialization)
                 -> some code us run that tries to access a property of language object which is not "real"
                   -> PHP failure
       ```
   
 * I was not able to see a way for plugins to run any hooks that would berun BEFORE
   object caches are taken into consideration.
 * Another option is a refactoring of how the transients are stored: namely don’t
   store object but associative arrays and move the array-to-object logic into the
   polylang plugin.
 * My patch is written with the intent of avoiding a refactor.
 * Hope this clears things up.
 *  [captin411](https://wordpress.org/support/users/captin411/)
 * (@captin411)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653202)
 * As for why the cache option did not work. I believe it is a chicken and egg problem.
 * I installed polylang and set it up. Then got the error — but the fastcgi or apache
   object caches now already have the objects in this odd state. (and I suspect 
   $this->cache->get(…) runs, “succeeds” and bypasses the PLL_CACHE_LANGUAGE check
   altogether).
 * Because it’s a shared hosting environment, I do not have the ability to reboot
   the web server processes.
 * This fix should correct things for people running on shared hosts that still 
   WANT to leverage an object cache for performance reasons.
 * I am willing to work on some alternative code patches if you think there is a
   better approach.
 *  [captin411](https://wordpress.org/support/users/captin411/)
 * (@captin411)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653203)
 * Perhaps these lines:
 *     ```
       ...
       if (false === $languages = $this->cache->get('languages')) {
       			if ((defined('PLL_CACHE_LANGUAGES') && !PLL_CACHE_LANGUAGES) || false === ($languages = get_transient('pll_languages_list'))) {
       ...
       ```
   
 * Could instead read something like this:
 *     ```
       ...
       $FORCE_NOCACHE = defined('PLL_CACHE_LANGUAGES') && !PLL_CACHE_LANGUAGES;
   
       if (($FORCE_NOCACHE || false === $languages = $this->cache->get('languages'))) {
       			if (($FORCE_NOCACHE || false === ($languages = get_transient('pll_languages_list'))) {
       ...
       ```
   
 * I have not explored any of the side effects this change would have at all tho.
 *  [captin411](https://wordpress.org/support/users/captin411/)
 * (@captin411)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653204)
 * Feel free to reach out on the wordpress slack [@captin411](https://wordpress.org/support/users/captin411/)
   I would love to help out.
 *  [captin411](https://wordpress.org/support/users/captin411/)
 * (@captin411)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653205)
 * Sadly, I am no longer able to reproduce this on my hosting account. If I find
   any more information I will be sure to follow up.
 *  Plugin Author [Chouby](https://wordpress.org/support/users/chouby/)
 * (@chouby)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653206)
 * >  -> APC object cache loads (it actually loads all transients and options from
   > mysql and HERE is where the problem is, the object exists, but the polylang
   > includes have not yet been loaded and thus deserialization fails)
 * Thank you very much. That’s clear now.
 * >  Thing I’ve personally learned:
   >  – I’ll probably avoid storing objects in wp
   > transients just to avoid this all together – and instead just use associative
   > arrays
 * Although it was convenient, I must admit that you are right. That’s why I chose
   to refactor (that wasn’t a big deal) rather than introduce your proposed fix.
   
   I uploaded a new development version (1.7.2.4). I would be very happy if you 
   could test it and let me know what you think. [https://downloads.wordpress.org/plugin/polylang.zip](https://downloads.wordpress.org/plugin/polylang.zip)
 * NB: you will need to resave the Polylang settings to clear the transient to have
   it storing arrays instead of objects. I did not add any upgrade procedure as 
   the code can deal with languages stored as objects and arrays.
 *  Plugin Author [Chouby](https://wordpress.org/support/users/chouby/)
 * (@chouby)
 * [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653207)
 * > Sadly, I am no longer able to reproduce this on my hosting account. If I find
   > any more information I will be sure to follow up.
 * I read this after writing my previous post.

Viewing 14 replies - 1 through 14 (of 14 total)

The topic ‘Fatal Error: PLL_Model::_languages_list()’ is closed to new replies.

 * ![](https://ps.w.org/polylang/assets/icon-256x256.png?rev=3433336)
 * [Polylang](https://wordpress.org/plugins/polylang/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/polylang/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/polylang/)
 * [Active Topics](https://wordpress.org/support/plugin/polylang/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/polylang/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/polylang/reviews/)

 * 14 replies
 * 5 participants
 * Last reply from: [Chouby](https://wordpress.org/support/users/chouby/)
 * Last activity: [11 years, 4 months ago](https://wordpress.org/support/topic/fatal-error-pll_model_languages_list/#post-5653207)
 * Status: not resolved