EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #09635

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] Subject trees in 3.4.5

CAUTION: This e-mail originated outside the University of Southampton.

Hi David,

Thanks for the speedy response, as always. As you say, I don’t specifically object to the change, just need to figure out how to make it work for us.


That’s now rendering it as just “C”, which is again different to how it was in 3.3.1x, but not necessarily a problem.

To resolve the previous issue of items only appearing at the leaf node, I had previously added all the separate layers of the subject tree to the database so they would appear in the browse view for each level. This meant that, on the item under the academic unit/department, you could see (in some cases)






Each line being a single link to that level of the subject tree


With the render_path parameter set to ‘0’ it is now rendering as






Which I can live with. At some point I will experiment with removing all the higher level entries from the database and only keep the leaf node values, then restore/remove  the parameter, so it renders the whole path again.


Thanks again,



From: David R Newman <drn@ecs.soton.ac.uk>
Date: Thursday, 22 February 2024 at 19:43
To: eprints-tech@ecs.soton.ac.uk <eprints-tech@ecs.soton.ac.uk>, Alan.Stiles [He/Him/They] <alan.stiles@open.ac.uk>
Subject: Re: [EP-tech] Subject trees in 3.4.5

Hi Alan,

I would take a look at:


I have checked over these and I think the one that most closely relates to what you describe is:


There is the render_path attribute you can set for the field that uses a subject tree.  However, reading this suggests you can either have the full path with multiple links or just the individual subject as a link rather than the full path as a single link like you describe you 3.3.15 behaviour.  At the time and as I describe in the issue above, adding the render_path attribute was intended so you can retain 3.3 behaviour.  I would give adding the attribute:

render_path => 0,

a go and see whether this does what you want.  Otherwise, I did note that the following issue implements a user-defined render function. If you cannot quite get back to what you had before:


However, it does not sound like you have a specific objection about the change, rather this changes how you might use this field.  I should note that these changes only relate to rendering.  I am not aware of any conceptual change.  So items under a child subject also count under the parent subject but are not explicitly capture in the database as being under the parent subject.  There is currently an outstanding issue with how the counts for some subjects in browse views, depending on the current subject/division being viewed:



David Newman

On 22/02/2024 5:31 pm, Alan.Stiles [He/Him/They] wrote:

CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Am I right in thinking that the rendering of subject tree fields changed at some point between 3.3.15 and 3.4.5 to show hierarchical detail?


We have a faculty structure in the subjects (outside of department field) which used to render links to the related view as


“A > B > C” as one link,


but the 3.4.5 rendering is showing

“A” > “B” > “C” as 3 separate links


Just want to check this is expected, and I can try and fix the underlying data field, which currently holds multiple values for “A”, “B” and “C” in order that the item renders as part of the item list for all three levels.




*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List
*** Archive: https://www.eprints.org/tech.php/
*** EPrints community wiki: https://wiki.eprints.org/