I have one site completely working for one client , now I have some more clients want same thing replicated for them , Is there any way , that I can use this site as base site , as I plan to access this site from there domain and providing database for each client.
I am using PHP and MYSQL.
Thanks for any support , I appreciate your point of view also in this process. do I have right approach
I have been told that there will be SEO issues if I use one site for multiple domain. I have no competent person available which can direct me on domain name linking. I have www.xyzuniversity.com and 85% data is fetching from database. now i have to create abcuniversity.com and I want that I just create new database and ready to use and I think I can make multiple sites like this , if I succeed
Thanks
You can point multiple domains to the site. You can get the domain name from the server vars ($_SERVER['HTTP_HOST']) and choose you database through that. Make sure you dont have any absolute links.
Put the shared code into a shared directory and give each domain it's own database configuration, so the database configuration is not shared.
Then start your application with the different configuration based on the domain, e.g. by server environment variables like the hostname.
If your design does not support a configuration that can be injected into the application, you need to maintain two code-bases, one for each domain, e.g. in source-code control with one branch per domain.
However I suggest that your code is that modular that it supports configuration for the parts that need configuration according to your needs. If it's not yet, think about coming closer to it and make the changes.
Related
I have seen a lot of solutions that involve using .htaccess. I would like to know a way to create sub domains using only PHP. For my purposes, this also needs to work using non-host-specific mechanics so it would work on most hosts.
All I know is that I would need a wildcard CNAME record that says all sub domains point to x.x.x.x, but I don’t know what to do from here. What I think you need to do is create a folder that contains the code for the sub domains, and I have done this, but I cannot find a cross-host way to link the sub domain with the folder. There has to be a way to do this as I have seen it done, but I can not find a way that meets my needs.
The problem here is that PHP doesn't handle the request coming in, a web server (e.g. Apache or Nginx) does and it's the config for that software that determines where a request goes. Now the good news is that you can have wildcards in your config (at least for Apache and Nginx, YMMV if you're not using one of those), as long as you can access the config file (you'll need root access on the server). There is plenty of information available out there depending on what web server you are using so you can google that part.
Now, assuming you've done that part, in PHP you just need to check what the root domain for the request is. That information is stored in $_SERVER['HTTP_HOST'], so you can use a simple script to figure out which subdomain has been requested and then launch the appropriate script for that subdomain. Something like this should do the trick:
// Assuming request comes from https://subdomain.mydomain.com
$subdomain = str_replace('.mydomain.com', '', $_SERVER['HTTP_HOST']);
echo $subdomain // Outputs "subdomain"
This will capture multiple levels of subdomains as well, so if your request comes from https://sub1.sub2.subdomain.mydomain.com then $subdomain would contain sub1.sub2.subdomain.
Edit after comment
You can't do this with shared hosting. Basically the config panel you get with the host, when you set up a domain or subdomain it's modifying the config file on the server for you. There's no way a host would let anyone access the config through anything other than their control panel for security. It's possible that hosts will have a similar setup to your test server, where subdomains just work as they use wildcards by default, but I don't know that and there's no guarantee of that.
WordPress itself is just blogging software. It doesn't let you set up lots of separate websites with their own installations. What WordPress Multisite (I assume that's what you mean when you mention WordPress) is use a single installation to host multiple "sites", but it's still one installation, one single database. All of the posts, all the pages, they're all stored in a single database and if you got into that database you could easily include a page from one site on another just by editing some fields in the database. It's not designed for reselling or for multiple, completely separate entities. There are a whole host of security risks in doing that sort of thing. It's designed for single entities that want to split their sites up into multiple sites, but where it's all one company, or related companies. Universities with different departments is one example I read about before, each department has their own "site" and the main IT office has a super user that can access all of them as it's on one single installation.
I could do with a little more information on what you're trying to do, but it sounds like you're trying to do something like WPEngine, where they sell hosting space and install WordPress for you. But they have dedicated servers that run scripts that create the config files and install WordPress on your own individual hosting space using their servers. That's known as SaaS (Software as a Service) and from the little you have said seems what you are trying to do. People subscribe to your site and get their own instance of the software you're selling that they access through an admin portal. That's not something they can install on their own hosting, they have to use yours. That's how most companies do this sort of thing.
So I am developing some software in php and mysql. The clients web application is hosted on their server but basically I want an easy way to turn their site off if they don't pay. I wanted to be able to host a say config file on my server that has maybe an array of data that says how long their subscription is good for, what they have access to etc. I obviously don't want to save this information directly on their server because they could manipulate the config to have whatever they want. Their are a number of other things I would be using this for but for the most part these are the most important parts. Also if there is a better way I am always open to any suggestions.
Thanks in advance!
I have a number of different domains where I would like users to be able to select a photo, however I want to photos uploaded/stored on one central separated domain.
Is there a more advisable way to do this?
I've considered using an iframe from the other domain (so they are interacting with the required domain) but haven't tried it yet.
I have also read that curl can potentially do this.
Any other ideas/problems/concerns...
All advise appreciated.
thx
There are a couple ways you can handle this. Here are the scenarios I see.
Scenario A:
All domains are on the same server. With this setup you can actually help your server security by storing the images and other files in a directory that is not accessible by Apache. Then you use PHP to serve the file to the end user through virtual links. Drupal does this with its private file system.
If the users are able to upload images from the other domains then just have all of the domains write the images to the same directory, but then always return the "central" domain's URL for retrieving them.
Scenario B:
The domains exist across two or more servers. With this setup what you really need to do is setup an API where the other domains communicate behind the scenes to send the photo to the core repository domain. This domain saves it and returns a URL for accessing it.
In either case you should really look up CDN technology. Its basically what your trying to accomplish plus a lot more. I would also recommend that in either scenario that you always use the path on the central domain for all the images instead of returning them back through the current domain.
No reason to get iframes or curl involved. Assuming that all these domains are on the same server (or same cluster of servers), there is nothing which requires that a file uploaded using a file on one domain must only be served from that domain. An upload form can do whatever it wants with the uploaded file, including storing it in a location where it'll be available from your central domain.
I would like to know the best way to enable custom domains when creating web applications. For instance, if you look at something like Base Camp, when you sign up for that you create your own 'sub domain' to which you use to login to your basecamp with.
Also, if you look at this like hosted ecommerce sites, you can use your own custom domain instead of using a sub domain of theirs.
Personally I can't see these web applications 'parking' each custom domain on the web apps hosting account or adding the DNS if it uses a sub domain like Base Camp does.
Therefore, the only way I can think about doing something dynamically like this is to maybe use mod_rewrite to redirect everything to a certain script that does the 'routing' based on the url. Then for the customer domains, the customer would just need to add a CNAME for their domain to something like custom.webappname.com which then in turn gets picked up by mod_rewrite and the php routing file.
If this is the best way forward, are there any performance issues with routing all incoming requests via this 'routing file'?
Sorry if im not clear, tried to explain the best I can.
Yes, your solution would be the best way. That is how other sites do it. Rerouting all requests through a central file using rewrite rules incurs a small performance penalty but it is well worth it.
In fact, in most applications you are already paying that penalty anyway. Any framework that uses the FrontController pattern already does exactly this. This includes pretty much all frameworks like Zend, Symfony 1 and 2, CakePHP, CodeIgniter an many others.
It really depends on the web app your working with.
For example we have a hosted CMS, using the cPanel API we do create an actual hosting account for each customer and install about 50KB of files on account creation including a default template, initial set-up script (handles DB install, initial population of data and basic settings amongst other things) and a few basic front end control scripts such as the contact form, in saying this we don't provide access to the hosting account, all interaction is via our web app. In our case this is regardless if a sub-domain or fully qualified domain. Our customers have the option of self-hosting their domain or we will host it, because we have complete cPanel hosting infrastructure it makes no difference to us where DNS is but if the customer has it away from us it is entirely their responsibility.
The reason we have this hosting set up is so customers can upload their own templates, for disk storage management (we aren't interested in being a file server but customers need some space for PDFs, images, etc) and to make sure the content of 1 customer doesn't get mixed in with the content of another. As a premium paid-for service our lawyers recommended a minimum of separate identifiable folders on the server for file storage.
Another example is blogger/blogspot, it is well known they use mod_rewrite for their sub-domains. This is appropriate for them to do it this way otherwise they would have to create a separate DNS zone for each blog at a minimum and this is a pain (hence why we use cPanel), plus you have all your other virtual hosting set-ups.
With mod_rewrite as you will be aware it will use a single wild-card zone to control the sub-domains and the mod_rewrite rule is easy to apply. From there it is simply creating a folder and redirecting requests for the sub-domain to it or directing to the script to control your app depending on what you're doing.
The truth is for an automated system using sub-domains I would use mod_rewrite but for something a bit more complex like a fully blown premium CMS requiring full legal conformity, quota management, suspend, terminate and file removal functions then I would recommend looking at a hosting control panel such as cPanel as a possible solution.
You've got the right idea. You keep a single codebase, running (for the sake of argument) on a single IP. You don't need to worry about virtual hosts, or even mod_rewrite (aside from whatever your application needs).
You web app simply handles any and all requests to that IP (on port 80 or 443, or whatever).
When your application bootstraps in response to a request, it peeks at $_SERVER['HTTP_HOST'], and configures itself for the client associated with that domain name. If not found, it 404s, or whatever makes the most sense.
We are about to begin work on an application that will eventually be deployed many times on one server. I am hoping to build a nice interface so that one of my coworkers can easily create new deployments of this application. The idea is to create a wizard with a series of options that will configure basic properties of each particular copy of the app such as color scheme, domain name, etc. Each copy of the application may be further tweaked independently down the line. I would like to know what is the best way to manage the automatic creation of users, the updating of domain name info and the deploying of copies of an application, with the ability to maintain certain discrepancies between each of these copies (such as installed plugins, different CSS) as we update the application in the future.
What I'm asking is extremely similar to the way StackExchange 1.0 functioned, where a user could configure several options and a customized version of the StackExchange would soon be up and running. How is this accomplished?
One thing you can do is have the web server set a variable based on the domain name and path, and then you can check $_SERVER for the value and choose the configuration based on that. Or if the application will only be run once per domain then just check $_SERVER['HTTP_HOST'].