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!
El miércoles, 3 de diciembre de 2025 a las 17:19:44 UTC+1, DSpace Technical
Support escribió:
> 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
>
> On Wednesday, December 3, 2025 at 2:35:47 AM UTC-6 [email protected]
> wrote:
>
>> 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.
>>
>> El viernes, 14 de noviembre de 2025 a las 18:02:37 UTC+1, DSpace
>> Technical Support escribió:
>>
>>> 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
>>>
>>> On Tuesday, October 14, 2025 at 6:01:48 AM UTC-5 [email protected]
>>> wrote:
>>>
>>>> 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):
>>>>
>>>> [image: rua.png]
>>>>
>>>> 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.
>>>>
>>>
--
All messages to this mailing list should adhere to the Code of Conduct:
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/dspace-tech/ea170ebb-d10e-4937-87b4-2591c6f08c48n%40googlegroups.com.
