UPDATE Content Elements and issues with unserialize()

Question

Update
The issue seems to be an unserialize() error. I wasn't getting notified before because CE suppresses error reporting on unserialize in various places in ft.content_elements.php. I'm going to keep digging to find out whether this is an EE issue, or what.

If anyone has run into unserialize issues with EE before, it would be much appreciated!

Original Post

So, I have content elements rendering the content of entries in my templates. For some reason that I can't isolate, some entries are rendered without any output from the content elements tag.

To be clear, it works just fine on some entries, but renders nothing on some entries.

I've checked the database and there is indeed the appropriate data in the exp_channel_data table. I've also checked the MySQL and PHP logs for something helpful, but nothing useful seems to be reported.

I'm not even sure exactly where to begin as far as giving helpful code. Would my CE snippet help?

Luckily this problem is only happening in my development environment, so there is a live site with the fishy content we could look at. The other issue is that I noticed this after upgrading various different add-ons and extensions, but even after rolling back the system code (via version control) and resetting my DB to a pre-update version, the issue persists.

Here are the extensions I'm using and version numbers and all that. Any help or guidance would be greatly appreciated! For example, does EE generate any helpful logs during the template parsing process?

EE 2.8.1 Content Elements 1.6.9 Wygwam 3.3 Assets 2.3.1 Low Search 3.1.4 Low Variables 2.4.2 Stash 2.4.6 Structure 3.3.14.4 Zenbu 1.9.1 Zoo Flexible Admin 1.81

Others too...

It seems like there is some kind of error during the parsing process so EE bails on generating the data from the DB. I can see it in the table, but it's not showing up on the front end :(.

Answer 1

Well, this was quite frustrating but I hacked together a workaround that at least lets me move forward and will make due for this use case.

It seems the issue stems from a database migration. I dumped the DB from production and loaded it up locally, which is where the non-render issue presented itself. I was able to force the errant entries back into whatever EE-DB-friendly format is required with the following steps.

1. Drop this function into the ft.content_elements.php file (taken from here):

   function mb_unserialize($string) {
       $string = preg_replace('!s:(\d+):"(.*?)";!se', "'s:'.strlen('$2').':\"$2\";'", $string);
       return unserialize($string);
   }
   

2. Identify the entries that need to be "re-formatted".

3. Do a wildcard search/replace in ft.content_elements.php for unserialize with $this->mb_unserialize. (:%s/unserialize(/\$this->mb_unserialize(/ in vim).

4. Load up the entry on the front-end to verify that the multi-byte deserializer is working. If the entry is loading, it should load in EE.

5. Load up the entry edit form in EE. Correct any formatting issues (delete escaped quotation marks, fix hyperlinks, etc.). Save the entry.

6. Undo your previous changes to ft.content_elements.php. The entries should load up fine now.

Yeah, definitely not an ideal process, but I am not inclined to go combing through CE's codebase to parse what exactly is going on (for shame!), but hopefully these posts will be properly formatted for future migrations as well.