What I have:
I have a website consisting of a domain and two subdomains. My website is a WordPress multisite installation. The domain and subdomain websites each use the same WordPress theme that make extensive use of font icons.
What I need:
I need my font icons to display on the subdomain websites instead of diplaying as...
Font icons display fine on the main domain.
The problem:
My console log reveals:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at http://xxx. (Reason: CORS header
'Access-Control-Allow-Origin' missing).
My question:
Why would a website, theme and/or font icon behave differently on a subdomain than the main domain and how can resolve the matter?
This answer has started in the comments of the question. Sorry about that, but I won't repeat what I said there.
Ok, so I decided to put it as an answer, as I think passing info in bits and pieces via comments is not a good practice.
And speaking of practices, here's why you should add all your scripts and styles using wp_enqueue_script() and wp_enqueue_style() in WordPress.
The key behind WordPress's success is it's flexibility. Anyone can extend or restrain it, by adding or removing functionality to/from it. In doing so, a lot of people (namely plugin or theme authors, or even the DIY guy not knowing much about web, just trying out different cool scripts he found last night) at some point decide to use a certain asset. A font library, a JavaScript library or a CSS framework.
Most of these assets, if loaded multiple times are going to conflict with themselves, especially if different versions of them are loaded. And this is why you should always tell WordPress what you are using. Because if it finds out another plugin is using the same library, it will only load the asset once and provide it for every script/plugin or whatever else needs it.
That's the main reason. One of the secondary reasons, which applies in your case, is that if you decide to move this WP to another address, it's smart enough to dynamically rebuild the urls to its assets so they work in each installation.
And i'm only scratching the surface here.
Related
I have a JPG in the header section of a responsive HTML page. I want to use the same site content for multiple domains that will point to my single set of files at my hosted URL. Example : mysite.com will host all files. But a second site - example theirsite.com will point in a forward to my hosted files location.
All the content will be the same, EXCEPT FOR the one image file (logo.png) or can be any name, but I would like to see if I can image-substitute 1 file (logo.png) to render so that, when visitors come to mysite.com, they see my file. When visitors come to theirsite.com they will see the logo file for theirsite.com instead of for mysite.com Sorry if I have not explained this professionally.
There are two real ways to do this. The best way is to handle it server-side.
You would need some sort of dynamic site generation, such as PHP. As the site isn't changing on each request, I'd recommend doing this generation ahead of time. Then you can utilize static hosting on CDNs and such. The specifics of how you do this depend on your technology choice. And, it matters little what you pick.
Doing the switch server-side is better, as crawlers will be able to see the right version of the site. Most crawlers don't run client-side code.
The second option is to handle it client-side. In this case, I'd recommend including a site definition file for each domain and writing some JavaScript to check the hostname the site was loaded on, and load the right site definition file. That file could contain elements and attributes to replace. Again, this is less desirable of an option, but still possible.
In the same vein as the microservice architecture approach we're currently looking at splitting our legacy marketplace application into multiple, smaller sites. We've already carved off the checkout portion and soon to follow will be the seller portal, user portal and registration pages. Each site will be completely separate and have its own domain, data access etc.
The problem is: how do we maintain consistent site chrome (i.e. header & footer) across multiple websites? For the checkout site that we've already split off we were prepared to drop the site chrome but that's going to be a much less acceptable solution for future projects.
The ideas I've had so far are (assuming we don't want to simply duplicate the header and footer in each site):
Put the necessary HTML in a nuget package and install it in each site that needs it. This should be fairly easy to do but has the disadvantage that any change to the chrome means every site needs to be updated and redeployed. Also, it limits us to .NET for all future sites (maybe not a real concern?).
Serve all our sites through some kind of proxy site that injects the site chrome into the HTML before serving to the client. This way the site chrome is actually its own application and can be deployed independently of anything else. Disadvantage: I haven't really got any idea of how to implement this; I wasn't able to find anyone else trying anything similar on Google. Also, it might be fragile even once it's up and running due to interplay between the chrome app and the content app.
Has anyone else solved this problem before? If so, what approach did you use?
I'm learning about Chrome and Native Client.
Basically i want to increase number of pages that are prerendered
by chrome (now its just one page).
I was thinking about creating a extension that would
allow to prerender more pages.
Is this a way to go or am i left with hard coding it into Chrome and build from scratch?
EDIT
I started a bounty for this question. I would really appreciate some input.
No, there is no way to go, you would need to hardcode it in Chrome and rebuild as you noted.
As you probably already know, Chrome explicitly states that they currently limit the number of pages that can be prerendered:
Chrome will only prerender at max one URL per instance of Chrome (not one per tab). This limit may change in the future in some cases.
There is nothing in their supported API's or their experimental API's that will give you access to modify this. There is not a toggle in chrome://settings/ or chrome://flags/ or anywhere else in Chrome currently that allows you to change this. You can however use the Page Visibility API to determine if a page is being prerendered.
In addition to the one resource on the page that you specify using the <link rel="prerender" href="http://example.org/index.html"> you could also consider prefetching resources.
The issue with prefetching is it will only load the top level resource of at the specified URL. So, if you tried to prefetch the other pages, like so:
<link rel="prefetch" href="http://example.org/index.html">
...then only the index.html resource would be prefetched, not all of the CSS and JavaScript links containeed in the document. One approach could be to write out link tags for all of the contained resources in the page but that could get messy and difficult to maintain.
Another approach would be to wait for the current page to finish loading, and then use JavaScript to create an iframe, that is hidden off the page, targeted at the URLs you want to prefetch all the assets for. The browser would then load all of the content of the URL and it would be in the user's cache when they go to visit the page.
There is also a Chrome extension that combines these two approaches by searching for link tags that define a prefetch and then creates the hidden iframe causing the assets to be downloaded and cached.
If the goal is to optimize around client performance for navigating your site there might be other alternatives like creating a web application that uses a Single Page Application (SPA) style of development to reduce the number of times JS and CSS are loaded and executed. If you are a fan of Google then you might check out their framework for building SPAs called AngularJs.
If it was a good idea to pre-render more pages, Chrome would probably already do it. Pre-rendering too many pages will drain website bandwidth and possibly end up slowing down the whole web, which is the opposite of what you're trying to achieve. So it's most likely intentional that you can only pre-render a single page and you shouldn't try to break that.
Not possible. Chrome manages pre-rendering based on many factors. If this was possible, it could also be easily abused by many sites. You could, depending on your page, keep all content on one page.
Let's assume there's a site - http://domain.com
Now my job is to upload a CMS (Joomla, version 1.7). However, there's a big mess on FTP - already a Joomla (version 1.5), forum software, many unknown PHP files, many custom folders.
I can't simply upload Joomla 1.7, because I would have to delete that Joomla 1.5 file by file. So I've decided to upload CMS to subdomain, http://domain.com/subdomain, and display that content from http://domain.com. I don't want to simply redirect, because original URL must be kept.
How to do it? iframes are pretty outdated.
Iframes ? Stay away, use rewrite rules and keep the domain clean
http://httpd.apache.org/docs/current/mod/mod_rewrite.html
iFrames are still heavily used today and would be a fine solution for you. However there would be some problems with using an iframe that you should consider. My two cents fix the problem correctly by install Joomla properly, then try the using re-write rules all else fails you can use iframes.
Bad Points for iframe solution:
Using an iframe pointing to your site would probably be really bad for SEO. I don't think google or bing would look into the iframe thus you'd get 0 SEO value out of this solution.
URL link's would be ruined, if a user wanted to bookmark, tweet the url,
or even just send it to a friend they would have no way of doing that
because the url would be changing in the iframe not in the browser
bar.
No so bad points for iframes:
Sounds like this is an easy workaround for your problem so its not very time consuming.
iFrames are used all over the place on the internet and are fully supported by all major browsers.
I have a website that I was asked to "redesign".
The site itself was built and still maintained by FrontPage, so there are hundreds (hopefully not more) of HTML pages.
My main limitation is that I can't change any of the URLs because they have been there for over 10 years and have a lot of SEO value.
I want to rebuild the site in a smart way (CSS classes, dynamic pages, etc.) but also give the owner the ability to change content as he needs.
I was thinking of using WordPress, however I don't have experience with it and I'm not sure what it's limitations are.
My other issue, is that I need server side languages in order to enable this kind of site, but I don't know how to do that without changing the URLs.
And after I deal with all that, is there any way around manually handling every single page?
Any suggestions, or pushing in a certain direction are all welcome.
Feel free to provide new, meaningful, URLs but make 100% sure that you configure correct 301 redirects from all old URLs to the new ones.
You may change the permalinks from your WordPress admin section once you've written the .htaccess file. The old links of the static pages can then be redirect to new pages and links using 301 redirects which won't negatively affect the existing PageRank and SEO; see How to redirect a webpage