Customize Native Child Theme in Ojs 3

Software Support
1

Hi @NateWr

We are using your child theme (GitHub - pkp/defaultManuscript: A clean, simple OJS 3 theme with a boxed layout that mimics a paper document.).
But we would like to make a small change for header color, fonts and abstract alignment.
I have tried this codes

head {
background-color:#262626;
}
body {
font-family: sans serif;
text-align: justify;
}

Nothing changes with the head color, the font changes but all texts seems to be justified. We just want to justify the abstract

It is very helpful for any given hints/css codes to customize the look (header, body, right sidebar, and footer).
This is my journal link http://jurnalbeta.ac.id/index.php/betaJTM

1 Like
2

Hi @kawahyu,

There are a couple of options for you depending on how much customization you want to do. The easiest thing to do is just to upload a custom CSS file under Settings > Apperance > Journal CSS.

If you went that route, you could try the following CSS code to change the header color:

.pkp_structure_head {
  background: red;
}

The following will adjust the base font in most places, though there may be some where you need to change it again:

body {
  font-family: sans-serif;
}

To justify the abstract, try the following CSS selector:

.obj_article_details .abstract {
    text-align: justify;
}

However, I don’t recommend you justify the abstract text. Justified text in browser’s is done very poorly, and is often considered difficult to read (in contrast to the justification you would get from a printed document processor). That’s why it’s generally avoided online.

If you expect you’ll make many more customizations to the theme, I’d recommend you look into creating your own child theme. You can child theme a child theme (ie - make a “grandchild” theme) to do this. You can learn more about that in this forum topic.

Finally, you should be wary of using default-manuscript. It’s still in early development stages so it may be missing key features and is likely to undergo significant changes before being released for public consumption. Still, if you’re happy to role with those changes, you’re welcome to use it.

1 Like
3

Thank you so much. We’ll be very glad to have the release

4

Greetings @NateWr

How could I customize font color, footer background and footer content?
Is it ?

.pkp_structure_footer {
background: red;
}
body {
font-family: sans-serif;
font-color: black;
}

I want to make PKP footer to the right and add some information on the left. How is it?
When I write something on the footer (Appearance), it comes up above the PKP

Thanks a lot

Footer.PNG950×75 4.92 KB

5

Hi @kawahyu,

This requires more significant CSS changes. You’ll need to be familiar with using CSS floats. The following will get you started but you’ll probably need to tinker further with it to get it looking good.

.pkp_footer_content {
  float: left;
  width: 50%;
}
.pkp_brand_footer {
  float: right;
  width: 50%;
}
6

Thanks a lot @NateWr
One more thing, I would like to change block color at the bottom of footer (Screenshot attached).
I tried using this code

.pkp_structure_footer_wrapper{
background: @bg-light-shade;
border-bottom: @double solid @bg-lighten-3;
}
But nothing changes.

7

Are you using this code in a standalone .css file? Or are you editing the .less files in your theme? These variables, @bg-light-shade and @bg-lighten-3, don’t exist in the theme. Have you created them separately?

8

I added the codes along with the other codes you informed me in one css file. I don’t edit the less file. I just looked at layout.less and found .pkp_structure_footer_wrapper. I think that is the code which relates to footer. I search about @bg-
 that it is about color. I made experiment for the codes

9

Hi @NateWr
I could customize them as I expect

10

Hi @kawahyu,

Great! Looks like you were able to get it working in the end. The variables @bg-* that you see are specific to the LESS processor. When you’re uploading a .css file, you just need to use plain colors, like #000 instead of the variables (anything with @ in front).

1 Like
11

Hi @NateWr,

Hi! I would like to clarify some aspects of the scheme proposed.

Let us suppose we need to modify the theme for ALL of our journals. Since the default standard theme is not recommended to modify, we would have to ask all our journal managers to switch to the (default) child-theme to make it possible to modify it and to synchronize the child-theme with any changes made (by the developers) in the standard one.

Now, let’s suppose some of our journal managers would like to make their own themes. We would recommend them to make their themes based on the child-theme (their themes would then be ‘grandchild-themes’). This would make it possible to synchronize both changes made in the standard theme, changes made by us (in the child-theme) and changes made by journals.

Sorry for these primitive questions, but do I get the idea?
And would it be safe to follow this principle now, at the earlier stage of development?

12

Hi @NateWr,

This would be an extension to the last question. In the description of your
default child theme you write:

Some versions of this theme are only compatible with certain releases of OJS

Might this mean there is some probability of the whole chain of parent-children relationship being broken in the case when the OJS is upgraded, while the child theme is not? And how can we avoid this to happen?

13

Hi @Ph_We,

Yes, the platform supports “grandchild” themes to an unlimited depth. Splicing off common features into separate themes which can then be extended is a good idea for keeping your code isolated and easier to maintain.

Might this mean there is some probability of the whole chain of parent-children relationship being broken in the case when the OJS is upgraded, while the child theme is not? And how can we avoid this to happen?

I’d encourage you to check compatibility between your theme plugins and your installation of OJS before upgrading either. In most cases, you’ll want to be completely up-to-date on both. The default theme will always be up-to-date with the current version of OJS, so if you’re building a child theme based on the default theme you should be safe.

But details in the templates can change from one version to the next. The best way to ensure your customizations maintain compatibility is to keep a staging or development site in which you can test compatibility in a safe environment before upgrading.

1 Like
14

Hi @NateWr,

Thanks for the answer. So the worst thing we may get when upgrading OJS before your child theme is updated might be some templates or variables working incorrectly, if they are changed in OJS and its default theme, right?
Are you going to support your child theme further, to make it always up to date with the current version of OJS?

15

Are you going to support your child theme further, to make it always up to date with the current version of OJS?

Which child theme are you referring to? defaultManuscript is a CSS-only child theme, so there’s very little scope for significant problems. The default-child theme is really intended only as an example, and only uses the very basic bits of the theme API which are pretty stable. If those parts need to change, we’d disrupt every custom theme ever made, so we’d have to provide some kind of compatibility support.

16

I am referring to this theme: Manuscript (Default child theme). Which is available through the Gallery now.

I am really sorry for these silly questions. I am really new to this, and I need to clarify/translate for our web-designers just what they should begin with to make the whole scheme as stable as possible.

So let’s suppose we set this default child theme for all of our journals. Now, what we can do next? Can we edit this child theme then? Or should we rather make a grand child theme based on this one and set this grandchild theme as default for all the journals, so the child theme would get any updates from you?
And should we instruct the end-users (journal managers) to create their own themes based on the child (or the grand child).

So I need some basic instruction of a recommended parent-child configuration for the multi-journal installation.
Once again, sorry :slight_smile:

17

Hi,

In our installation I have used a rather simple approach.

I basically created a new theme (let’s call it baseTheme). This theme is based on the default theme, but it is not a child theme - it is a independent new theme which has a lot of the same code as the default theme.

For every journal I am creating a new child theme which is based on the baseTheme. The child themes are really simple, most of them only have a custom header image and some colors redefined. In some cases journals have requested some edits to their templates etc. and these changes are of course saved in their own child theme.

If something changes in OJS3 that will affect the themes, in most cases we only have to edit the baseTheme and these changes will affect the child themes. Besides this in some cases we have to take into consideration changes that affect child themes with custom templates.

So we have basically two levels of themes: baseTheme => Journal child theme

I am still considering changing our baseTheme to be a child theme of the default theme but depends on the amount of changes we end up having. This would mean that we would have three levels: default theme => baseTheme => Journal child theme

2 Likes
18

@Ph_We: there isn’t really a “best” way here. There are only a couple options with pros and cons. In general, though, I recommend never modifying any code distributed by a third-party (in this case, PKP).

In general, I would say there are two models: using a Child Theme or Base Theme. With the Child Theme approach, you base all of your work off the default theme or another theme created and distributed by someone else (ie - Manuscript or Bootstrap3).

The Base Theme model is what @ajnyga has described: creating your own base theme and extending from that.

By using a Child Theme approach, you can benefit from any of the rolling changes that are provided by a third-party. For instance, a popular request is for us to redo the citation block on the article details page to make it smaller. So we’ll probably do that at some point, and we’ll integrate those changes with the default theme, and make sure they work with Bootstrap3 and Manuscript as well. If you use a Child Theme, you’ll get those changes for “free” just by updating the plugin.

However, that also means that you’ll need to keep an eye on changes that are happening. If we make a change that effects one of your custom themes in an unexpected way, you’ll need to have some way of identifying and correcting that before you update.

By using a Base Theme approach, you can insulate yourself from some of these changes. With the citations change, for instance, if you don’t like the change we’ve made, you can drop the old template into your base theme and keep all the same styles. However, you won’t get any of the rolling updates we make, like the recent bug we’ve fixed with the navigation submenus on some mobile devices.

So either way works. It really just depends on how you prefer to manage the changes that are coming down the pipeline. A custom base theme is a good way to insulate yourself from some of those changes, but it may mean more work is needed down the line to integrate the changes you want to include.

Personally, here’s how I would organize things if I was running a platform with lots of journals that each needed customizations.

  1. I’d create a custom child theme, myPlatformTheme, of the default theme. This would act like a “base theme” for all of my journals. It would allow me to place any code that I wanted to include with all journals, but I wanted to remain separate from the default theme. For instance, maybe my journal platform includes a custom link to the platform in the footer of every journal. That would be something to include in this base theme.

  2. I’d create a custom child theme of myPlatformTheme for every journal that needed more customizations. That way each theme’s modifications could be isolated from each other.

With this setup, I can still take advantage of all basic bug fixes and improvements from the default theme. Because I havne’t touched any of the code there, I can just update and get those improvements easily. But if the default theme does something that doesn’t fit with what I need for my platform, I can insert modifications into myPlatformTheme and automatically have them applied to every journal on my platform.

But that’s just my preference. Depending on how involved you’ll be for maintenance and upgrades, you might find other strategies work best for you.

3 Likes
19

Hi @ajnyga and @NateWr,

We are cordially thankful to both of you for finding some time to make it somewhat clearer. Your experience is indispensable. I think we would choose the approach, proposed by @NateWr.

So the “Manuscript” child theme, available through the Gallery, is only an example of a child theme, which we might take as a basis for our own child theme. I think we should possibly rename it to make it independent from the original “Manuscript”. Anyway, we should not upgrade it through the Gallery once we have made some modifications to it. Is that right?

20

Yes, you should never make modifications to the original files. These changes will be destroyed when you update in the future. Either create a child theme or copy the files into a brand new theme with a separate name.

2 Likes