Manuscript Theme links colors

We use OJS and Manuscript Theme 1.0.2 for many journals. Basic color settings (@bg-base and @accent) allow individual styling via Website Appearance.
But at the same time, the color of links remains the same (@primary: #4b7d92;). As it is set in variables.less and this setting cannot be changed via Website Appearance.
What is the easiest way to change this color for different journals? The general idea is to make @primary equal to @bg-base.

Dear @NateWr, is there any way to change the variable @primary? The most correct method would be to put it in Website Appearance settings, by analogy with how it is done for @bg-base and @accent. But if this is not possible, then how can we change it through loading custom css? Thanks!

Hi @rkhalikov

You can change the link color of each journal by adding this to the css (replace XXXXXX with your preferred color):

a {
color: #XXXXXX;

That will also change the color of the article links, but if you want a different color of those you an just add that separately:

.obj_article_summary>.title a {
color: #YYYYYY;

Hope this helps!

Hi, Emma. Thanks, your method works. But what about colors for a:hover? How to set correctly in custom css something like “@primary-lift: lighten(@primary, 10%”?

In addition, it turns out that the color of DOI/ORCID links, as well as the search buttons (in main menu and search results), is set independently. In general, all this seems too complicated :frowning:. I believe that putting the link color settings to Website Appearance would easily solve this issue.

Hi Roman,

I agree it would be better/quicker if the link color could be changed in the settings, however, if it helps, here is the code for changing the hover color:

a:hover {
color: #292975;

Best wishes,

Thanks, Emma.

I experimentally found that I need to use this kind of css:
a {color: #2c2c82;}
a:hover {color: #6868cc;}
a:focus {color: #6868cc;}

But the question remains with other links - doi and orcid. This does not work for me:
.obj_article_details > .orcid a:hover {color: #6868cc;}
.obj_article_details > .doi a:hover {color: #6868cc;}

Am I making a mistake somewhere?

Try this:

.obj_article_details .orcid a, .obj_article_details .doi a:hover {
color: #6868cc;

Hope it helps! =)


Emma, ​​thanks for the tips, not everything was perfect, but they helped to understand the logic (which is very confusing…). As a result, I parsed in detail all css using browser’s developer tools and came up with this result.

First of all, if we use one journal or several journals with the same website style, the simplest and most correct way is to set the desired colors directly in the template (variables.less).

In case of individual styles, I needed to override styles for a number of elements. Here is my custom css. Let’s assume that color_1 = @primary and color_2 = @primary-lift.

a {color: #color_1;}
a:hover {color: #color_2;}
a:focus {color: #color_2;}
.cmp_notification {border-left-color: #color_1;}
.obj_article_details .orcid a:hover, .obj_article_details .doi a:hover {color: #color_2;}
.obj_article_details .orcid a:focus, .obj_article_details .doi a:focus {color: #color_2;}
.obj_announcement_summary .read_more {color: #color_1;}
.obj_announcement_summary .read_more:hover, .obj_announcement_summary .read_more:focus {color: #color_2;}
.cmp_button, .cmp_form .buttons button, .pkp_head_wrapper .pkp_search button, .page_lost_password .buttons button, .page_search .submit button, .block_make_submission a {color: #color_1;}
.header_view .return {color: #color_1;}
.header_view .return:hover, .header_view .return:focus {background: #color_1;}
.header_view .download:hover, .header_view .download:focus {background: #color_1;}
.page_search .submit button::after {background-color: #color_1;}
.page_search .submit button:hover:after, .page_search .submit button:focus:after {background:#color_2;}
.pkp_head_wrapper .pkp_search .search_controls .search_prompt:hover, .pkp_head_wrapper .pkp_search .search_controls .search_prompt:focus {color: #color_1;}

Now it finally works exactly as I wanted!

Hi @rkhalikov,

Glad you were able to figure it out. We have opted not to make the primary color a theme option because it is very easy to impact your journal’s usability and accessibility if the wrong choice is made. For this reason, we have chosen not to put that power directly in front of everyday users who may not understand the ramifications of their choice.

As you found, you can accomplish what you want with a custom CSS file, but this can require a little bit of digging. And as the default theme changes over time, your CSS file is likely to fall out of sync.

Instead, we recommend using a custom theme where possible. We offer a template starter theme you can check out. And here is an example of a replacement for the that would add an option for the primary color:


class DefaultChildThemePlugin extends ThemePlugin {
	public function init() {

		$this->addOption('primaryColor', 'FieldColor', [
			'label' => 'Primary Color',
			'description' => 'The primary color used in links and other places.',
			'default' => '#007ab2',

		if ($this->getOption('primaryColor') !== '#007ab2') {
			$additionalLessVariables[] = '@primary:' . $this->getOption('primaryColor') . ';';

	 * Get the display name of this plugin
	 * @return string
	function getDisplayName() {
		return 'My Theme';

	 * Get the description of this plugin
	 * @return string
	function getDescription() {
		return 'My example theme that adds a theme option for the primary color.';

Alternatively, if you know what color you want and don’t need the option under Settings > Website > Appearance, it may be easier to use the example child theme as-is, open styles/remove-borders.less, and replace the content with the following:

@primary: #123456;
@primary-lift: lighten(@primary, 10%);

That will ensure that if we make changes to the theme in the future, it will still use your colors wherever we use @primary or @primary-lift.

This and lots more info on theming can be found in our theming guide.

Many thanks for the information. This largely explains the logic. I agree that strategically this approach is more correct. But it requires more experience and testing. We’ll try to work in this direction.

1 Like