We here at ISU have started to use the EAD Archive export regularly. We've found a major problem with the subject terms being incorrect when exporting all. This is happening with both of our installations of Archon. Each XML file in the exported ZIP file has the subject terms of the previous XML file and the correct terms. In other words the zip/xml tree looks like this:

1. zip:
   • a.xml
     • subject terms
       • term A
       • term B
   • b.xml
     • subject terms
       • term A
       • term B
       • term C
   • c.xml
     • subject terms
       • term A
       • term B
       • term C
       • term D

Steps to reproduce:

1. Select Export -> EAD Archive
2. Click Launch
3. Select any Repository(leave the classification on (Select One)
4. Click Export

I was able to fix it(with a sledgehammer) via adding this on line 503 in packages/collections/templates/ead/collection.inc.php
$arrEADSubjects = null;

So that section would read like this:
`

  <?php
           if (!empty($objCollection->Subjects)) {
              $arrEADSubjects = null;
              foreach ($objCollection->Subjects as $objSubject) {
                 $arrTraversal = $_ARCHON->traverseSubject($objSubject->ID);
                 $objParent = reset($arrTraversal);

                 $arrEADSubjects[$objParent->SubjectType->ID][$objSubject->ID] = $objSubject->toString(LINK_NONE, true, ' -- ');
              }
           }

`
I'm not sure what other repercussions this fix will introduce though as I haven't done any testing other than the EAD export.

We here at Illinois State have clone off our production Archon installations for testing the new code and have run into an issue with confirmation pop up winodows. They come up blank in Chrome or don't come up at all in Firefox and Internet Explorer. I'm not sure why yet. This is installed on RHEL7 running Apache 2.4.6 and php 5.6.30

http://my.ilstu.edu/~tpwals1/Archon.png

Has anyone else run into this?
-Tim Walsh.

I ran into this troubleshooting an Archon instance --

While accessing the detailed view of a collection, the app became completely unresponsive, with MySQL taking 100% of the CPU. A restart of the mysqld service was necessary to get the site functioning again.

The route that caused the database hang looked like this: archon-instance.com/index.php?p=collections/findingaid&id=249&q=video

I turned on the MySQL slow query log, and the following query showed up in the log, taking around 20 seconds per run. It seems to run forever:

SELECT ID,CollectionContentID FROM tblDigitalLibrary_DigitalContent WHERE CollectionContentID IN (SELECT CollectionContentID FROM tblDigitalLibrary_DigitalContent WHERE CollectionID = 249 AND CollectionContentID IN (1435) AND Browsable = 1 GROUP BY CollectionContentID HAVING COUNT(1) = 1);

Googling the query, I found this old thread on a discussion forum: http://forums.archon.org/viewtopic.php?f=5&t=960&start=15

Near the bottom of the thread, there was a patch suggested by user gordieschmitt for /packages/collections/lib/collection.inc.php:634, replacing:

$query = "SELECT ID,CollectionContentID FROM tblDigitalLibrary_DigitalContent WHERE CollectionContentID IN (SELECT CollectionContentID FROM tblDigitalLibrary_DigitalContent WHERE CollectionID = $this->ID AND CollectionContentID IN (" . implode(",", $contentKeys) . ") $browsable GROUP BY CollectionContentID HAVING COUNT(1) = 1)";

with

$query = "SELECT dd.ID,dd.CollectionContentID FROM tblDigitalLibrary_DigitalContent dd, (SELECT CollectionContentID FROM tblDigitalLibrary_DigitalContent WHERE CollectionID = $this->ID AND CollectionContentID IN (" . implode(",", $contentKeys) . ") $browsable GROUP BY CollectionContentID HAVING COUNT(1) = 1) a where dd.CollectionContentID = a.CollectionContentID";

I tried this patch, and it seems to resolve the issue in this case. This patch might be a good candidate for a future version.

On https://github.com/archonproject/archon/blob/master/packages/core/templates/default/enum-list.inc.php#L117 it lists levelcontainers, however there is no code for this output.

Archon substitutes unescaped query strings into HTML at various places, making it vulnerable to cross-site scripting attacks. We found out through https://www.openbugbounty.org/incidents/202333/, which, if hope to have fixed the following, though a fgrep '\"$' -r * --include \*.php suggests there may be more cases.

--- packages/core/pub/contact.php       2017-02-23 18:00:19.289374542 +0100
+++ packages/core/pub/contact.php.orig  2014-01-17 21:24:06.000000000 +0100
@@ -67,7 +67,7 @@
 
     $in_referer = $_REQUEST['referer'] ? $_REQUEST['referer'] : urlencode($_REQUEST['HTTP_REFERER']);
 
-    $repositoryid = $_REQUEST['repositoryid'] ? int($_REQUEST['repositoryid']) : 0;
+    $repositoryid = $_REQUEST['repositoryid'] ? $_REQUEST['repositoryid'] : 0;
 
 
 
@@ -111,8 +111,8 @@
 
        $form = "<input type=\"hidden\" name=\"f\" value=\"sendemail\" />\n";
        $form .= "<input type=\"hidden\" name=\"p\" value=\"core/contact\" />\n";
-       $form .= "<input type=\"hidden\" name=\"referer\" value=\"".htmlspecialchars($in_referer)."\" />\n";
-       $form .= "<input type=\"hidden\" name=\"query_string\" value=\"".htmlspecialchars($query_string)."\" />\n";
+       $form .= "<input type=\"hidden\" name=\"referer\" value=\"$in_referer\" />\n";
+       $form .= "<input type=\"hidden\" name=\"query_string\" value=\"$query_string\" />\n";
        $form .= "<input type=\"hidden\" name=\"RepositoryID\" value=\"$repositoryid\" />\n";
 
        $strRequiredMarker = "<span style=\"color:red\">*</span>";

Now that PHP5.6 and prior is deprecated, has anyone done any work to upgrade the code to be PHP7 compatible? I've done just the barest testing and see that 3.21 doesn't work on PHP 7.1.22. As we have no plans to upgrade to archivespace or any other package right now I'll need to update the code, but would like to coordinate this work if anyone else is doing the same.

-Tim Walsh
Illinois State University.

It appears that when creating cache entries for the public finding aids multiple entries for a collection and rootcontent id can be created, but only one is used. This is on an Archon instance using Microsoft SQL Server.

You can verify by finding a large collection that doesn't properly load...then compare the speeds of...

query to get public that was causing issues

SELECT  Dirty,FindingAidText 
FROM webuser.tblCollections_FindingAidCache 
WHERE CollectionID = <collection_id> AND TemplateSet = <template_name>  AND ReadPermissions = 0 AND RootContentID = 0

query to get staff view that loads fine

SELECT  Dirty,FindingAidText 
FROM webuser.tblCollections_FindingAidCache 
WHERE CollectionID = <collection_id> AND TemplateSet = <template_name> AND ReadPermissions = 1 AND RootContentID = 0

First query was returning something like 19 results and taking the first one.

There's a soon-to-be coming pull request that fixes the symptom of this issue by doing a 'TOP 1' w/ an ordering by id descending, but there's an underlying issue that's causing more data than necessary to be stored.

Guessing the issues is with the write part of the findingaidcache.php file.

Discovered with troubleshooting w/ @leonelramirez and @graykr.

Admin setting is enabled but a visit to ?p=collections/eadlist returns

domain... is currently unable to handle this request.
HTTP ERROR 500

in chrome.

doesn't seem to matter if using my customized or default theme. We do have a handful of monkey patches /pub directory so hard for me to say if this is me, or a wider problem. Looking to see if anyone else can reproduce. On 3.21 rev3

After updating our mySQL server to version 5.7, we noticed that searches within the public Archon interface took a long time to complete. Most searches took around 6 minutes to complete, when the same search on an older version of mySQL was almost instantaneous.

Research led me to suspect the slowness was caused by how 5.7 now handles derived tables, and I was able to isolate a query in /packages/collections/lib/core/archon.inc.php as the one responsible for the slow-down. Slightly different versions of this query appear 4 times in this file (lines 1848, 2225, 2601, 3005).

A fix that worked for me was including the DISTINCT command with the internal SELECT for each query. E.G. at line 2225, I replaced:
$query = "SELECT tblCollections_Content.*, tblCollections_Collections.ClassificationID as ClassificationID FROM tblCollections_Content JOIN tblCollections_Collections ON tblCollections_Collections.ID = tblCollections_Content.CollectionID JOIN tblCollections_LevelContainers ON tblCollections_LevelContainers.ID = tblCollections_Content.LevelContainerID LEFT JOIN (SELECT ContentID FROM tblCollections_UserFields WHERE $userfieldquery) AS tblCollections_UserFields ON tblCollections_UserFields.ContentID = tblCollections_Content.ID WHERE ($textquery OR NOT (tblCollections_UserFields.ContentID IS NULL)) $subquery $enabledquery ORDER BY tblCollections_Content.SortOrder";

with:
$query = "SELECT tblCollections_Content.*, tblCollections_Collections.ClassificationID as ClassificationID FROM tblCollections_Content JOIN tblCollections_Collections ON tblCollections_Collections.ID = tblCollections_Content.CollectionID JOIN tblCollections_LevelContainers ON tblCollections_LevelContainers.ID = tblCollections_Content.LevelContainerID LEFT JOIN (SELECT DISTINCT ContentID FROM tblCollections_UserFields WHERE $userfieldquery) AS tblCollections_UserFields ON tblCollections_UserFields.ContentID = tblCollections_Content.ID WHERE ($textquery OR NOT (tblCollections_UserFields.ContentID IS NULL)) $subquery $enabledquery ORDER BY tblCollections_Content.SortOrder";

This has resolved my search speed issues, and I haven't discovered any knock-on consequences.

I have NOT been able to test backward compatibility with older versions of mySQL, and so haven't submitted it as a pull request yet.

I'm trying to move a working installation of Archon 3.21 rev. 1 to a new server. It's not working, and I'm wondering if it's due to the new server running PHP 5.6? Does Archon work with PHP 5.6?

Thanks,
Glenn

I'm trying to add french to the project , as I am new to programming can someone guide me to the right steps

Hello,

I came across the following error when attempting to upload an EAD file into an Archon test server. When I attempted to upload the file, the admin interface stuck at "Parsing file php..."

Upon further inspection of the error.log file, I came across the following entry.

PHP Fatal error:  Call to undefined function mb_detect_encoding() in /var/www/archon/htdocs/packages/collections/db/import-ead.inc.php on line 67, referer: http://<ip-address-here>/index.php?p=admin/core/database

I checked the import-ead.inc.php file, and I could in fact find no instance of the mb_detect_encoding function defined elsewhere within the file. I also performed a grep -R for mb_detect_encoding on the /var/www/archon/htdocs directory, and the only line that came back from this search is the previously-mentioned line import-ead.inc.php. The context for this function call is as follows:

foreach ($arrFiles as $Filename => $strXML)
      {
         echo("<br/><br/>\n");

         echo("Parsing file $Filename...<br/>\n");

         $currEncoding = mb_detect_encoding($strXML, 'UTF-8, ISO-8859-1');
         if ($currEncoding != 'UTF-8')
         {
            echo("File encoded in $currEncoding. Converting to UTF-8...<br/>\n");
            $strXML = encoding_convert_encoding($strXML, 'UTF-8', $currEncoding);

Below are my current version details:

Server: Ubuntu 16.04 LTS (minimal image from Canonical on AWS Marketplace)
Apache Version: Apache/2.4.18
MySQL Version: Ver 14.14 Distrib 5.7.31, for Linux (x86_64)
PHP Version: PHP 5.6.40-30

Archon Version: 3.21-rev. 3

Has anyone else experienced this issue and/or produced a local fix for this problem?