I have been given the task to embed a bunch of small websites into a larger website on our main domain.
The problem is that the small websites previously each had their own domain and were programmed with absolute paths. They will stop working if they are simply copied into subdirectories next to the main website.
Additional constraints:
The absolute paths can not be replaced automatically, since some of them are generated with JavaScript. A few parts of the unminified source code have been lost, so it would be extremely painful to fix.
The chances are good that this stuff will never be touched again. It has been decided that it should not be fixed in a proper way since "that would be waste of time".
It should be easy to add additional small websites.
I came up with the idea to create a subdomain for each website, but that violates constraint 3, because it would involve bothering the people responsible for DNS whenever a new website is added.
Is there a simpler solution?
I would be tempted to write a one-off program that I can point at a directory, and all it does is open the javascript files that have the absolute paths, and replace them with a relative path. A little bit of complexity in writing the program, but then super simple after that.
As for the simplicity in adding new sites, it depends a little on how these sites are hosted. If they're all retaining their own hosts, bugging the DNS people might be necessary no matter what. If they are being moved to the host server to live in the same directory structure as the main website, you can just put them in subdirectories so it looks a little like...
http://maindomain.com/
http://maindomain.com/subsite1/
http://maindomain.com/foobar/
http://maindomain.com/imspecial/
http://maindomain.com/shopping/
Adding a new site would then just be a matter of sticking another directory in there with it's own site code.
Related
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.
The question is very simple and even tho I might get downvoted into oblivion for it, I can't find a good search query for this.
If I link images, stylesheets, scripts and other things with the full website url (http://url.tld/css/style.css) instead of path (css/style.css) , are the visitors affected negatively? Is there any difference?
The html page is on the same link as the resource, so we're not talking about external resources.
This only makes a difference if you change your domain name. You cannot simply transfer the scripts over but have to change each line or the include of those files then.
One small thing to keep in mind: Your string will be longer and so your file will be a very bit bigger in size but it doesn't really matter.
Either won't affect visitors. Specifying the protocol might cause problems in the future if your users can switch between http and https. Specifying the folder also means changes when you move the site. So best to use relative
I've just added a subdomain to my website, but can I point it to files in the main website with relative links? Like in the way that ../ goes back a folder, can you tell it to remove the first part of the url?
Also, I've just seen perhaps it's better putting the image folder as a subdomain too, is it worth doing this?
It's not possible to link to another domain using relative links, even if it is a subdomain. If you really want to do this you could make some kind of scripting helper to do that, but it would need to run on every page. With this you could run into problems on clients that have scripting disabled.
Putting images in a different subdomain is usually done to optimise loading speed. Browsers usually have a limited number of simultaneous requests to a single (sub)domain. By putting images on a separate (sub)domain you allow the browser to make more simultaneous requests and (in theory) allow your site to be loaded faster.
You can't use relative links, but you can use mod_rewrite to help you make a 'pseudo relative' link.
If your desired relative link were: href='folder/filename.typ'
then make it: href='root/folder/filename.typ'
in .htaccess enter: Rewriterule ^root/(.+)$ http://yourdomain.com/$1
You don't have to use 'root' of course, any word will do so long as it's unique in this context (i.e. not an actual folder name).
CAUTION: I found this thread looking for a solution myself. I've only just worked out this method. It does work on my site but I've not tested exhaustively yet.
I have a more general design question relating to css and websites. I know that it is good computer science to normalize code as much as possible and avoid duplication. So it would stand to reason to me, at least in theory that one would do the same when organizing stylesheets for a website.
So when I started on my most recent website I started out with this same philosophy. It worked ok for my first few pages and while I was only testing in firefox...
However as my site grew and as I added pages, multiple layouts (and browsers) I found this philosophy broke down really quickly. Ultimately over time I have moved to the following approach:
I have a very limited top level css file for each master page layout in my site, it contains classes for well known styles across that layout as well as css for the master page.
I keep specific css styles for each page.
I keep specific css styles for embeddable page elements / controls
I ended up taking this route so that I could trust that changes on one page wouldn't accidentally break other pages in the site resulting in a lot of regression bugs.
What do other people do when approaching this? Is this a good / bad approach... I do see cons to this approach, some pages are very similar so making a significant change means changing more css code, I also feel that the pro's outweigh this on a daily basis.
What do other developers think about this philosophy? Good? Bad? Just curious really...
To me its one of those situations where I weighed the difference between my ideals (I try to keep very tight code), and the frustration of changing requirements on one page breaking 20 other pages because I changed a div width by a few pixels (upsetting a float on another page for instance).
Thanks for your input
Just like any other type of code, if you are duplicating your CSS code all over the place, you are asking for trouble. Maintenance is going to get harder and harder for you as time goes on.
The best way to not have issues with a change on one page affecting other pages detrimentally is to have a style guide that drives your UI layout and design. If your style guide defintes the HTML and CSS classes to use for a given design element, then they will all always be displayed the same across all pages. If a specific page's element needs to be changed, you change the HTML to use a different class and then build new CSS for that class (and add it to your style guide for reuse). The style guide also allows you to make sure that your HTML is uniform across all developers working on the site, which means even less of a chance of CSS changes causing problems as you do more development.
Another point you need to remember with CSS is that every one of those .css files you create and reference on a page is an HTTP request. If every page and control has its own CSS file, you are really hurting your users' experience on the site by bogging down the total request download time for every single page request. It also makes it less likely for their browser to cache the .css files because the cache has a limited amount of space, so if you keep filling it with more and more .css files, they are going to get dumped from the cache more quickly. Yes, you can combine .css files programmatically in a handler so your page only makes one request per page, but then you have additional server overhead and the caching issue still remains (unless you have a single request for all .css files on your site, which defeats the purpose of what you're trying to do here anyways).
[This question is somewhat related to this question, but the answers are not...]
I have always used relative paths in HTML and scripting languages (PHP/ASP/JSP) to refer to EVERYTHING. I think the justification had to do with 'what if the website gets hosted in some weird subdirectory.' But my coworker has started throwing absolute paths into a PHP site we're working on. At first I was appalled, but then I thought, "why not? We'll never be hosted in a subdirectory." Nowadays, getting hosted in the root is not an uncommon necessity. Is it still necessary to "code" (markup, really) with relative paths? I think it's probably an antiquated practice by now.
Definitely. You never know where your code is going to end up, or for what purpose.
Suppose you build a new version of a site, but to help your users transition, you move the old version to a "/classic" subdirectory. The same often happens the other way around where sites will host a beta version of the new redesign in a "/new" directory.
Building it properly the first time shouldn't be a hassle, and you'll thank yourself for it one day.
Well, it's probably not the end of the world but it's building in a dependency that you don't need.
If for example you ever want to put a number of versions in subdirectories in a test harness, or subdirectories help to work around some other issue (such as combining this with some other app that insists on being in the root), you may find it harder.
Sure, you can probably always work around it in some other way - but the problem is you now have to.
Edit: Killed my opening paragraph as it was based on a miss-interpretation of the referenced article.
I always use an absolute path for the following reasons:
Includes:
1. When you use a templating system, you never know the directory structure that a document is going to have when it's calling the include.
2. If documents are going to be moved around, you can be pretty sure it's going to be the documents themselves rather than the includes. If it is the includes, then they're being moved my someone who knows what going on. Added to this, if it is someone not familiar with absolute/relative path, they'll understand absolute a lot better than relative.
css: (as well as the items above)
1. When editing with Web Developer, relative backgrounds disappear when your style sheet isn't in the same directory as the doc.
2. By spec, when you put something on the 'Net, it should be there for the duration. When I'm building something new, I build it in a new folder, or with a new file name and leave all the old docs alone.
If you're using dynamically-generated pages, dynamically generate your URLs. For example, with JSTL use <c:url>. Not only does this allow you to move your pages in the future, it also ensures that your URLs will be properly escaped (tell the truth: how often do you build query strings with &? if you want the W3C validator to accept them, you need to).
For my personal website, which uses PHP to build pages, I've created several methods: insertPageRef(), insertCodeRef(), and so on, that create valid HREFs. As a result, I don't hesitate to re-arrange my site structure as it evolves.
The case of being moved to a subdirectory is fairly unusual, I'd say. Far more usual is being hosted on different servers: you create your site for testing on "dev.yourcompany.com" then go live by moving it to "www.yourcompany.com". In that case, you need to use relative links for obvious reasons.