Problem rendering glyphicons in ojs 3.0.0

I have a strange problem and do not know if this is a bug or settings problem:

the glyphicons are sometimes rendering correctly and sometimes not. It depends on:

  1. the computer I use (I always use the latest chrome browser but on either windows or linux)
  2. The address eithe or bot there are no rules - If it does not work on one then it works on the other.
  3. Even if they work on the main site they can still fail rendering in the “dashboard”

any clues here?
I am using the standard out-of-the-box theme without anything fancy.

I tried installing bootstrap theme set but its the same thing there.

What are your settings for base_url and any base_url[]s in

I’m getting the following error in my web browser’s console when accessing your server:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at (Reason: CORS header 'Access-Control-Allow-Origin' missing).

Cross-Origin request configuration is not handled in OJS, to my knowledge, and is thus left as function of the webserver configuration.

When requested from, the url is being delivered with an HTTP response 206 Partial Content, which may also be part of the consideration.

@NateWr might be more familiar with the intricacies here.

I just saw your site launch on Twitter, noticed the missing search icon, looked in the console and saw the Cross-Origin request, then remembered this forum post. :slight_smile:

Indeed, if I go to your site at, the icons won’t show up. If I go to (no www), they load fine.

You can see if you go to the stylesheet that the URL for loading the icons is // without the www.

Even if you regenerated the CSS to add www, you’d have the same problem when your site was reached at I’d recommend you handle this on the server level, by making one of the locations the true location of your site, and redirecting all requests (so either with www or without).

There may be some server-side stuff you can do to make this just work. That’s not my strength, but using one or the other URL format is just good SEO policy too, so I’d recommend you do things that way.

Can you describe more what you mean by “using one or the other URL format is just good SEO policy”? I think I would have argued that the important thing is selecting one URI as the basis for the canonical URLs, but I’m not familiar with a reason not to expose a site via multiple URIs, assuming the canonical URL is identified.

I wish OJS would de-emphasize the use of base_url and base_url[]s, leaving these only for forming the canonical URL and not for writing links, etc. In my mind, a single journal configuration could expose OJS from (canonical instance) and (alternate url) and (private development instance with identical configuration). Assuming OJS appropriately exposed <link rel="canonical"> tags, what would be the risk/harm to consider? How committed are we to spitting out absolute paths instead of relative paths in the current framework?

Hi @ctgraham,

I think you’re right that proper use of canonical tags would overcome the primary problem of having duplicate content. What I’d be worried about would be all the ancillary problems that would/could arise.

For instance, if you’re using Google Search Console at all, it only tracks full details per-property, and it considers, and different properties. You can group them, but you only get general aggregate statistics. Many of the useful tools are only available per-property.

More concerning would be how external ranking signals interact with a canonical link. This is something that I honestly don’t know about – maybe it’s no problem – but I’d be nervous about the impact. Example: if half of your inbound links point to and half of them point to, does the canonical link still get the full value of all of those links?

In my mind, canonical links are a workaround when there’s no alternative. I’d be very cautious before implementing them as an intended strategy for deliberately hosting multiple instances of the same content. I’d be much more likely to opt for using noindex to void alternate sites completely. That said, I’m definitely open to being corrected on this issue. I just know that Google’s not as smart as it is often reputed to be, and minimizing the complexity of content relationships on a site would be my first priority.

Looking at it from a different angle, I’d also be very sceptical that many of our users have the technical awareness to implement and manage canonical links properly. You’re kind of a (welcome) exception to our typical user base, but I worry if we tried to automate this too much, we might end up causing more problems than we want.

I’d definitely be open to exploring what kind of developer hooks or other tools we might be able to put in place to allow folks like yourself to run more advanced setups.

Nice discussion but for a simple user:

What are the steps I should take?

my settings in


My domain’s DNS is done with the following inputs: A


My question is how do I redirect traffic to

Or any other solutions to the problem?

One solution you could try within OJS itself is to explicitly name each journal base_url, including the site index, in For example:

base_url[index] =
base_url[npwtj] =
base_url[another] =

This should force OJS to construct all links without the www prefix.

Other solutions would be a the webserver level, and start to diverge from the scope of this forum. For example, you could use Apache Name-based Virtualhosts to differentiate between and and setup mod_rewrite to redirect all traffic from to


I have posted this issue and my solution 2 month ago. Just here OJS3: No Access-Control-Allow-Origin header is present on the requested resource (Chrome) - #2 by Vitaliy

1 Like

Had same issue.

I set base URL that includes www and removed CSS files from cache. Icons appear fine now.