3

I have multiple sites that share a lot of the same files. Sorta like:

  • CoffeeBeansForSale.example
  • CellPhonesForSale.example
  • ComputersForSale.example

They will end up using a lot of the same code / files so it would make sense for both to point to the same info on the server so if I, for example add a new font or update an order form, it wouldn't require updating it on 50 sites. What would be the best way to set this up on the site?

I know in PHP I can create a 'common_site_files' directory and just do an include('/home/mysites/common_site_files/fonts.php'); in PHP. But with HTML it won't really work.

So what would be the best way to set up the sites / directories so I can save myself hours of work in the future?

Improve this question
4
  • 2
    So why not do it in PHP?
    – Steve
    Commented Aug 26, 2022 at 7:13
  • 1
    I don't think this is really appropriate here. I agree with Steve that PHP is likely the best way to go . I'd add that if you separate your CSS from your HTML, you can update styles by calling a common CSS stylesheet, even if you need to add the common one and then a second one with overrides for it. You may be able to do some templating with HTML add-ons, but once you have done that, you may as well use PHP. You could also write placeholder variables and script substitututions - but again, PHP is easier...
    – davidgo
    Commented Aug 26, 2022 at 9:43
  • Node.js + Handlebars would be my choice
    – Mike Ciffone
    Commented Aug 26, 2022 at 12:53
  • Doing it in HTML is impossible. Something like <img src="CoffeeBeansForSale.com/../common_site_files/images/order_icon.png"/> doesn't work in HTML.
    – Robbie
    Commented Aug 26, 2022 at 17:01

1 Answer 1

Reset to default
1

If you really have only pure static files, at least Apache has SSI or "Server Side Includes" with an introduction at https://httpd.apache.org/docs/current/howto/ssi.html which do as it is named, you can compose files on server by including one into another.

I wouldn't necessarily recommend doing that. Because it is still some CPU burnt at each page retrieval, for something, if purely static, that can be pre-computed once for all.

Instead, more probably I would see you should pre-generate your files, again if they are purely static. You can store them decomposed and then with the magic of some scripting and stuff like Makefile you generate the final files out of the source content.

They exist various frameworks for static website and CMS that work that way. Lots of them. I don't have personal experience with any of them, but at least names that often come on that topic are Gatsby, Hugo and Jekyll.

Pre-generating the files in advance though has the advanced benefit that the results are pure HTML and can be served by any webserver. When you are using a static engine, you may need to install specific stuff on the webserver for final rendering if there is no way to render pages in advance.

But if by

They will end up using a lot of the same code / files so it would make sense for both to point to the same info on the server

You mean absolutely the exact same content, then you even don't need all the above, Apache allows having multiple names/ServerAlias statements, in order to tie a specific configuration including DocumentRoot and hence files served to multiple hostnames. If you have an order form calling some other URL with a CGI, that script can itself consult Referer or something added by Javascript running on the client side that would specify which of the hostname it was running on, so that you require only a single piece of code/back-end to fuel all your different front-end dynamic needs.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.