Subject browse produces 500 Internal Server Error

Skip to first unread message

John Thiesen

Nov 2, 2021, 2:04:17 PM11/2/21
to AtoM Users
We're on AtoM 2.6. I've noticed that there are a couple of places where Subject browse produces "500 Internal Server Error." I'm thinking there must be a couple of subject terms that are corrupted

You can reproduce the error at by using "wood*" or "Yoder*" in the search box. This happens also if the user is browsing up or down the list and happens to hit one of these terms. I've run through the entire list of terms elsewhere in the alphabet and did not find additional bad terms

Is there any way I can delete the 2 corrupted terms? Or even find out what they are?

Dan Gillean

Nov 2, 2021, 4:17:01 PM11/2/21
to ICA-AtoM Users
Hi John, 

If you haven't already, I'd suggest taking a look at the webserver error logs to see if the related error message might provide more information on what's causing this 500 error. Feel free to share what you find here if you're uncertain how to proceed. For checking the error logs, see: 
After that, the first thing I would suggest that you try is running a couple maintenance tasks that can fix common corruption issues - namely, rebuilding the nested set and generating slugs.
If a search is causing the 500 error, then there could also be an issue with the search index - hopefully the error logs will tell us more, but you can get some basic information on the status of your index with this task:
And you could try re-indexing - but be aware that this can be a long-running process that will make your content temporarily unavailable while it runs, so it's generally best to start a re-index outside of business hours, or even on a Friday so it can run over the weekend for a large site. See: 
(That said, kicking off a reindex only to return on Monday to discover it failed due to whatever is causing this error would not be great, so you may want to try the other steps in this thread first, and if they don't fix the issue, report back on what you find in the error logs and from the search:status task)

Whether you choose to re-index or not at this time, after any of the above steps I would clear the application cache, restart PHP-FPM, and do a quick test to see if that happened to resolve the issue. 
If that works - great! If not, then we do have some MySQL queries that might be helpful for identifying data corruption in our Troubleshooting documentation. You will need to access the MySQL command prompt to run the queries - instructions on how to do so can be found here: 
The data corruption check queries can be found here: 
These queries currently mainly help identify problems with information objects (i.e. archival descriptions), but may still help to uncover related issues. If you do find issues, that section of the documentation has a few follow-up recommendations depending on what you find. 

Otherwise, please share with us anything relevant you discover during your investigation, and we can attempt to provide further suggestions based on that. 

Good luck!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
he / him

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit
Reply all
Reply to author
0 new messages