ERROR(EAD-EXPORT): PHP Warning: count(): Parameter must be an array or an object that implements Countable in

144 views
Skip to first unread message

shiva naik

unread,
Mar 2, 2022, 5:02:40 AM3/2/22
to AtoM Users
Hi Support,

One of the jobs while generating gives below errors, could you please advise how do I fixed it.

-----------------------------------

ERROR(EAD-EXPORT): PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/nginx/atom/plugins/sfEadPlugin/modules/sfEadPlugin/templates/indexSuccessBodyDidElement.xml.php on line 137

ERROR(EAD-EXPORT):

ERROR(EAD-EXPORT):

ERROR(EAD-EXPORT): Invalid XML generated for object 71122.

ERROR(EAD-EXPORT):

ERROR(EAD-EXPORT):

ERROR(EAD-EXPORT): <?xml version="1.0" encoding="utf-8" ?>

ERROR(EAD-EXPORT): <ead>

ERROR(EAD-EXPORT): <eadheader langencoding="iso639-2b" countryencoding="iso3166-1" dateencoding="iso8601" repositoryencoding="iso15511" scriptencoding="iso15924" relatedencoding="DC">

ERROR(EAD-EXPORT): <eadid identifier="cwl" countrycode="GB" mainagencycode="ARCHON 2913" url="https://archive.rcdea.org.uk/index.php/cwl" encodinganalog="identifier">CWL</eadid> <filedesc>

ERROR(EAD-EXPORT): <titlestmt>

ERROR(EAD-EXPORT): <titleproper encodinganalog="title">Catholic Women&#039;s League - East Anglia Branch</titleproper>

Dan Gillean

unread,
Mar 2, 2022, 8:40:33 AM3/2/22
to ICA-AtoM Users
Hi Shiva, 

I used the URL of the description in the provided error message to view the record and try exporting the EAD myself. While I also got an error, it was a different one: 

Unknown record property "entityTypeId" on "QubitStaticPage"

At a glance I'm not sure exactly what is causing these errors without more information. I can however offer a few starting suggestions. 

First, it would be helpful to know more about your installation, such as: 
  • What is the full AtoM version number listed in Admin > Settings > Global at the top of the page?
  • Have you recently upgraded?
  • Did you follow the recommended installation instructions for your version? If no, what changes have you made (in operating system, PHP version, database, webserver, etc)?
  • Was this record created via the user interface, or imported? 
    • If created via the user interface, was any of the text copied from an external source such as a Word document?
    • If created via import, did you use Microsoft Excel to prepare your CSV?
I ask the upgrade question because sometimes key steps are skipped in the upgrade process, meaning that the internal database schema does not match the actual database being loaded, which can lead to strange outcomes with similar error messages to those I saw. In most cases, the missed step is that the database is not dropped and then recreated before the sqldump is loaded (step 4 in this section of the 2.6 upgrade documentation). If you think this is the case, it's generally best to repeat the upgrade process and make sure you don't miss these key steps. See for example the suggestions in this thread: 
Regarding the questions as to how the record was created, I noticed that other descriptions had no issue exporting as EAD, suggesting that there's something unexpected in the metadata of this record set causing problems. The most common of these is non-UTF-8 characters that causes the export process to fail - a common issue when text is sourced from Microsoft products, which typically use their own custom character encoding instead of the de facto web standard of UTF-8, which AtoM expects. 

In the biographical history of the related authority record for example, I can see what appear to be Microsoft's custom "curly quotes" that slant in a particular direction around the text. If you copy this character into the navigation bar of a separate browser tab and then manually enter a double quote character next to it, you can see the difference. It's possible something like this is making the export break. For more information, see: 
There's also more specific information on this in the 2.7 documentation, as the 2.7 release will include a new option to validate a CSV prior to or during import and check for common errors. On UTF-8 issues, see: 
We often recommend that AtoM users consider downloading LibreOffice Calc as an open source alternative to Microsoft Excel, as it defaults to UTF-8 and provides options to check and set the character encoding, separators, and other elements before opening any CSV. 

As an aside, I doubt this is the cause of the error, but it may lead to related performance issues on large operations: I noticed that this particular authority record, the Catholic Women's League (CWL), is manually linked as the creator in many different levels of the same fonds (Catholic Women's League - East Anglia Branch). AtoM has an inheritance system in place for both creators and repository names, meaning that if the creator is the same in a child-level description as its parent, then AtoM will automatically inherit the creator name at the child level, and you don't need to manually enter the creator there. In fact, doing so means there are many more unnecessary relationships in the database that can cause timeouts when attempting long running operations - including exports. The inheritance system is also meant to align with the ICA's general principles of description (namely, add information at the highest relevant level, and do not repeat information unnecessarily at lower levels) - while you can definitely add a different creator name at lower levels where needed (i.e. when the creator is actually different), if the creator is the same at lower levels then it's generally better to leave it blank during record creation - the inheritance will include the creator name at lower levels in the view pages of the related descriptions. 

Fortunately, there's a command-line task that you can run that will automatically check parent descriptions and remove any unnecessary manual links to the same creator in child descriptions when found. See: 
I would try running this task, and then manually fixing the quotation marks used in the authority record History field of the CWL, and see if that has any effect on the export. Check the archival unit itself for any other instances of potential non-UTF-8 characters as well. 

Finally, it's also possible that there's some data corruption that is causing the problem. A good first step is to run some common command-line maintenance tasks to ensure that the nested set is properly built, all records have slugs, the application cache is cleared, and the search index is up to date. See: 
You can also run the following query to check for other forms of data corruption - there are some suggested remediation steps on the same page, depending on what you find: 

If none of the above helps to resolve the issue, then hopefully the additional information you provide about your installation and archival unit in question will allow us to provide further suggestions. Let us know what you find! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
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 ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/c85e0c90-727e-4b2a-af90-17f3c1d85336n%40googlegroups.com.

shiva naik

unread,
Mar 8, 2022, 10:31:48 AM3/8/22
to AtoM Users
Hi Dan,

Thanks for the response

The version of Atom is 2.6.4 and it was upgraded last year in May 2021.

it's not just the CWL jobs failing, it's random and even the other jobs fail or freeze at running states. we get 500 errors for the jobs page while this happens and the only way to get it working is to force clear the jobs via command. 

I will try to run the maintenance task mentioned to see if that fixes the issues
Any other advice would be highly appreciated to get into the root cause of the issue

Many thanks
Shivaji Naik

Dan Gillean

unread,
Mar 9, 2022, 8:58:24 AM3/9/22
to ICA-AtoM Users
Hi Shiva, 

Thanks for this. It would still be helpful to know the full version number listed in the settings, to confirm the second value listed  - the schema migration. For a 2.6.4 release, the full version *should* be: 2.6.4 - 184. 

If that second number is lower than v184, then this may mean that a schema migration was missed during the upgrade process - which can happen if the upgrade-sql task is forgotten during upgrade. Let me know if this is the case. 

Otherwise, as previously noted, in addition to running the maintenance tasks I would also suggest checking for any data corruption that might be causing so many issues. See: 
Also as previously suggested, I do strongly recommend you run the unlink creators task if you haven't already: 
Let us know how it goes after running all the common maintenance tasks and checking these other elements!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/67e24051-11f3-4a7d-905a-d02ecfb79c29n%40googlegroups.com.

shiva naik

unread,
Mar 9, 2022, 1:47:10 PM3/9/22
to AtoM Users
Hi Dan,

Thanks for the quick response, the full version seems to be 2.6.4 - 175.

I don't recall any steps missing from the upgrade doc and the ATOM was working fine for the last 9 months.

How do I upgrade the schema now to v184 and what is the impact of this upgrade on the server?

Many thanks,
Shiva Naik

Dan Gillean

unread,
Mar 9, 2022, 3:40:20 PM3/9/22
to ICA-AtoM Users
Hi Shiva, 

It can take a while for the effects of missing schema migrations to become apparent, so it's entirely possible the issue has been present but lurking for a while. 

I would recommend that you try following the upgrade documentation from Step 2 of this section, with one change: 
After you have made a local database backup (i.e. the sqldump), try purging the contents of your site before dropping and then recreating the database, reloading the sqldump, and then running the upgrade task. The purge task syntax looks like: 
Note that the task will prompt you for a new site title and admin user credentials after the purge is complete - don't worry about what you enter here, since they will be overwritten once you drop/recreate the database and load your backed up data. So, rough summary of steps:
  • Make a sqldump in a secure location
  • Run the tools:purge task
  • Drop and recreate the database
  • Load your sqldump
  • Run the tools:upgrade task
  • Run the rest of the maintenance tasks lister later on the upgrading page (rebuild search index, clear cache, restart PHP-FPM, etc)
After that, check the full version number again (there's also a command-line task to do this, using php symfony tools:get-version), and test to see if the errors persist. 

If so, then following the recommendations to check for data corruption would be my suggested next step, and let us know what you find. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3de76032-cbd0-4fa8-bae0-be2caf3c341an%40googlegroups.com.

shiva naik

unread,
Mar 10, 2022, 2:56:43 PM3/10/22
to AtoM Users
Hi Dan,

As advised I have followed all the tasks but I am getting an attached error? stating base table already exists.

  • Make a sqldump in a secure location
  • Run the tools:purge task
  • Drop and recreate the database
  • Load your sqldump
  • Run the tools:upgrade task
Many thanks,
Shiva Naik
sqltask upgrade.jpg

Dan Gillean

unread,
Mar 11, 2022, 10:33:57 AM3/11/22
to ICA-AtoM Users
Hi Shiva, 

This is a tough situation that may be difficult to resolve. 

I've found some similar posts in the forum - in some cases, repeating the drop/create database step, then loading the sqldump again and trying the upgrade task once more worked. That would be my first suggestion. 

If that doesn't work, then things will be more complicated. First, I'd suggest making a duplicate of your database dump, so if something goes wrong, we still have the current version. 

I found the following issue ticket related to this: 
From what I can tell, migration 176 attempts to rename the function table to function_object. See: 
I talked to the developer who worked on issue #13365, and his best theory at this moment is that your table has already been renamed to function_object. This could be because part of migration 176 was run during your last upgrade attempt, but then aborted before finishing the rest of the upgrades - it's hard to tell with the information we have. 

One thing you could try is manually skipping that specific migration, to see if it allows you to bypass the error. You can try doing this by updating the current schema version number, so when the upgrade task runs, it starts from migration 177. He suggested the following SQL query - run it after you've loaded in your sqldump, but before running the upgrade task: 
  • update setting_i18n set value='176' where id in (select id from setting where name='version');
Like I said, there is a fair bit of guesswork here, which is why I recommend keeping a separate backup in case this does not have the intended effect. 

Let us know if that helps! 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3a73fb5b-a5c7-480c-924d-29156dd30c98n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages