The custom styles should be displaying in the Scripto views as well.
I’ll use the live Papers of the War Department (PWD) site as an example of the setup.
On the home page (https://wardepartmentpapers.org/s/home/page/home
), the view is loading the site theme’s css file, which sits at https://wardepartmentpapers.org/themes/pwd/asset/css/style.css
.
On the Transcribe section landing page (https://wardepartmentpapers.org/scripto/s/home/1/1/item
), the view is loading the Scripto custom theme, which sits at https://wardepartmentpapers.org/modules/Scripto/asset/css/site-themes/pwd.css
. Hopefully this example helps.
As to your other question:
Asides from customized markup being overwritten when it comes to updating the Scripto module, is there anything else to be aware of?
Scripto lives in its own section separate from where Omeka S’s public view files live. As a result, you cannot create your own custom markup from within your site theme the way you can for other modules, i.e. Contribution. Scripto might have its own pattern for doing this; the lead developer is currently looking into it.
Users can create multiple projects within Scripto the same way they can create multiple sites within Omeka S. However, all sites within Omeka S share the same Scripto installation. Any time two separate site administrators within an Omeka S installation add a Scripto link to their navigation, they are adding the link to the same, single Scripto instance associated with the Omeka S instance. There would be too much complexity involved in enabling per-site and theme custom markup files for Scripto. That was at least the main use case in mind during Scripto’s development. If you’re sure your use case will have only one site using the Scripto instance, custom views make sense.