DSpace 7.6.1 SSR not working

[Ibai Stats]

Hello:

We have some problems with the repository caused by SSR not working. 

When we do a CURL -L of the home page, we get this result (we are not getting the full HTML response):

In theory, SSR is enabled by default, and no configuration related to it has been changed. What should we check in this case to ensure it works correctly in DSpace 7.6.1?

Thank you very much and best regards.

[DSpace Technical Support]

Hi,

If you are still hitting this issue with SSR not working, we have a guide for how to ensure your site has SSR enabled in the "Search Engine Optimization" documentation at https://wiki.lyrasis.org/display/DSDOC7x/Search+Engine+Optimization#SearchEngineOptimization-Ensuretheuserinterfaceisusingserver-siderendering

Tim

[Ibai Stats]

Hi Tim: 

Thank you very much for your response. We have checked that all the configuration is OK, but still SSR is not working. 

Could there be a specific problem with version 7.6.1 that's causing this feature to not work? Is there anything else I could check? 

We have verified that in other previous (7.5) and later versions, this does not happen to us.

Best regards.

[DSpace Technical Support]

Hi,

I'm not aware of any bugs in DSpace 7.6.1 that would cause SSR to fail entirely.  I also don't recall any similar reports on this mailing list from other institutions.

That said, you could also try to upgrade to the latest version of 7.6.x, which is currently 7.6.5: https://wiki.lyrasis.org/display/DSDOC7x/Release+Notes

It's also possible that an upgrade to the latest version of 7.6.x will solve the issues you are seeing. 

If an upgrade doesn't help, or you cannot upgrade, then my only other advice would be to use the troubleshooting guide to see if there are underlying errors that could be causing SSR to fail. It's always possible there's some sort of configuration or setup error that is "snowballing" into a larger error.  If so, there would be signs of that error in the logs or in your web browser's "console".  See the guide for how to find these: https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error

Tim

[Ibai Stats]

Hi Tim: 

Thank you very much for your response.

I dont know if this can be related, but we have found that the PM2 logs show the following persistent error:

2025-11-30 12:24:27 +02:00: Error in server-side rendering (SSR)
2025-11-30 12:24:27 +02:00: Error details :  Error: ENOENT: no such file or directory, open 'dist/server/assets/i18n/en.json'
    at Object.openSync (node:fs:601:3)
    at readFileSync (node:fs:469:35)
    at TranslateServerLoader.getTranslation (/xxxxxxxx/dspace-angular/dist/server/main.js:1:7841654)
    at TranslateService.getTranslation (/xxxxxxxx/dspace-angular/dist/server/main.js:1:2544266)
    at TranslateService.retrieveTranslations (/xxxxxxxx/dspace-angular/dist/server/main.js:1:2544114)
    at TranslateService.use (/xxxxxxxxx/dspace-angular/dist/server/main.js:1:2543648)
    at ServerLocaleService.setCurrentLanguageCode (/xxxxxxxxx/dspace-angular/dist/server/main.js:1:803671)
    at ServerInitService.initI18n (/xxxxxxxxxx/dspace-angular/dist/server/main.js:1:7852325)
    at ServerInitService.<anonymous> (/xxxxxxxxx/dspace-angular/dist/server/main.js:1:7854044)
    at Generator.next (<anonymous>) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: 'dist/server/assets/i18n/en.json'
}
2025-11-30 12:24:27 +02:00: Falling back to serving direct client-side rendering (CSR).

Looking in that path I see that assets only contain files like these
en.d332cb3fe482394367781784743548fd.json
en.json5
(BTW they look similar the json is minimized)

I've checked the path dspace-angular/dist/server/assets/i18n/, and the error is correct: the file en.json doesn't exist. Instead, the build process has generated files with hashes for cache-busting, like:
en.d332cb3fe482394367781784743548fd.json

en.json5

It seems the server-side application is hardcoded to look for en.json, but the build process creates a hashed version.

Is there a specific configuration in angular, PM2 or config.prod.yml that I need to adjust to make SSR correctly resolve the paths to these hashed asset files?

I haven't found any clues about this specific pathing issue online. Any pointers would be greatly appreciated.

Thank you very much, and best regards!

[DSpace Technical Support]

Hi,

That error looks similar to the one in this thread: https://groups.google.com/g/dspace-tech/c/qp56Whhtvpo/m/VTwQt9fWAQAJ   However, in that situation it was reported in DSpace 9.1, and no one else has been able to reproduce that behavior (to my knowledge).  So, I still don't understand myself the scenario where that is occurring, as it's not happening for most sites. But, as noted in that thread, the original reporter found a workaround.

Regardless, I'd also recommend considering an upgrade.  There were a *lot* of bugs fixed between 7.6.1 and 7.6.5.  It's very possible that you are encountering something that is now fixed in a later version of 7.6.x.  If so, an upgrade would fix it.  If *not*, then you'd at least be on the latest version and it'd be easier for others to try to reproduce or diagnose the issue (as there's more sites running on 7.6.5 or later versions of 7.6.x).

Tim