404 when clicking on Reference copy or Thumbnail copy filename links

[Chris Selwyn]

Hi,

I am a new user of AtoM, using it to catalogue my family archives.

I have just started linking digital objects to my archive descriptions and I have found that the URLs generated for the links to the Reference and Thumbnail copies are not always correct. My AtoM installation is at the path "/atom" relative to my domain but the links to those copies that are generated on the digital object view page both start with "/uploads" rather than "/atom/uploads". The Master copy link is generated correctly and includes the full URL to the image object.

I have tried looking into the problem but I'm getting a little lost in unfamiliar PHP code but I think it is to do with the fact that the Master file link is generated using QubitObject::getDigitalObjectUrl() which has the following code at the end to generate the URL

  return $request->getUriPrefix()
            .$request->getRelativeUrlRoot()
            .$digitalObject->getFullPath();

Whereas the Reference and Thumbnail link generation simply use  $reference(/thumbnail)Copy->getFullPath() in the code file apps/qubit/modules/digitalobject/templates/_metadata.php.

Shouldn't the _metadata.php also concatenate $request->getUriPrefix() and $request->getRelativeUrlRoot() onto the front of the result of the $reference(/thumbnail)Copy->getFullPath()?

I have modified my copy of _metadata.php to do just that and it seems to work now.

Similar code appears in the _metadata.php in the arDominionB5Plugin code as well.  I'm not sure how or when that is used but I suspect that a similar fix may be needed there as well.

Chris Selwyn

[Dan Gillean]

Hi Chris, 

Have you checked to ensure that the Base URL is properly configured in Admin > Settings > Site information? I'm not sure if this will resolve the issue (we generally recommend using a subdomain instead) but it's worth a shot. If not, I will see if we can reproduce this issue and file a ticket if needed. 

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/c8b43bed-82f4-4688-bc66-a51d7c959423n%40googlegroups.com.

[Chris Selwyn]

Yes I have checked that it is set correctly. That setting appears to not be used when generating the URLs of the reference and thumbnail images. The fix that I have done seems to work.

        <?php $request = sfContext::getInstance()->getRequest(); ?>
        <div class="digital-object-metadata-body">
          <?php if ($showReferenceCopyFileName) { ?>
            <?php if ($canAccessReferenceCopy && $sf_user->isAuthenticated()) { ?>
              <?php echo render_show(__('Filename'), link_to(render_value_inline($referenceCopy->name), $request->getUriPrefix().$request->getRelativeUrlRoot().$referenceCopy->getFullPath(), ['target' => '_blank']), ['fieldLabel' => 'referenceCopyFileName']); ?>
            <?php } else { ?>
              <?php echo render_show(__('Filename'), render_value($referenceCopy->name), ['fieldLabel' => 'referenceCopyFileName']); ?>
            <?php } ?>
          <?php } ?>

and

        <div class="digital-object-metadata-body">
          <?php if ($showThumbnailCopyFileName) { ?>
            <?php if ($canAccessThumbnailCopy) { ?>
              <?php echo render_show(__('Filename'), link_to(render_value_inline($thumbnailCopy->name), $request->getUriPrefix().$request->getRelativeUrlRoot().$thumbnailCopy->getFullPath(), ['target' => '_blank']), ['fieldLabel' => 'thumbnailCopyFileName']); ?>
            <?php } else { ?>
              <?php echo render_show(__('Filename'), render_value($thumbnailCopy->name), ['fieldLabel' => 'thumbnailCopyFileName']); ?>
            <?php } ?>
          <?php } ?>

There may well be a better way of doing it.

Chris

[Chris Selwyn]

Sorry to come back to this one but I have just upgraded to AtoM 2.8 and I am still experiencing the problem that I described and provided a fix for last year.

In addition, AtoM 2.8 is wanting me to switch to the atDominionB5theme. But if I do then there I always get 404s on 3 files :-

• https://<my domain>/dist/js/vendor.bundle.1697f26639ee588df9ee.js
  
• https://<my domain>/dist/js/arDominionB5Plugin.bundle.0f4e03041937e8075d96.js
  
• https://<my domain>/dist/css/arDominionB5Plugin.bundle.33b8488ae3d60e127786.css
  

Unfortunately, as with the issue that I reported previously, my AtoM is installed at https://<my domain>/atom and not at the root of my domain.

So the URLs for the js and css resources do not get loaded.  They URLs should be 

• https://<my domain>/atom/dist/js/vendor.bundle.1697f26639ee588df9ee.js
  
• https://<my domain>/atom/dist/js/arDominionB5Plugin.bundle.0f4e03041937e8075d96.js
  
• https://<my domain>/atom/dist/css/arDominionB5Plugin.bundle.33b8488ae3d60e127786.css

I have spent some time looking into how those URLs get generated but I am not managing to work it out.

The URL of the site is set correctly in the Site Information settings to https://www.selwyn-family.me.uk/atom but that setting does not appear to be used when generating the URLs of the js and css resources.

I have reapplied my fix for the Reference and Thumbnail links in the digital objects page and that now works again but I cannot fathom how the css and js URLs are generated. 

Can you help?

Chris

[Dan Gillean]

Hi Chris, 

Thank you for re-reporting this issue, and I'm sorry to hear it continues to cause you problems, and indeed is even more complex with the new BS5 theme. I have alerted the Maintainers team to this thread, so hopefully they can review your feedback and proposed fix in advance of the next release. While I cannot promise if a solution will be included in the next release or not, I can point out that now that we have a dedicated team of Maintainers, releases are happening more frequently and consistently. 

In the meantime, I will try to get a developer familiar with the BS5 upgrade work to review this thread, and offer any insights about possible workarounds for you for the theme issues arising from your chosen domain. 

In the interim - while I do think that we should properly address these issues and support users defining their chosen domains however they see fit, have you considered switching to using a subdomain (e.g. archives.selwyn-family.me.uk or atom.selwyn-family.me.uk, etc), and adding a redirect from your old URL? While we wait to see this issue properly addressed, using a subdomain instead will bypass all these issues. 

Hopefully we will have more suggestions for you soon. 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/49e30b5e-e8a7-4e58-85ad-d33403d7741cn%40googlegroups.com.

[José Raddaoui]

Hi Chris,

You may need a similar fix to generate those URLs, they will be located in "plugins/arDominionB5Plugin/templates/_layout_start.php". As Dan suggested, I'd consider using a subdomain.

Best,

Radda.

[Chris Selwyn]

Thank-you very much for the hint. Once I knew where the code is that generates those URLs then the fix was easy.

I have edited the _layout_start.php as follows :-

```

    <?php $request = sfContext::getInstance()->getRequest(); ?>

    <?php echo "<script defer src=\"{$request->getRelativeUrlRoot()}/dist/js/vendor.bundle.1697f26639ee588df9ee.js\"></script>" ?>
    <?php echo "<script defer src=\"{$request->getRelativeUrlRoot()}/dist/js/arDominionB5Plugin.bundle.0f4e03041937e8075d96.js\"></script>" ?>
    <?php echo "<link href=\"{$request->getRelativeUrlRoot()}/dist/css/arDominionB5Plugin.bundle.33b8488ae3d60e127786.css\" rel=\"stylesheet\">" ?>

```
It appears to be working now. I wonder how many other places (as yet unfound) I will need to make a fix to in a similar fashion.

From those random Hex strings in the resource names, I'm guessing that this file is generated as part of the application build process. If that is the case then the code that generates the file will need changing.

As regards running AtoM in the root of a subdomain, my opinion is that if it is necessary to run it like that in order that the application works then it should be made a requirement rather just than a recommendation.

Thank-you for the hint.

Chris

[Melanie Kung]

Hi Chris,

We have started working on a fix for the access copies links issue you're facing but are having some issues replicating your exact issue. Do you have a public repo for your AtoM changes and configuration that we can take a look at? And if you could provide some details on how you've set up your routing for your AtoM site, that would be helpful to help debug your issue!

Bests,

Mel

[Melanie Kung]

Hi Chris,

After much discussion internally, we are marking this as a won't fix and closing the issue for now. As mentioned before, AtoM installations are recommended to be on its own domain/subdomain instead of a sub-folder, but it should be possible to have a workaround for this by configuring the web server appropriately. Feel free to re-open if there are still issues with the links with an appropriate AtoM and web server configuration.

Related Issue can be found here: https://github.com/artefactual/atom/issues/1744

Bests,

Melanie

[Chris Selwyn]

Melanie,

I'm sorry it has taken me so long to get back to you on this subject.

I must say that I am disappointed that you have decided to take this course of action. 

I cannot see a simple way to "configure the web server appropriately" in such a way that AtoM will just work. The problem is that, since AtoM returns some incorrect URLs to the client (web browser), when the browser actually wants to fetch one of those URLs, the web server has to realise somehow that it is a URL associated with the AtoM installation. Unfortunately there is no consistent information explicit in the incorrect URLs to identify them as a AtoM URLs as there would be if AtoM had sent the correct URL to the browser in the first place. So the web server is going to have to be explicitly configured to recognise that certain URLs need to be rewritten and forwarded to the correct URL that AtoM should have generated to start with. Those URLs can can only be determined through trial and error but include (but are not limited to) those URLs that I have listed in other posts in this thread. You could save me the trouble and give me that list if you know it.

You have said in a previous posting on this thread "AtoM installations are recommended to be on its own domain/subdomain". The guidelines do indeed describe the installation of AtoM in the root of a domain however there is no mention that this is the recommended or preferred method. There is no suggestion that any other installation style will simply not work.

If you wish to insist on the position that AtoM should only be installed in the root of a domain then I really suggest that you add to the installation guidelines that it is not just a "recommendation" but actually a "requirement".

However, having said that, I cannot fathom for the life of me why you would not want AtoM to work correctly and return the proper URLs of the artefacts that it contains regardless of what path it is installed into.

Chris

[Chris Selwyn]

Further...

Since I am now using the arDominionB5 plugin, the functions in the file apps/qubit/modules/digitalobject/templates/_metadata.php seem to be overridden by the functions in plugins/arDominionB5Plugin/modules/digitalobject/templates/_metadata.php. So it seems I now need to apply the fixes that I had done originally for the digital object reference and thumbnail URLs to the equivalent file in the arDominionB5 plugin copy of the code in. Now it works again :-)

Chris