Display JPG based upon URL - html

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.

Related

Do I need an HTML file for every single page on my website?

Say I have a product website, like Amazon (this is not the case, but it will help me explain my point), and I have a URL for every single product (such as with Amazon)...
Do I need to copy-paste and modify an HTML file for every single individual product page, or is there a way to use a "model" on which I can base all my other pages without recopying the whole code and modifying a few things in each?
I've just started learning HTML and web development, so bare with me if I'm asking a stupid question.
It just seems odd to me that a million-page website should host a million+ individual, nearly identical, HTML files.
Thank you very much in advance.
P.S. I'm using Amazon's brand name as an example here, and am not affiliated with anything related to it. Thank you for understanding.
No, you do not need an HTML file for every single page on your website. While you could do that, it is becomes very infeasible to manage the bigger your site becomes. On most websites you would have the following components:
A front end - consists of HTML code and usually some sort of template engine with placeholders for your data
A backend - consists of your data store (usually a database).
There will also usually be some form of API and/or middleware between your front end and backend.
If you go to https://example.com/myproductid in your browser, your computer will send that request to the web server. The web server will then retrieve your data, load it into the correct template, and serve the page to you.
In traditional HTML and PHP only websites, you would have to reload the entire page each time you went to a new product. However, you can instead use a technique called Ajax to only update certain parts of a web page rather than reloading the entire page. That way you can just update the text, images, and links that are specific to the product, and the rest of the page would stay the same. (Note: Ajax originally used XML, modern implementations usually use JSON).
Ultimately, you will want to learn some JavaScript and then start looking into various web frameworks or libraries such as ReactJS.
Not you Can have only one page for all product, but you have to make it Dynamic.
Yes you need an HTML document for your each webpage, like for Home page, contact us page you need different HTML documents

Are full links when linking resources worse than paths?

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

Hyperlink to specific page or folder with default document?

We are in the process of redesigning our company's web site, and we have been told by consultants that it is important that we either:
1.) Always link to a specific page i.e. foo.com/buy/default.aspx
or -
2.) Always link to a directory and allow the default document to load i.e. foo.com/buy/ where "default.aspx" is the default document
Is there any practical benefit to either approach? Does being 100% consistent in doing one or the other really gain us anything?
In your first example, always linking to a specific page helps prevent ambiguity in your URLs. Prefer a canonical URL (can be with or without a file extension). If you have to have multiple URLs for a single resource, for example /products/product1.aspx and products?productID=product1, then take advantage of the Canonical URL property in your code to specify which is the proper one.
Using extensionless URLs allows you to change technologies later. For example, /blog/post1.aspx is different than /blog/post1.php, say if you ever switched to WordPress (not common, of course, but it happens). It's just an easy way to make the links work no matter the technology. Plus, in my opinion it's always better to, as much as possible, mask the technology stack that you're using where possible. Extensionless URLs are becoming the norm (in my opinion) as people seem to be moving more toward an API-based approach to URIs as resources, and mixed technology stacks.
The second method you mentioned is good because it helps you make clean URLs
(don't click these urls they are just examples)
okay URL
http://www.example.com/example/example.php
clean URL
http://www.example.com/example/ (so much easier to remember, and shorter to write out)
here is a good tutorial I found that shows you how to accomplish this: http://www.desiquintans.com/cleanurls (htaccess)

How to rebuild an entirely static website, without changing URLs?

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

HTML Include: Separate Header and Footer

Can we include an HTML file / snippet from another HTML file?
My use case is related to how a website is built; in a simple form, a site typically has the same header and footer across the board. It is pretty straightforward if the site is equipped with e.g. PHP so you can do something like the include statement; we can contain the header and footer in separate files and include them later. But, what if the site is purely static i.e. no "back-end" support?
One thing that I had done in the past is to utilize templates in Dreamweaver. This worked but I'd prefer something that is more product-independent.
Thanks.
What you're looking for is Server Side Includes. It used to be available on most hostings, no idea what the situation is today.
Actually, a simple system based on a makefile and, why not, php's command line version, might also be helpful: a simple makefile that visits all php files in a directory, feeds it to php (eg, processes page decoration and stuff) and redirects the output to a corresponding html file should be enough to generate a set of uploadable, 100% static html files.
SSI is a great option if it is available to you as already suggested, I have always used PHP personally but as PHP is not available and if SSI isn't available then there is a JavaScript option as well.
The great thing with the JS option is the server doesn't need to have support for it due to the include scripts being client side. The bad thing is if the client doesn't have JS enabled in the browser the includes won't work. In saying that the vast majority of website users have JS enabled and this is displayed by most websites in the world who employ JS in 1 way or another.
Examples, the first one I found with a 2 second Google uses jQuery, have a look at the info here
There are also some AJAX plugins that could potentially be used for this at the jQuery website if it is a path you're interested in going down.
I hope this helps you :-)