2. FAQ
In the source code of the page there are various meta tags at the very beginning, which provide information about the age and code base of the version used:
<meta name="generator" content="Goobi viewer" />
<meta name="version" content="21.01" />
<meta name="build date" content="2021-01-10 05:44" />
<meta name="git-revision" content="dd0bea0" />
"Goobi viewer" is the product name, "21.01" the version number. "2021-01-10 05:44" is the date when the application was compiled. "dd0bea0" are the first seven characters of the git commit hash used to compile the application.
The date is a good first indicator. The git-commit hash can be searched for on GitHub, for example, to find out exactly what state the application is at.
For the re-indexing of the entire database, the contents of the indexed_mets folder must be copied into the hotfolder:
cp /opt/digiverso/viewer/indexed_mets/*.xml /opt/digiverso/viewer/hotfolder/
Before copying, make sure that the hotfolder is empty so that no potentially corrected records are overwritten with an older version from the indexed_mets folder.
The Goobi viewer supports all so-called "evergreen browsers". These are the current versions of Google Chrome, Firefox, Safari and Microsoft Edge.
Older versions, especially Internet Explorer 11, have not been officially supported since mid-July 2018.
The Goobi viewer has full support for OBJ (Wavefront Object), GLTF/GLB and partial support for PLY and STL.
Partial support means that only the mesh can be displayed but no surface properties. The models are then displayed in one colour.
We recommend installing the Goobi viewer in a virtual machine in order to be able to add or remove resources as required. The following parameters have proven to be a good basis:
- 4 CPUs
- 8GB RAM
- 25GB hard disk for the operating system
Storage is also needed for the digitised files. If possible, this should be connected directly to the machine and not as a network drive. An LVM is then created within the machine in order to be able to increase or decrease the memory if necessary.
If a network drive is used, we recommend connecting it via NFS. In this case, however, an additional local device should be available for the Solr search index and the image cache. Otherwise performance problems may occur.
We also recommend installing the Goobi viewer in the current Ubuntu Linux Server LTS distribution.
If the file system on which the data of the Goobi viewer is stored is full, usually
/opt/digiverso/, then the following folders can be emptied without problems:updated_mets/deleted_mets/error_mets/success/
The following folders can also be checked:
abbyy/The files in this folder have been automatically converted to ALTO by the Goobi viewer Indexer since October 2017. The Goobi viewer itself only uses the ALTO. If the data was imported via Goobi workflow, it is available there and can be deleted in the Goobi viewer.pdf/The PDF documents stored in this folder are delivered with a PDF download from the Goobi viewer. If there are no files here, (if configured) a PDF with optional text is generated from the image and optional ALTO file and delivered. The result is the same, only the delivery time may take longer. For the PDF files generated in this way, there is a cache undercache/pdf.data, so that PDF documents that have been generated once are stored there up to a cache size of 100GB.
The theme is compiled and the core is included as a dependency. Therefore, the following steps describe how to check out the Reference theme and compile a viewer.war:
- If not already done, maven must be installed:
sudo apt install maven
- Then check out the theme:
mkdir -p /opt/digiverso/viewer/themes
cd /opt/digiverso/viewer/themes
git clone https://github.com/intranda/goobi-viewer-theme-reference.git
- Now compile the application:
cd /opt/digiverso/viewer/themes(goobi-viewer-theme-reference/goobi-viewer-theme-reference/
mvn package
At the end, the compiled Goobi viewer is located in the
target/viewer.war folder.There is a
Master branch that is always stable and installable. There is also a so-called
Develop branch, which contains new functions but cannot be completely stable yet. The Develop branch is used for
feature_ branches in which new functionality is developed. As soon as these are finished, they are merged into the Develop branch and from time to time the developments flow back from the Develop branch into the stable Master branch.The Goobi viewer and its components have a version number consisting of potentially three digits, for example 21.01.3.
The first digit of the version number indicates the year in which the version was released. In 2021, for example, this is 21.
The second digit indicates the month in which the version was released. Months are always indicated with two digits and, in case of doubt, filled with a leading zero. In January, for example, this is 01.
The third digit is optional and describes the patch level. It is only given if there is also a bugfix release. In the example above it is 3.
In addition to the stable versions, there are also development versions. These always have the version number of the following month without patch level and end with
-SNAPSHOT. Based on the example above, the next development version would be 21.02-SNAPSHOT.Should it ever happen that the Solr index contains empty anchor documents (i.e. multi-volume works without volumes) due to faulty imports, these can be removed from the index in one fell swoop. The following command can be used for this purpose:
cd /opt/digiverso/indexer
java -jar solrIndexer.jar config_indexer.xml -cleanupGrievingAnchors
Sometimes during development it may be necessary to clear the entire Solr search index. To do this, all works must be deleted from the Goobi viewer without leaving any residues. Finally, the Solr index has to be optimised. On the Linux command line this task can be solved as follows:
cd /opt/digiverso/viewer/indexed_mets/
for i in *.xml; do echo touch ../hotfolder/${i/.xml/.purge}; done
curl "http://localhost:8983/solr/collection1/update?optimize=true&waitFlush=false"
If the image display in the Goobi viewer is prevented by an access licence, a substitute image is displayed.
The path to this image is configured in the messages file using the following key:
noImage_accessDenied
The default entry is as follows:
noImage_accessDenied=<img src\=“/viewer/resources/images/access_denied.png” />
The key can be overwritten in the local messages files. This allows individual images or texts to be displayed that are different for each language.
No, the Goobi viewer does not store cookies.
However, in a modern world there are many more ways to store data and the Goobi viewer does use them. However, we can say with a clear conscience: "All data automatically created by the Goobi viewer to provide functionality will be deleted at the end of the session."
Technically, there is a cookie. However, this is automatically generated by the Tomcat Application Server. Only a temporary character string, the JSESSIONID, is stored in the cookie. This session is generated on the server side when the Goobi viewer is called up and stores information such as the selected language in the user interface or whether a user has logged in. The session is automatically deleted after 30 minutes of inactivity.
The Goobi viewer also stores other data. However, this happens in the browser session. This means on the user's computer and not on the server. The information stored here is, for example, which view was selected for the search hits (details, list, thumbnails) or which zoom level and position an image has, so that this information can be retained when browsing.
The session storage is automatically deleted when the tab is closed or the browser window is closed.
Last modified 1yr ago