Difference between revisions of "Admin/System Tools/Regenerate Views"

From EPrints Documentation
Jump to: navigation, search
m
m
 
Line 2: Line 2:
 
This page pertains to the '''Regenerate Views''' button in the '''[[Admin/System Tools|System Tools]]''' tab of the '''[[Admin]]''' web page for your repository web interface.
 
This page pertains to the '''Regenerate Views''' button in the '''[[Admin/System Tools|System Tools]]''' tab of the '''[[Admin]]''' web page for your repository web interface.
  
The '''Regenerate Views''' button updates the timestamp in the archive's <tt>var/views.timestamp</tt> file to the current time.  This file is used whenever a browse view (menu or listing) page is requested, if the current (server-side) cache for this browse view page is older that the timestamp in this file, then the browse view page is regenerated.  This is better than regenerating all browse view pages immediately.  As a repository gets larger the time to regenerate all browse view (menu and listing) pages gets longer and can put a high load on the server.  Also, by default the individual caches for browse view pages are set to 24 hours, so if the view pages were actually generated, there is a good chance many of their caches would expire before they were ever accessed.
+
The '''Regenerate Views''' button updates the timestamp in the archive's <tt>var/views.timestamp</tt> file to the current time.  This file is used whenever a browse view (menu or listing) page is requested.  If the current (server-side) cache for this browse view page is older that the timestamp in this file, then the browse view page is regenerated.  This is better than regenerating all browse view pages immediately.  As a repository gets larger the time to regenerate all browse view (menu and listing) pages gets longer and can put a high load on the server.  Also, by default the individual caches for browse view pages are set to 24 hours, so if the view pages were actually generated, there is a good chance many of their caches would expire before they were ever accessed.
  
 
If you actually want to regenerate browse view (menu and/or listing) pages use the '''[[API:bin/generate_views|bin/generate_views]]''' script.
 
If you actually want to regenerate browse view (menu and/or listing) pages use the '''[[API:bin/generate_views|bin/generate_views]]''' script.

Latest revision as of 21:11, 4 March 2022

Admin: Editorial Tools - System Tools - Config. Tools


System Tools: Status - Create user - Start Indexer - Stop Indexer - Force Start Indexer - Regenerate Abstracts - Regenerate Views - EPrints Bazaar - Send Test Email - Database Schema

This page pertains to the Regenerate Views button in the System Tools tab of the Admin web page for your repository web interface.

The Regenerate Views button updates the timestamp in the archive's var/views.timestamp file to the current time. This file is used whenever a browse view (menu or listing) page is requested. If the current (server-side) cache for this browse view page is older that the timestamp in this file, then the browse view page is regenerated. This is better than regenerating all browse view pages immediately. As a repository gets larger the time to regenerate all browse view (menu and listing) pages gets longer and can put a high load on the server. Also, by default the individual caches for browse view pages are set to 24 hours, so if the view pages were actually generated, there is a good chance many of their caches would expire before they were ever accessed.

If you actually want to regenerate browse view (menu and/or listing) pages use the bin/generate_views script.