Error decoding JSON data: Syntax error after update to 3.6.3

[rbuelund]

Yes - there is absolutely something wrong with the params field - but where did all thoses signs come from!? This has happened after upgrade from 3.6.2 to 3.6.3

[rbuelund]

I have another params field that looks like this:

{"language":"","editor":"","timezone":"Europe\/Copenhagen","0":"{\"language\":\"\",\"editor\":\"\",\"timezone\":\"Europe\\\/Copenhagen\",\"0\":\"{\\\"language\\\":\\\"\\\",\\\"editor\\\":\\\"\\\",\\\"timezone\\\":\\\"Europe\\\\\\\/Copenhagen\\\",\\\"0\\\":\\\"{\\\\\\\"language\\\\\\\":\\\\\\\"\\\\\\\",\\\\\\\"editor\\\\\\\":\\\\\\\"\\\\\\\",\\\\\\\"timezone\\\\\\\":\\\\\\\"\\\\\\\"}\\\"}\"}","admin_style":"","admin_language":"","helpsite":""}

I believe it should look like this:


{"language":"","editor":"","timezone":"Europe\/Copenhagen","0":"{"language":"","editor":"","timezone":"Europe\/Copenhagen","0":"{"language":"","editor":"","timezone":"Europe\/Copenhagen","0":"{"language":"","editor":"","timezone":""}"}"}","admin_style":"","admin_language":"","helpsite":""}

..or am i wrong here ? Where do all those \ signs come from ? I believe they are filling up and corrupting the user profiles.

[Per Yngve Berg]

No, it did not happen during the upgrade, but only manifested after the upgrade.

Do the faulty user differ from the others?

Code: Select all

{"admin_style":"","admin_language":"nb-NO","language":"nb-NO","editor":"","helpsite":"","timezone":""}

Looks like you had Magic Quotes enabled on php 5.3 some time in the past.

[rbuelund]

Most user profiles look like this:
{"language":"","editor":"","timezone":"","0":"{\"language\":\"\",\"editor\":\"\",\"timezone\":\"\"}"}

But many have way more \ signs and therefore get corrupted I believe.
So I believe I'll have to manually restore the params fields to this for the ordinary user?:
{"language":"","editor":"","timezone":"","0":"{"language":"","editor":"","timezone":""}"}

..or how does the default params string look like ?

[rbuelund]

Magic quotes has been disabled on the server since Joomla 3 so on the new sites I have on that server, this can not be the reason for this problem?

[deleted user]

@rbuelund I'd honestly just suggest deleting the column's data and leaving it empty for now. It is massively corrupt.

[I-MAG]

I solved it for now.
I copied the library folder from joomla 3.6.2, overwriting the one from 3.6.3
/kasper

That worked for me. Thanks.

[strix6]

Will things be fixed in 3.6.4 this tuesday?

[rbuelund]

@rbuelund I'd honestly just suggest deleting the column's data and leaving it empty for now. It is massively corrupt.

I believe that deleting all params data for all users will only affect those users who eventually has chaged their editor or language ? Otherwise nothing will happen ?
I will need to insert {} in the column - not ?

[deleted user]

Editor, language, and timezone.

[brian]

Code cannot fix faulty data - only fixing the data can fix the problem

Everyone that I have seen so far has faulty data so the error message from the code is correct and will not be changed

[JFS]

Okay, so what is the best way to find the corrupt data then? Any best practice here?

*edit

without digging around too much in the code

Code: Select all

update xxxx_modules set params="" WHERE params = "{\"\"}";

helped me here.

[hamsteg]

I too have the error and added the data to the exception but I see nothing strange ...

Code: Select all

exception 'RuntimeException' with message 'Error decoding JSON data: Syntax error the bad data is: {"show_title":"","link_titles":"","show_intro":"","show_section":"","link_section":"","show_category":"","link_category":"","show_vote":"","show_author":"","show_create_date":"","show_modify_date":"","show_pdf_icon":"","show_print_icon":"","show_email_icon":"","language":"","keyref":"","readmore":"","show_parent_category":"","link_parent_category":"","link_author":"","show_publish_date":"","show_item_navigation":"","show_icons":"","show_hits":"","show_noauth":"","alternative_readmore":"","article_layout":"","show_publishing_options":"","show_article_options":"","show_urls_images_backend":"","show_urls_images_frontend":""}' 

I did a database search on {""} in the params column but that returned nothing. xxxx_components is clean. 5 empty lines, the rest is filled. It seems that certain "older" articles are not functioning. Coming closer, though I do not understand it. In SQL I selected two old failing articles and two new still showing articles.

Code: Select all

select * from XXXX_content where id=139 or id=145 or id=571 or id=575

The attribs column shows the difference. Removing the attribs removes the error (anybody knows how bad this is?).

The answer lies in the string ... but I have no idea what, copied from the database:

Code: Select all

"show_title":"","link_titles":"","show_intro":"","show_section":"","link_section":"","show_category":"","link_category":"","show_vote":"","show_author":"","show_create_date":"","show_modify_date":"","show_pdf_icon":"","show_print_icon":"","show_email_icon":"","language":"","keyref":"","readmore":"","show_parent_category":"","link_parent_category":"","link_author":"","show_publish_date":"","show_item_navigation":"","show_icons":"","show_hits":"","show_noauth":"","alternative_readmore":"","article_layout":"","show_publishing_options":"","show_article_options":"","show_urls_images_backend":"","show_urls_images_frontend":""}

Replacing the attribute with {} seems to solve the problem. Newer articles don't have this field filled so is this field still needed to be filled?


SOLUTION for older articles! (v1.5 upgraded)
Do not disable line 72 but change line 67 to:

Code: Select all

$decoded = json_decode(html_entity_decode($data));

The json_decode function cannot handle html entities! I find this a serious short coming of the 3.6.3 update (due to creating an exception without testing), this needs to be updated fast!

Question: anybody know what the attributes are used for? Maybe a remove of them can solve the problem too?

[I-MAG]

I updated to 3.6.4 which came out today, and the problem is back!

[hamsteg]

I have something similar going on but not quite the same as the accounts above. I updated 10 Joomla sites to 3.6.3. All are on the same server. Only one is throwing this JSON error on EDITING an article. Adding a new article works just fine. We cannot edit any articles. I have tried disabling the different admin modules and I've run some sql searches for {""} as well. I'm not finding anything. Any ideas? I'm at a loss.

See my solution in this topic, it has to do with HTML entities in the attributes column of xxx_content and the json_decoding().

[mojito]

Its perhaps philosophically correct to say that the data is corrupt so the code is ok. However always opinion and the practicalities that follow. I wish coders could see the real world works unlike a server environment or compiler.
There are a lot of users here with this issue and not a great helpful solution. It feels a bit like the SEO arguments against joomla. Joomla devs shouldn't have to consider SEO I GOTIT now thanks after a few years ! Wordpress seem to care however so joomla is getting its ass kicked and you ought to care or go start to work on wordpress.
This data came from legacy code or plugins.
If ever I wrote a code improvement I would try and consider the real world scenarios. Writing data that was ok at some point by joomla or a 3rd party plugin should not break the system.
Joomla released code that says we need this data to be ratified. Maybe have a softer error. Allow us to know WHICH JSON is the issue so we can fix it ??

It feels like there has been some corporate memo for a few years that has changed the spirit and I didnt want to believe it. I am trying to resist the urge to convert to wordpress but it feels almost like I am being forced. No seo no xml sitemap plugin but yes much better foundation for things like ACL. I want to love and stay joomla but you guys are making it hard.

[markloewy]

Here was my situation...
I have 20 sites on the same server and 4 of them had this issue. Strangely enough, all 4 of them were using Sucuri Web Proxy service that protects the Joomla sites. I got this blue screen when trying to access the back-end of the Joomla sites. All problem sites were on Joomla 3.6.3 and I was trying to update to 3.6.4. Here is how I fixed it.
- Downloaded the file: Joomla_3.6.2-Stable-Update_Package.zip from www.joomla.org. This is a previous version.
- Upload the file to the root folder of the website
- Extract the file (you are now reverted back to Joomla 3.6.2)
- Login to the Joomla admin part of the site.
- Components...Joomla Updates and go ahead and run the updater
- All fixed and you are now on 3.6.4

This solution worked on all 4 of the sites. Must be something in 3.6.3.

[rbuelund]

Joomla released code that says we need this data to be ratified. Maybe have a softer error. Allow us to know WHICH JSON is the issue so we can fix it ??

I must agree on the above !

[xiphias]

I have the same error but in the backend when editing a K2 item. Even after the update to 3.6.4 I still have this issue where I can't edit a K2 item. Frontend looks fine. Checked JSON in SQL and all looks valid.
I can add a new K2 item and edit that new item.

Anyone else having the same problem?

[CatfishPKR]

I fixed the issue by overweriting the /libraries folder with the 3.6.2 version. Then, after the 3.6.4 update, the same problem reappears. Overwritten with 3.6.2 folder again, problem fixed. How about fixing this problem for good in the next Joomla update?

[deleted user]

For the last time there is no error to fix in the core of Joomla except for reverting the checks for invalid data structures and allowing sites to blissfully ignore the fact they have corrupt database fields.

The "fix" is to fix your databases. I'm thoroughly getting tired of explaining this. If you really think Joomla should let your sites run without any indication of broken data or configurations, petition to the leadership to merge this pull request which removes integrity checks - https://github.com/joomla/joomla-cms/pull/12562

[apsilva]

Robert Went posted a small script that intends to solve most of the bad JSON in the database issues.
Didn't test it, so, of course, make a backup if you intend to use it and use it at your own risk.

See https://github.com/robwent/joomla-json-db-check

[cybersholt]

Edit: looks like I was replying to old comments. Please disregard.

[sgodun]

After updating from 3.6.2 to 3.6.4 I started getting the "Error decoding JSON data: Syntax error" message when trying to run the "Eyesite" extension (v3.08 and v3.10).

https://extensions.joomla.org/extension/eyesite

EDIT: Never mind. It fixed itself. :-/

[Mzlaki]

I had the same error after updating to J! 3.6.4, the issue appeared when editing K2 items. Error decoding JSON data: Syntax error
I overwrote the files in /libraries/vendor folder with the ones from version 3.6.2.
Everything seems to be back to normal.

[mojito]

mbabker is going to be mad !

[Mzlaki]

Well I did try to fix the database, but it didn't need fixing. And it's more important my site works, than make mbabker happy.

[mojito]

At the end of the day this code update was bad. They can defend it at a hard limit but there should have been a cleanup or warning or auto resetting of broken fields. I am going to have to take drastic action like this as well. Did you try robert wents script ? I would like to know if anyone did.
https://github.com/robwent/joomla-json-db-check

[naghris]

Brent Laminacks sql-fix to modules table worked for me. Has this solution any side-effects?

[deleted user]

At the end of the day this code update was bad. They can defend it at a hard limit but there should have been a cleanup or warning or auto resetting of broken fields.

You can't auto-clean this up. It would essentially mean loading every record from every JSON based field in the database into memory and trying to decode it, and that would only cover the database tables that core knows the schema for (so no third party extension tables). That process alone would be massively memory heavy and would probably time out the upgrade on a lot of systems. So that's not really an option either.

That cleanup tool, while it can work for a lot of cases, only matches select patterns and only for a couple of columns. There was a bug report for this same issue and the JSON string had a bunch of trailing characters at the end of it that broke things that a pattern matching tool won't catch. So while it'll definitely help for a lot of cases, it's not a full solution.

I already made a proposal to remove the error check since people could care less whether they have bad data. Petition leadership if you really want that in core.

And it's more important my site works, than make mbabker happy.

You're right. But this isn't about making me happy by any means. Your site is "functioning" without this error check, but it is blissfully ignoring the fact that there is broken data in your database. Sooner or later you must address this fact. The fact Joomla blissfully ignored invalid configurations and data records in the past is not justification for continuing to do so in the future; we add these error checks to help prevent other errors and unfortunately it comes with side effects like totally bringing down a site because nothing in the code catches and gracefully handles these errors.