What Michelle is reporting on – omitting a quotation mark – is invalid EAD and so the outcome is expected behavior. It’s not specific to the fix in place, it’s specific to invalid EAD.

Please see Michelle’s last comment - I don’t think that issue is specific to this, but it’s possible you may be able to address it (and definitely should if it’s specific to this).

Tested. Appears to have passed if you do it correctly, though there’s a remaining bug where if you forget to close your quotation marks the title “ghosts”.

Successful outcome:

1. Created a test resource for this ticket (MLP-2025-0326)

2. Added a child archival object with mixed content, including part of the title wrapped in <title render=”italic”></title> tags.

3. Also added a grandchild archival object with ONLY content in <title render=”italic”></title> tags and no content outside of the tags. Also added a note with similar mixed content.

4. These all worked, and showed the appropriate portions in italics. Also tried underlines.

However, if you forget to close your quotation marks, anything in or after the title tag disappears from display once you save. You can’t click on it in either the SUI or PUI if the incorrent <title> tag is at the beginning, e.g. https://test.archivesspace.org/staff/resources/198/edit#tree::archival_object_46560. You can only see it if you KNOW the url and go directly to it.

How to replicate the unsuccessful outcome:

1. Create an archival object, using the title tag but forget to close the quotation marks, e.g. <title render="italic>Example</title> title with unclosed quotations at the beginning

2. Save the archival object.

3. The archival object saves, but the title disappears and you cannot click on it in either the SUI or PUI. If you navigate away you need to go directly to the exact URL to go back to it.

Including screenshots

Why are “title” tags being used here or anywhere in ArchivesSpace fields? Maybe that’s an EAD Tags thing? (I just searched it up and looks like it’s ok because it’s an EAD thing so EAD is fighting browsers here _

I think the problem here is all browsers assume the title tag is only ever THE TITLE of the page TAG. Like browsers assume this is the TITLE of the actual page and they say “here’s a title tag in the middle of the page which is wrong so I’m going to hide that” which makes sense since in HTML tagging that’s how it should be.

It looks like the title field can have “display: block” set and that brings back the hidden title tag, but it seems wrong-ish to tag things title when it’s not standard html and the browsers are just doing the right thing? Maybe the title box used to be “display: block” and now it’s “display: inline” (or I think it’s inline now).

But going back and fixing all ArchivesSpace titles to make sure there’s not any title tags seems less than ideal.

To me this is a pretty substantial bug, since it prevents users from viewing data (it’s a deal breaker for upgrading for us). I also wonder if its possible to have better error handling where something like this doesn’t fail silently like this. It’s a lot easier to notice problems like this when it generates an error message like with the missing translations in . No idea as to the feasibility of this though.