Hello,
I’m wondering if anyone has successfully created custom css that carries through all of Scripto’s pages, and not just the project page itself, which carries a url something like “www,nameofsite.com/scripto/s/home”. However, the custom styles do NOT display in the directory of www.nameofsite.com/scripto.
I’m going off of the directions as shown here:
https://omeka.org/s/docs/user-manual/modules/scripto/themeingScripto/
Thanks!
When you’re theming Scripto and your project, you need to coordinate their respective themes. The documentation is describing a process where you can generate a Scripto theme from an Omeka S site theme so that the two share styles. Do you have a live example to share and allow others to troubleshoot?
Papers of the War Department 1812 is the live example the documentation refers to. The “Transcribe” section is the Scripto portion of the website.
I have named the stylesheet the same as the respective Omeka S theme. Unfortunately I have to develop on a private URL.
I can say that Scripto’s file under view > layout > layout-scripto-public-app.phtml is displaying the custom styles just fine.
However, under view > scripto > public-app > index > index.phtml , the custom styles are not applying.
I would just like to know if this is to be expected or if the custom styles SHOULD be working there as well.
Thanks
I’m also curious what the reason is for the note about not changing Scripto Markup when it comes to theming. If we want to make this look like our site, markup changes are required in some areas. Asides from customized markup being overwritten when it comes to updating the Scripto module, is there anything else to be aware of?
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.
Thank you so much for this detailed explanation! It does help and actually, this base page looks like it isn’t meant to be themed: Scripto · Papers of the War Department
That’s the directory I was referring to originally.
Ah, I see now. Yes, that particular view has no url routes associating it with a site. In the https://wardepartmentpapers.org/scripto/s/home/1/1/item url, the home is the slug for the site within that Omeka S installation. Scripto’s views can check for an associated site, check its current theme, and then look within its css directory for a matching stylesheet. It unfortunately cannot do the same for custom markup due to the complexity involved.