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:
- the computer I use (I always use the latest chrome browser but on either windows or linux)
- The address eithe npwtj.com or www.npwtj.com bot there are no rules - If it does not work on one then it works on the other.
- 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_urls in config.inc.php?
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 http://npwtj.com/lib/pkp/fonts/fontawesome/fontawesome-webfont.woff2?v=4.3.0. (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
www.npwjt.com, the url
http://npwtj.com/lib/pkp/fonts/fontawesome/fontawesome-webfont.ttf?v=4.3.0 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.
Indeed, if I go to your site at www.npwjt.com, the icons won’t show up. If I go to npwtj.com (no www), they load fine.
You can see if you go to the stylesheet that the URL for loading the icons is
//npwjt.com without the
Even if you regenerated the CSS to add
www, you’d have the same problem when your site was reached at
www.npwtj.com. 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_urls, 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
http://myjournal.org (canonical instance) and
https://www.myorg.org/jourals/myjournal (alternate url) and
http://dev.myjournal.org (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?
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
https://mydomain.com 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
mydomain.com/article/1 and half of them point to
otherdomain.com/index.php/mydomain/article/1, 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:
npwtj.com. A 22.214.171.124
www.npwtj.com. CNAME npwtj.com
My question is how do I redirect traffic to npwtj.com?
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 config.inc.php. For example:
base_url[index] = http://npwtj.com/index.php/index
base_url[npwtj] = http://npwtj.com/index.php/npwtj
base_url[another] = http://npwtj.com/index.php/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
npwtj.com and setup mod_rewrite to redirect all traffic from
Had same issue.
I set base URL that includes www and removed CSS files from cache. Icons appear fine now.