EPrints Technical Mailing List Archive

Message: #08926

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

Re: [EP-tech] auto-X.Y.Z.css

Hi Yuri,

Thanks for the feedback.  I did not find any noticeable slowdown when using this method but I could imagine with generate_static or a lot of requests coming in at once this could be quite processor intensive and slow generation times. 

I have switched to you -M flag which is much more efficient*.  Unfortunately, this gives a relative time compared to the process, technically, this means that generate_static will generate different values compared to pages requested through the browser.  However, as you suggest in your comment about an md5 hash, really the important thing is to make sure that this value changes when a file changes.  If on occasion its changes when a file has not been modified this is not a big problem, as long as it does not happen on every request.  As at that point we are basically no longer caching _javascript_ and CSS, which would slow page loading time and increase CPU load on the server.

I have done some testing running generate_static and the run time is not noticeably different with this feature enable or not.  I might see if there are some larger scale tests to determine any difference.  However, I think the difference should be trivial relative to other aspects that contribute to page load times / server load.

Regards

David Newman

*https://github.com/eprints/eprints3.4/commit/7d658dd352867c0d9c9b82c98dd7e52c5eb54c23

On 29/04/2022 8:21 am, Yuri via Eprints-tech wrote:
CAUTION: This e-mail originated outside the University of Southampton.

Hi!

 why not using the md5 hash? That would be consistent, not depending on last modified. Also you open the file (stat on it) for every web page view.

The md5 would be calculated on generate_static. Because we run generate_static every time we change the css, then we can use it to create directly the md5 and store the value somewhere.

Also using webpack is another option.

Il 29/04/22 08:43, David R Newman via Eprints-tech ha scritto:

Hi both,

Here is my fix:

https://github.com/eprints/eprints3.4/commit/d940ee2ff8d3955010988bea8379cf1502eb8cda

I am not sure if you want to patch.  This will probably need some adaptation if you are running 3.3, as the function in Repository.pm expects an inc file with flavours and ingredients, which is new for 3.4.  I have also noted I took a rather odd approach using a ternary statement to update the $last_modified_time depending on whether the latest timestamp returned for the current directory is more recent.  There is nothing seriously wrong with this but I may fix it for something marginally more efficient.

Regards

David Newman

On 28/04/2022 5:38 pm, David R Newman via Eprints-tech wrote:

Hi John and Yuri,

This is the bane of my life as well, having to tell users to make sure they "hard refresh" the page before complaining something is not appearing/working as expected.  So having a fix for this will save me a lot of back and forth because I can be confident caching is not an issue.

Therefore, I have created this GitHub issue:

https://github.com/eprints/eprints3.4/issues/220

I have half written this already, it should not take too long to complete but may take a while to test to be confident it will do the job.

Regards

David Newman

On 28/04/2022 5:29 pm, John Salter wrote:
CAUTION: This e-mail originated outside the University of Southampton.

As a (hopefully useful) side note, the Apache Rewrite ruleset will honour URLs for the auto css and _javascript_ that match e.g.

style/auto-3.3.10.css

style/auto-3.3.101.css

style/auto-3.3.10999.css

style/auto-3.3.100000.css

- any amount of digits (but only digits) before the '.css' or '.js'.

 

This can be used to force newer versions of the auto- files into browsers.

 

For recent versions of EPrints, I think you can copy lib/cfg.d/template_core.pl into the archive config file.

I would suggest changing this line:

href ="" $repo->current_url( path => "static", "style/auto-".EPrints->human_version.".css" ),

to:

href ="" $repo->current_url( path => "static", "style/auto-".EPrints->human_version."1.css" ), #note '1' before '.css'

 

Next time you need to force a different auto CSS or JS file, update the digit, or remove it!

 

For older versions of EPrints (3.3.10, possibly beyond), where the loading of config files from various different directories worked a little differently, and overriding files from lib/cfg.d/ wasn't as simple as copying them to the local config, you could make a lovely hack, intercepting the template pins and adding extra digits to them:

https://gist.github.com/jesusbagpuss/c5ae75d8cbafb902af8299ec57101d8c

 

I'm not /recommending/ the above hack - but we had it running like that without incident on 3.3.10 for a number of years!

 

Cheers,

John

 

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of David R Newman via Eprints-tech
Sent: 28 April 2022 16:50
To: eprints-tech@ecs.soton.ac.uk; Yuri <yurj@alfa.it>
Subject: Re: [EP-tech] auto-X.Y.Z.css

 

Hi Yuri,

This is in lib/cfg.d/template_core.pl.  This file may also be in your archive's cfg/cfg.d/ directory or possibly even the flavours/pub_lib/cfg.d/ directory if you are on 3.4. 

This is the block of code you need to update (around line 39):

 $head->appendChild( $repo->xml->create_element( "link",
            rel => "stylesheet",
            type => "text/css",
            href ="" $repo->current_url( path => "static", "style/auto-".EPrints->human_version.".css" ),
        ) );

Regards

David Newman

On 28/04/2022 4:41 pm, Yuri via Eprints-tech wrote:

CAUTION: This e-mail originated outside the University of Southampton.
 
Hi!
 
  where's the code/template that generates the link in the head to
auto-X.Y.Z.css? I've modified it, but it is cached in the browser for a
month. I need to change it in order to people to get the changes without
asking them to clear the cache.
 
Thanks!
 
 
*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: https://eur03.safelinks.protection.outlook.com/?url="">
 AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=qD%2Bac2q85kHMQ9C%2FngNKXI03jrGh0s52kqxiJefoXQs%3D&amp;reserved=0
*** EPrints community wiki: https://eur03.safelinks.protection.outlook.com/?url="">
 uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Mjmd7ryQW69R5WYd6mS%2FU5JtKGpw%2FU3rB6EXpf8xMKE%3D&amp;reserved=0

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/