Articles not showing "SyntaxError: Unexpected Token"

Having an issue in MODX where articles have suddenly stopped displaying.

Here are screenshots of the issue





And some details about MODX version (2.5.0 pl)


It appears like the JSON is returning no results at all, despite there being database records.

Actions I have tried to resolve the problem:

1. updating to the latest version of MODX
2. Uninstalling and re-installing article related modules (articles, taglister, quip)
3. Updating article related modules
4. deleting the core/cache folder
5. putting cloudflare into development mode
6. clearing the modx cache
7. repairing the bt01_site_content database table

None of the above has worked. I'd be extremely grateful if you could point me towards a solution for this problem. We have other MODX sites on the exact same server with this setup and all of those are loading articles fine (so it can't be a server config issue). Also If I try to load an individual blog post by copying the ID into the correct URL (e.g. http://www.bodytransformation.co.uk/manager/?a=resource/update&id=146) then it loads and can be edited fine, the issue is just with the list view.

Thanks
Andrew
[ed. note: scorchsoft last edited this post 10 years, 4 months ago.]

That's an odd one. Are the articles visible in the front end? Is there anything helpful in the MODX Error Log?

You might check the modx_site_content table in the DB to see if the 'parent' field of the articles is always set to the articles container's ID. Sometimes an invalid parent can prevent display in the Manager. While you're there, see if the class_key is set to Article and the context_key is correct.

Quote from: BobRay at Jun 03, 2016, 02:35 PM

That's an odd one. Are the articles visible in the front end? Is there anything helpful in the MODX Error Log?

You might check the modx_site_content table in the DB to see if the 'parent' field of the articles is always set to the articles container's ID. Sometimes an invalid parent can prevent display in the Manager. While you're there, see if the class_key is set to Article and the context_key is correct.

Yeah they are visible:
http://www.bodytransformation.co.uk/resources.html
If I type in the ID in the back end then you can edit them too.


In terms of the parent ID. The parent resource has the ID "8", same as the resources in the database


Class and context keys also look fine:


Either way, it is the whole list failing to display, not just a single article. It's like there is some dodgy record somewhere causing the whole thing to bug out

Ok so went through every blog article and changed the parent ID from 8 to -8 one by one. Logic being that if there was a dodgy record then it would make things appear again.

Result, item of content 126 and 145 were causing my pain:
screenshot of resource #126: http://i.imgur.com/s0vRsf5.png
Screenshot of resource #145: http://i.imgur.com/bVTPEMZ.png

And here is the SQL file for both of these records should anyone reading this want some debugging data:
https://www.dropbox.com/s/wkx4jj4qzf4snbr/dodgy%20records.sql?dl=0

and with it removed, articles are back.

My thinking is that the site was running an old version of articles that somehow allowed this info to be corrupted. Once corrupted it killed the list of articles (though in my view this list should be able to handle dodgy data without returning an empty list). Not sure what in the data caused it, though something clearly did/.

It's possible that your problem was caused by character set issues, or pasting from a word-processing program (e.g., Word). If it's the character set, you may have more trouble down the road.



There is information on character set issues here: http://bobsguides.com/convert-db-utf8.html.

You can check the character set in the MODX core/config/config.inc.php file against the actual values in the DB with PhpMyAdmin. Be sure to check the DB, the tables, *and* the text fields within the tables (or let SiteCheck check them for you).

Thanks for your support on this Bob. It looks like all the character sets marry up as latin1:

Config file:


Database table:


Individual columns:


Not utf-8 but it is at least consistent.

So pasting from word is the most likely culprit, though shouldn't MODX/SQL catch this upon save? Or maybe it does now but didn't in the older Articles extra?

Oh and I've bought site check from your website. Just by way of buying you a beer.

Thanks! I hope you find it useful.

Undoing the mess Word makes out of the data is too complex for MODX to deal with. If you have an old copy of notepad, or something similar, you can paste the text there first to remove the Word crud. Some text editors also have a 'paste from word' function (I think TinyMCE may have that as well).

Ok fair enough. You can use ctrl+shift+v to paste with no formatting in most web browsers to save having to copy into notepad.

Yup! TinyMCE cleanup is pretty advanced. It will clean any and all things upon paste, depending on your configuration.