Digital objects gone after upgrade

134 views
Skip to first unread message

mpw...@ualberta.ca

unread,
Jan 20, 2020, 2:37:20 PM1/20/20
to AtoM Users
Hi all,

Ubuntu 18.04, fully updated 2020-01-15
NGinx 1.14.0
PHP 7.2.24
MySQL 5.7.28
ElasticSearch 5.7.16
OpenJDK 11.0.5
AtoM 2.5.3

This AtoM is upgraded from 2.4.1 on Ubuntu 16, which was running on a separate server; its 100G data partition containing the AtoM site was detached from U16 and reattached to the U18 server, where the upgrade to 2.5.3 was performed.

We did the usual:

php symfony tools:upgrade-sql
php symfony search:populate
php symfony digitalobject:regen-derivatives
php symfony cc
reboot

The problem that we are experiencing is that we can't access any digital objects associated with information objects (aka archival descriptions) in the database. There are images, textual, and audio files attached to some of the descriptions, and they are now missing (the actual FILES are there).

E.g., on the main page, if oyu click on Digital objects in the Browse by menu on the left, you see different descriptions that have digital objects attached to them. Once you click on the actual digital object, you'll get a 404 error.

Thanks for any help.

Dan Gillean

unread,
Jan 21, 2020, 11:39:47 AM1/21/20
to ICA-AtoM Users
Hi Michael, 

A couple suggestions to start with: 

1) Make sure that you have correctly set your Base URL in Admin > Settings > Site information. The base URL is used to construct export URLs, so it's possible AtoM can't serve the correct link if you haven't updated your base URL. 

2) I would suggest performing a CSV export of a couple descriptions with digital objects, and then taking a look at the value included in the digitalObjectURI column, to see if you can determine what about the path is incorrect. Does the base URL look right? If you ignore the base URL, can you use the command-line to navigate to the supplied path in the uploads directory and find the master object? Hopefully this will give you some insights into what's going on. 

3) Don't forget to check your Nginx configuration block - it references the location of the uploads directory and sets access rules. If you've configured your uploads differently, you may need to make adjustments to this file. 

4) It's possible this is a permissions issue. I would suggest you make sure that the www-data user can access your uploads directory. Normally when we set the permissions in AtoM, we use the following: 
  • sudo chown -R www-data:www-data /usr/share/nginx/atom
If your uploads directory is not located beneath the root AtoM installation directory, you may need to apply the same permissions to the directory in its current location. 

Hopefully one of those ideas will point you in the right direction! 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/a07f99c3-5fa3-4682-8d23-1a63e4f8ca24%40googlegroups.com.

Maryna Chernyavska

unread,
Feb 3, 2020, 6:05:45 PM2/3/20
to AtoM Users
Hi Dan,

Thanks for your suggestions. We checked everything as you recommended, and everythings seems fine: the base URL, the digitalObjectURI column, we ccould use command line to navigate to the supplied path in the uploads directory and find the master object; checked our Nginx and permissions. Everything seems fine, but no digital objects can be accessed :( Any other ideas where we could look?

Thanks,
Maryna

Maryna Chernyavska, MA, MLIS
Folklore Archivist
Bohdan Medwidsky Ukrainian Folklore Archives
Kule Folklore Centre
University of Alberta
To unsubscribe from this group and stop receiving emails from it, send an email to ica-ato...@googlegroups.com.

Dan Gillean

unread,
Feb 6, 2020, 10:57:24 AM2/6/20
to ICA-AtoM Users
Hi Maryna and Michael, 

Interesting. I will consult our team for further suggestions, but a couple questions to clarify what you are seeing: 
  • So, the reference display image is not showing on view pages, AND trying to click through to the master DO is also leading to a 404 - is that correct?
  • Is the he uploads directory still in the right place, just below the root AtoM directory? Can you confirm that, in copying your uploads directory over to the new server, you didn't accidentally create an extra directory level in there (for example /usr/share/nginx/atom/uploads/uploads/... or /usr/share/nginx/atom/uploads/r/uploads/... or /r/r/..., etc)?
  • Can you try exporting some records with digital objects attached? If you take the URI included in the exported CSV and add it back to the browser when logged into AtoM, does it take you to the master digital object? If not, does the base URL appear correct on the export URI at least? Can you see any other obvious errors in the paths provided?
With a bit more information, I will see if our team has other ideas. 

Cheers, 

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

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/5bd3e15d-f442-460c-9643-15685fca70c0%40googlegroups.com.

Michael Ward

unread,
Feb 6, 2020, 12:02:08 PM2/6/20
to ica-ato...@googlegroups.com
Hi Dan,

> the reference display image

I will let Maryna answer that.

> uploads directory still in the right place

Yes, we checked all that. The files are where they should be, and
where AtoM says they should be. Atom says "Original Digital object not
accessible", but when I check the path, the object, e.g. a photo, it's
there, with world-readable permissions. But see below.

> try exporting some records

Another one for Maryna.

One other thing - this AtoM site started at about v2.1, and has worked
fine through upgrades to 2.5.3. In the logs I now see it's trying to
find files at:

/usr/share/nginx/atom/uploads/r/

... but that's not where the installation is. It has NEVER been in
/usr/share/nginx/atom, it has ALWAYS been in /var/sites/atom .

So why is it looking for files in a place where they've never been? Is
there an internal setting we can change?
> You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAC1FhZ%2BMczWoJLxvtYB-T_065jA47FjRQjn%2BoKTC2M6Sw6E3Hg%40mail.gmail.com.



--
Michael Ward
Arts Resource Centre (ARC)
450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
780-492-5278

Dan Gillean

unread,
Feb 6, 2020, 12:13:52 PM2/6/20
to ICA-AtoM Users
Hi Michael, 

It sounds like we're getting closer to the root of the issue here! 

I would take a look at your Nginx configuration block and make sure the paths referenced there match where you've actually installed the site. In our default block (which we suggest users typically create at /etc/nginx/sites-available/atom.comf) there are several references to the default installation location that you might need to modify. See: 
Remember to restart/reload Nginx if you make any changes here. You might want to restart php-fpm for good measure as well. 

This also means you'd need to run the permissions differently - my guess is that your command should look like this: 
  • sudo chown -R www-data:www-data /var/sites/atom
Let us know what you find!
Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

Michael Ward

unread,
Feb 6, 2020, 12:27:39 PM2/6/20
to ica-ato...@googlegroups.com
Hi Dan, thanks for the quick response.

Indeed, although the site root was properly defined, there was an
instance of /usr/share/nginx further down in the config file - thanks
for pointing that out! Digital objects now appear to be visible, but
I'll have to get Maryna (not in today) to check.

This still has not fixed everything - the main site banner is still
broken, although it's images/banner.png, exactly what and where it
should be and always has been.

Thanks again. We'll be in touch soon.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BMsaVa7Ofx833XLwHkk1HojsKyeTFBqaoKBoKeXy5diQ%40mail.gmail.com.

Michael Ward

unread,
Feb 6, 2020, 12:30:37 PM2/6/20
to ica-ato...@googlegroups.com
Hi Dan,

Regarding the banner, this appears in the logs:

FastCGI sent in stderr: "PHP message: Empty module and/or action after
parsing the URL "/images/banner.png" (/)"

Mean anything to you?

Dan Gillean

unread,
Feb 6, 2020, 1:42:53 PM2/6/20
to ICA-AtoM Users
Hi Michael, 

Is this banner image part of a custom theme, or is it something you have added to use in a static page, such as your homepage? Or is it being used somewhere else?

If it's on a static page (including the homepage), have you entered the full path to the image in the static page HTML, or a relative path? Additionally, does the path in your HTML begin with a slash?
  1. <img src="images/banner.png" />
  2. <img src="/images/banner.png" />
  3. <img src="/var/share/atom/images/banner.png" />
Based on a couple quick tests, I got the best results following option 1 of the examples above - it may be because of how some of the directories are symlinked in our Vagrant box, but in my VM I couldn't get 3 to work. And as for option 2 - if you enter a relative URL and start with a slash, then AtoM may be throwing the error because it's already assuming a slash from the relative current location, so it's actually searching for the image at //images/banner.png

Another possibility for investigation:

Anything found in the images directory *should* be publicly accessible on the web if the permissions are set correctly - so, are you able to enter http://[your site base URL]/images/banner.png into your web browser and see the image? If no, then you may need to check the permissions of the items in this directory. 

You could also try clearing all caches and see if it helps - with a typical installation using PHP 7.2, this would be (run from the root AtoM installation directory):
  • php symfony cc
  • sudo systemctl restart memcached
  • sudo systemctl restart php7.2-fpm
Let me know if any of the above helps to troubleshoot this! 

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

Michael Ward

unread,
Feb 6, 2020, 3:53:47 PM2/6/20
to ica-ato...@googlegroups.com
Hi Dan,

This is 100% STUPID.

I cleared cache etc, I even rebooted. When I went to the site, BANG
there is the banner, YAY!

Then I poked around a bit, returned to the home page . . . and the
banner is gone.

Huh?!?

On another workstation, I went to the site, there's the banner, good;
hit refresh, the banner disappears.

I can go directly to the banner via URL, and I SEE it, as in:

somesite.com/images/banner.png

I tried moving the banner, renamed it, I tried using other pix in
images/ - none of them appear (as the banner).

What is going on here?
> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BZZTb8hUkHuJOZWJDY_zT51xcE2k2oHLJ%2B5Fw5k4RPoQ%40mail.gmail.com.

Dan Gillean

unread,
Feb 6, 2020, 4:38:53 PM2/6/20
to ICA-AtoM Users
Hi Michael, 

That is very strange! Just to rule it out - after clearing the application caches again, can I suggest that you go into your browser settings and fully clear the browser cache as well? My initial suspicion is that there is a cached version of the site in the browser history that's being served up instead of a fresh pull from the source URL. This doesn't fully explain the issue reappearing on a separate workstation (unless you've previously visited your site there as well), but any time I've heard of similar reports in the past, it has typically come down to some kind of caching issue - often the browser. 

I'll add that, depending on how (and as what user) you moved and renamed your files in the images directory, you could have inadvertently changed the filesystem permissions on them, so that might be something to check as well?

Anyway, start with that - I'll see if anyone here has other suggestions as well. 

Cheers, 

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

Michael Ward

unread,
Feb 7, 2020, 12:05:11 PM2/7/20
to ica-ato...@googlegroups.com
For the record, I asked some others to look at the site; I can 100%
guarantee they have never visited it before. The banner disappeared on
them too, after clicking around, so it cannot be local (browser)
cache, it must be something on the server.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2B0N1JZ9jyE9bFMTBRsyv9khriUEBTme9w7SdABcwd36w%40mail.gmail.com.

Dan Gillean

unread,
Feb 7, 2020, 1:30:29 PM2/7/20
to ICA-AtoM Users
Hi Michael, 

One of developers suspects there may still be something misconfigured in the Nginx config file, so you might want to review that one more time. Additionally, when the image fails to load, if it is a server side issue then there should be something in the Nginx error logs - can you check those and see if there is any relevant error message to share?

One more thing to check - if you use the "Inspect" tools in your browser to inspect the failed image it should show you the relative path being used to attempt to fetch the banner. Does this match your expectations? Do you see any issues there?

Finally, please do remember my earlier suggestion to verify that you didn't inadvertently change the file permissions when copying/editing the banner earlier. I would also recommend that you try clearing the application caches one more time, and do any browser-based testing in an Incognito or Private browser window, where the browser cache is typically disabled by default - just so we can fully rule it out as an interfering factor. 

Cheers, 

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

Michael Ward

unread,
Feb 10, 2020, 3:38:54 PM2/10/20
to ica-ato...@googlegroups.com
Hi Dan,

Good call - yes, there was an instance of /var/lib/atom further down
in the config file - fixed, and many thanks for that.

All paths and permissions are fine. The path to the banner is exactly
as it should be in Firefox Inspector or if I look at the page source,
but I did notice something else.

If the URL is just https://myatomsite.com, the banner is there.

The banner disappears if the URL includes index.php/, as in

https://myatomsite.com/index.php/

This appears in error.log:

42058 FastCGI sent in stderr: "PHP message: Empty module and/or action
after parsing the URL "/images/banner1.png" (/)" while reading
response header from upstream
> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKABqF%2B6WFitFiUu1aj0o8R%3DKPCh%3DwnsUj4gk4pYDD0Mg%40mail.gmail.com.

Michael Ward

unread,
Feb 10, 2020, 3:47:17 PM2/10/20
to ica-ato...@googlegroups.com
P.S. the banner is actually called banner.png OR banner1.png, and
that's the path.

Kind of makes sense (maybe?) that the banner disappears, since its
path is not /index.php/images/banner1.png .

Dan Gillean

unread,
Feb 10, 2020, 5:09:43 PM2/10/20
to ICA-AtoM Users
Hi Michael, 

Ah, ok - an interesting side effect of the way Symfony (the PHP framework used) builds the URLs. 

Fortunately, this came up in the forum recently, and there is a way to make it so that /index.php/ is not inserted into the URLs. See: 
Keep in mind that this assumes you are using the default Nginx configuration. I'd say try it, but it may require a bit more figuring since you've made some changes. However, if it works, I think it should avoid the issue of a user landing on the homepage with /index.php/ in the URL and not seeing the banner. 

Also, are you using the full path in the URL to the banner, or a relative one? I would have expected that, with a relative path (e.g. just src="images/banner.png") it should show up regardless, but perhaps not. 

Cheers, 

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

Michael Ward

unread,
Feb 10, 2020, 5:25:23 PM2/10/20
to ica-ato...@googlegroups.com
Hi Dan,

It's not completely clear to me *which* line I'm to change to "true".

I guess it's in apps/qubit/config/settings.yml, the "no_script_name"
line (which is highlighted):

prod:
.settings:
no_script_name: false

Change that to "no_script_name: true"?

If yes, it makes no difference. Yes, I cleared cache, restart php7.2-fpm.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZJAoU47xOjg0gv6CxokM5ib2FzDzk9Ji_Wq%2BCV7-z2pTg%40mail.gmail.com.

Michael Ward

unread,
Feb 10, 2020, 5:27:29 PM2/10/20
to ica-ato...@googlegroups.com
Regarding the atom nginx file, the only customization is the path to
the atom install.

raddao...@gmail.com

unread,
Feb 11, 2020, 7:08:11 AM2/11/20
to AtoM Users
Hi Michael,

Just to be sure, did you make the "no_script_name" modification in "settings.yml.tmpl" or in "settings.yml"? Also, where are you adding the banner? On the homepage edit or in the AtoM code?

Bests,
Radda.
> >> > >> >> >> > >> >> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/5bd3e15d-f442-460c-9643-15685fca70c0%40googlegroups.com.
> >> > >> >> >> > >> >
> >> > >> >> >> > >> > --
> >> > >> >> >> > >> > You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> >> > >> >> >> > >> > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> >> > >> >> >> > >> > To unsubscribe from this group and all its topics, send an email to ica-ato...@googlegroups.com.
> >> > >> >> >> > >> > To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BMczWoJLxvtYB-T_065jA47FjRQjn%2BoKTC2M6Sw6E3Hg%40mail.gmail.com.
> >> > >> >> >> > >>
> >> > >> >> >> > >>
> >> > >> >> >> > >>
> >> > >> >> >> > >> --
> >> > >> >> >> > >> Michael Ward
> >> > >> >> >> > >> Arts Resource Centre (ARC)
> >> > >> >> >> > >> 450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
> >> > >> >> >> > >> 780-492-5278
> >> > >> >> >> > >>
> >> > >> >> >> > >> --
> >> > >> >> >> > >> 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-ato...@googlegroups.com.
> >> > >> >> >> > >> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAAUb%2B1qzwsc04ZpXa%2BfvR1-5trnSnsMBUbf6V9qg1%2BZ9b_4KTg%40mail.gmail.com.
> >> > >> >> >> > >
> >> > >> >> >> > > --
> >> > >> >> >> > > You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> >> > >> >> >> > > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> >> > >> >> >> > > To unsubscribe from this group and all its topics, send an email to ica-ato...@googlegroups.com.
> >> > >> >> >> > > To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BMsaVa7Ofx833XLwHkk1HojsKyeTFBqaoKBoKeXy5diQ%40mail.gmail.com.
> >> > >> >> >> >
> >> > >> >> >> >
> >> > >> >> >> >
> >> > >> >> >> > --
> >> > >> >> >> > Michael Ward
> >> > >> >> >> > Arts Resource Centre (ARC)
> >> > >> >> >> > 450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
> >> > >> >> >> > 780-492-5278
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >> --
> >> > >> >> >> Michael Ward
> >> > >> >> >> Arts Resource Centre (ARC)
> >> > >> >> >> 450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
> >> > >> >> >> 780-492-5278
> >> > >> >> >>
> >> > >> >> >> --
> >> > >> >> >> 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-ato...@googlegroups.com.
> >> > >> >> >> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAAUb%2B1of7jY1DnAXGUuEGJVZ%3DrAnAV0guya2a%3Du64Gk36RXNFQ%40mail.gmail.com.
> >> > >> >> >
> >> > >> >> > --
> >> > >> >> > You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> >> > >> >> > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> >> > >> >> > To unsubscribe from this group and all its topics, send an email to ica-ato...@googlegroups.com.
> >> > >> >> > To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BZZTb8hUkHuJOZWJDY_zT51xcE2k2oHLJ%2B5Fw5k4RPoQ%40mail.gmail.com.
> >> > >> >>
> >> > >> >>
> >> > >> >>
> >> > >> >> --
> >> > >> >> Michael Ward
> >> > >> >> Arts Resource Centre (ARC)
> >> > >> >> 450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
> >> > >> >> 780-492-5278
> >> > >> >>
> >> > >> >> --
> >> > >> >> 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-ato...@googlegroups.com.
> >> > >> >> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAAUb%2B1r8xyr6nG9AZ%2BGfKvrB%2BFJ65ybYGXgP9xVSGNZ7jLNzZw%40mail.gmail.com.
> >> > >> >
> >> > >> > --
> >> > >> > You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> >> > >> > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> >> > >> > To unsubscribe from this group and all its topics, send an email to ica-ato...@googlegroups.com.
> >> > >> > To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2B0N1JZ9jyE9bFMTBRsyv9khriUEBTme9w7SdABcwd36w%40mail.gmail.com.
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Michael Ward
> >> > >> Arts Resource Centre (ARC)
> >> > >> 450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
> >> > >> 780-492-5278
> >> > >>
> >> > >> --
> >> > >> 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-ato...@googlegroups.com.
> >> > >> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAAUb%2B1qXT8gBgygaLm0v--4d579oqfiHmHaGqLX9ofb1wYQFFg%40mail.gmail.com.
> >> > >
> >> > > --
> >> > > You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> >> > > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> >> > > To unsubscribe from this group and all its topics, send an email to ica-ato...@googlegroups.com.
> >> > > To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKABqF%2B6WFitFiUu1aj0o8R%3DKPCh%3DwnsUj4gk4pYDD0Mg%40mail.gmail.com.
> >> >
> >> >
> >> >
> >> > --
> >> > Michael Ward
> >> > Arts Resource Centre (ARC)
> >> > 450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
> >> > 780-492-5278
> >>
> >>
> >>
> >> --
> >> Michael Ward
> >> Arts Resource Centre (ARC)
> >> 450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6
> >> 780-492-5278
> >>
> >> --
> >> 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-ato...@googlegroups.com.
> >> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAAUb%2B1oZbNZ-r0jzonjTb505jkAKwQzX5nw8Mb7MATVDAGX4ag%40mail.gmail.com.
> >
> > --
> > You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> > To unsubscribe from this group and all its topics, send an email to ica-ato...@googlegroups.com.

raddao...@gmail.com

unread,
Feb 11, 2020, 7:26:45 AM2/11/20
to AtoM Users
Hi again,

I gave it a quick try locally with the logo and, from the homepage edit:

<img alt="AtoM logo" src="/images/logo.png">

Works for me with and without "index.php". If you're doing it from the source code you may want to check how it's done in the header (without the link part):

<?php echo image_tag('logo', array('alt' => 'AtoM') ?>

Best regards.

Michael Ward

unread,
Feb 11, 2020, 10:50:07 AM2/11/20
to ica-ato...@googlegroups.com
Hi Radda,

Thanks for the reply.

I edited settings.yml.

Banner is in the homepage edit - it works now, YAY; the leading / was missing.

However, the logo still doesn't work. Isn't it supposed to appear in
place of "atom" in the upper left corner? Adding the code snippet:

<img alt="AtoM logo" src="/images/logo.png">

...to the home page makes it appear in the middle of the page, below
the header (as I expected).

However, that is a minor matter. I don't think the client is overly
concerned about it.

Thanks for the assistance.
> --
> You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FdkVY-2Ptv8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/8c05954e-7a29-4140-aad3-7da949ab8736%40googlegroups.com.

Dan Gillean

unread,
Feb 11, 2020, 11:00:06 AM2/11/20
to ICA-AtoM Users
Hi Michael, 

In this thread, I walk through how to change the logo in the header for the base Dominion theme. There's also a lot of other useful information in there if you are considering further stylistic customizations, including suggestions on how to create a custom theme plugin. See: 
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/CAAUb%2B1oqUmyZbBKAb0sCEKddETUnx6sZ6-2iOf_Oz2nPeMwgyg%40mail.gmail.com.

Michael Ward

unread,
Feb 11, 2020, 11:27:06 AM2/11/20
to ica-ato...@googlegroups.com
Thanks Dan!

And thanks to everyone for all the help and suggestions, and patience.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZLXcjHq-qLdOPbenOZX%3DWR_4NJ16z7Lr4K724C3NOZAUA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages