I'm developing the online presence of a new sporting league. The web presence will consist of the organisation's information site (think the NFL website) and then individual team sites.
My idea to achieve this was to pick a framework like Zend Framework, and then have two applications (main site and team sites application). When a visitor accesses the organisation's domain the request is handled by the organisation's application code, and when an attempt to access any of the teams' domains (they could be dozens) the request is sent to the team sites application code, and the skin is switched depending on the domain accessed via.
The reason I want all team sites to run from the same application code is, if I added a section (for example, roster) then I'll want that on all team sites. There's seldom going to be an occasion where a team is going to need an individual page, but I'll handle that when I come to develop the CMS.
What I need is just a helping hand on how the above scenario would work with Zend Framework. I have one Zend Framework library that I'd like to use for both applications (which is in my include_path) so would just like to know how the requests would be routed and the framework would be set up to handle this situation?
Thanks in advance.
EDIT: I should also mention that I'd like the share the models between the two applications. For example, the individual teams sites may feature profiles of players for that particular team, but the organisation site may offer profiles of every player.
Putting the ZF libs into the include path is basically all you need to do to share ZF between applications. You can share any models the same way. By putting them on the include path.
What you describe above doesnt sound like it needs multiple applications though. If all that varies is the site theme, then you can serve that all from the main application. Add a custom route that can detect when its a team site. For instance, when team sites are available at their own domain, map the domain name to the theme folder and apply any necessary filters to limit the player profiles.
An alternative would be to make the main application a consumable webservice. The other applications could then use the main application's API to fetch the appropriate player profiles.
Related
I have a SAAS in production and I want to give the customer the option of having a custom domain.
The application is in PHP without any javascript framework.
I would like to know the best ways to set up so that it is practical in terms of scale and implementation.
The operation should be as follows:
MAIN APPLICATION
myapp.com/company/product/clothes
The client will be able to navigate through the page through his domain as well, but everything being consumed from the main application without code duplication.
Customer domain example
companyapp.com/product/clothes
I currently use a shared hosting that contains WHM/CPANEL.
I've been working on a site (for my company) to allow selected data center users to remotely access a scheduling calendar and some pages offering information on the various servers they are coming to the site to access--on a separate site. Initially, I was under the impression that I'd be creating a database and registration page to add, authorize or track end users. My initial project coding has been a combination of HTML, PHP, CSS, and MySQL and Apache for the database side. Now I've been told that we will be using AD, tied into our company's official Active Directory, so that users can use the same IDs and passwords that they've already had approved by our company.
My question is (hopefully) simple. Is there a certain web programming language that I should use in creating the pages that works better with Active Directory than others?
If you are comfortable with PHP, you should be able to achieve the above no problem!
The beauty of PHP is that someone somewhere along the line had the same problem as you so chances are, there's an established solution already.
adLdap seems to be a good solution, a library that already does most of the hard work for you and all you'd need to do would be integrate it into your script!
See: http://adldap.sourceforge.net/wiki/doku.php?id=documentation_user_functions
Hopefully this can make it a little easier for you so you can concentrate on the other things like the actual functionality of the website itself.
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.
I am developing a web app and want to be able to stagger the deployment of new builds and versions across our users. For example...
Deploy new version of app and migrate a couple of test accounts to it for testing
When testing is happy, move say 5% of customers to the new version and monitor support problems and server load problems with those customers.
if it is still going ok, gradually move more and more customers over to the new version until everyone is updated.
Fogbugz and Kiln from FogCreek are using a deployment system like this. You can read about it here...
The problem I am trying to solve at the moment is that different accounts on the system can be using different versions of the code.
What is a good way of managing and controlling this? Can Apache do some of the heavy lifting here? I want to avoid too much overhead, or weird loader scripts to work out where to send the request. How do web apps like Fogbugz on Demand deal with the problem? Is there a recognised design pattern for this?
The users are identified via a domain name (eg user1.example.com, user-bob.example.com, etc).
There are easily hundreds of ways to accomplish this; so let's think at a high level without talking specifics of the architecture:
Large public sites like Yahoo and MSN handle design changes with random samples and set cookies with long timeouts to identify who should be receiving the new design.
For paid upgrades and beta invites you should be able to identify and tag which customer accounts will receive the new 'design' or feature set upon their login. For instance, the new updates to Digg v4 were for logged-in and opted-in customers only. Facebook had a similar rollout across their system with the new profile pages.
You may decide to pay for beta testers. You can easily use Amazon's Mechanical Turk or sites like custfeedback.com
The specifics will be up to you and your architecture. Hopefully you've written your software with this functionality in mind; and hopefully you've provided easy ways to provide both application and database upgrades easily at deploy time. Magento (an open-source e-commerce platform) handles this very well. Each module is built in a form of a plugin and each of its components keep record of their own version. Database upgrades are performed on the fly with install and upgrade scripts based on the new/future version retained in configuration files.
You may choose to move your beta testers to a new domain or database that has more detailed logging and realtime analysis than your production machine. This was the method mentioned in the Kiln blog post - they referenced the site http://martinfowler.com/bliki/BlueGreenDeployment.html - eventually, however you accomplish the segregation of your accounts and traffic, you eventually have to consolidate. You'll need to perform your migration in a maintenance window most likely and get everyone up to the same version.
Best of luck!
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'].