Our main website uses symfony 1, and by the time I started working on the code it seems impossible to upgrade (too much custom code from previous developer). Now we are adding a large addition to what the company offers. Instead of using a really old framework I wanted to use CodeIgniter, also since I'm very familiar with it. My real question:
What is a proper way of setting up a website to use multiple frameworks. The new features will be separate from the original website, but it will still need a few tables of the database.
I was going to have apache handle where the root directory was depending on the url and just do everything normally. The main website is example.com and the new feature will be abc.example.com
I'm really looking for people who have done this and some tips and warning they had.
PHP will run the framework based on which directory is loaded on the server. For instance, on most apache servers the root directory for example.com would be /www. Which means all of the code for Symphony would be in /www/*.
When you setup the path of your subdomain, just put it outside of the /www folder. Then, when you go to abc.example.com apache won't try to load the original site along with the Symphony framework.
I think it will be fine for both frameworks to share the same database tables. I'm not entirely sure how you plan for these two applications to work, but as long as you don't change the column names and types you should be okay.
If you don't want the applications to share the data in the original table, then look into using mysqldump or something of the like to copy the data over to a new table.
Related
I'm having a big problem trying to find a way to structure my application for scaling. Below is my current setup:
We have an application written in PHP and MySql. The app is written in such a way that it can, in theory, serves thousands of different websites using the same codebase (but each will have different database).
In our current setup, we have 1 nginx config file per 1 website, all of them pointing to the same location lets say /var/www/current-version. We have a way for us to know which website is supposed to be rendered.
Each time we upgrade, we update code to /var/www/new-version
Copy all code from /var/www/current-version/ to /var/www/old/
Point all current projects from current/ to old/ by search and replacing all nginx config files and the do a service reload
Copy code from new/ to current/
Loop through the websites to
edit the corresponding nginx config file to point to the current/ folder
sync the new updated config files across all instances
run update script (we have to do this because the upgrade process may involve migrating db and several other things)
This upgrade process involves quite a few steps and is subjected to certain issues such as when the sync does not happen fast enough.
I wonder if there is any better way to do this?
PS:
I'm not sure if this is the best place to ask this kind of question, stackexchange has too many sub-sites and I'm confused. Anyhow, please feel free to let me know if I post in the wrong place
Why not just to use symlinks? For example, all nginx configs are set up to /var/www/website, that is a symlink to /var/realdir/website_1_1_0. You deploy a new code to /var/realdir/website_1_2_0 and after it just change a symlink to point to this new directory.
I'm having a bit of an application structure design dilemma.
I have created a web app that creates online surveys. It all works fine, but I would now like to create a new site that does different types of online surveys. This new site will be pretty much 95% similar in terms of layout, logic, functions, etc.
Rather than duplicate all the code from the current web app, I'd like the new app to share in the "fountain of knowledge" created by the current app - so to speak.
Can anyone enlighten me with their experiences of doing this sort of thing? Their best practices?
As a rough guide, I'm currently thinking of using symlinks for all the major logic files (library.php, functions.php, etc), and then deciding which logic to use based on which URL the user logged-in from.
Does that sound like a good or bad idea?
Would it be any better or worse to divide the whole system in to 3 sites, with the site in the middle containing all the common elements and logic? This middle site would have no independent use - it would be used from either of the 2 applications looking for functionality and assets, etc.
Any help and experience on this matter is very much appreciated indeed.
I'm very wary of going down a dead-end solution.
Kind Regards,
Seb
Good solution if:
you host your website yourself and creating symlinks between differents virtual hosts is not a problem
you won't have to make significative changes between the 2 websites
But instead of using symlinks, I could take advantage of PHP's include_path directive and put the common libraries in this path. This way, just write your includes relative to this path, the files will be accessible from any site you want on the same server.
The second advantage of using include_path is you can bypass any open_basedir directives which wouldn't allow you to include files which are not in the same virtual host base dir.
This is how I'd do it...
Create a core library.
Create you 2 site directories.
Create site specific code folders in
each site.
Create core library folders in each
site that simlink to the main core
library created.
Basically, lets say i have a webserver and i resell hosting specifically for local churches.
i have 5 churches as clients, i have a simple CMS made for them they are equal copies of the same files, for each website i install the CMS , database and the website, i think it's a waste of resources.
i would like to know if i can do the following, afaik most webhosts have the following structure:
A main directory (home)
www.church1.com (church1)
www.church2.com (church2)
www.church3.com (church3)
www.church4.com (church4)
www.church5.com (church5)
basically i want the CMS to be on the Home directory, and each one of the Churches (clients) would only have a Config file, a Database ant the template regarding their websites.
so the system source code would be shared, but the website design and the database files would be completelly separated.
i'm not a webhosting or a development expert, but i know my way around, i'm sorry if the question is too basic, i'm having a hard time finding if this is possible.
EDIT: I Think Rudu's reference pretty much solved my problem!
Since you are building it yourself, put the include files (application logic) in a folder or include path that is accessible to all the domains. Then you can put your template files, images and stylesheets in the individual domain folders. If you are database driven you can check the domain $_SERVER['HTTP_HOST'] and load results from a certain table or database based off of that. You really can go a lot of different directions here if you are building it yourself.
It is possible - the answer. Exactly - there are some settings ( and now i dont remember them ) that can block it - but set up in all sites that libraries are there and be happy
We have a custom PHP/MySQL CMS running on Linux/Apache thats rolled out to multiple sites (20+) on the same server. Each site uses exactly the same CMS files with a few files for each site being customised.
The customised files for each site are:
/library/mysql_connect.php
/public_html/css/*
/public_html/ftparea/*
/public_html/images/*
There's also a couple of other random files inside /public_html/includes/ that are unique to each site. Other than this each site on the server uses the exact same files. Each site sitting within /home/username/. There is obviously a massive amount of replication here as each time we want to deploy a system update we need to update to each user account. Given the common site files are all stored in SVN it would make far more sense if we were able to simply commit to SVN and deploy to a single location direct from there. Unfortunately, making a major architecture change at this stage could be problematic. In my mind the ideal scenario would mean creating an account like /home/commonfiles/ and each site using these common files unless an account specific file exists, for example a request is made to /home/user/public_html/index.php but as this file doesnt exist the request is then redirected to /home/commonfiles/public_html/index.php. I know that generally this approach is possible, similar to how Zend Framework (and probably others) redirect all requests that dont match a specific file to index.php. I'm just not sure about how exactly to go about implementing it and whether its actually advisable. Would really welcome any input/ideas people have got.
EDIT AllenJB's comment reminded me that we have previously explored AliasMatch as a potential solution to this, we ended up with an general.conf file for a user that looked something like this:
php_admin_value open_basedir "/home/commonfi:/home/usertes:/usr/lib/php:/usr/local/lib/php:/tmp"
php_admin_value include_path "/home/commonfi"
AliasMatch (.*).php /home/commonfi/public_html/$1.php
AliasMatch (.*).html /home/commonfi/public_html/$1.html
You can set this up via the Apache configuration - you probably want Alias, but there are several options:
http://httpd.apache.org/docs/2.2/urlmapping.html
You certainly can build a "cascading" system as you describe (load local file, if that doesn't exist, load global file). The complexity is that the files are loaded in different ways (using include() in PHP, through the web, ... maybe even more ways?)
Filesystem includes
If the includes/ consist of files containing one PHP class each, you could use an autoloader like Zend Framework does. The autoloader would look first for a custom version of the include file, and if it doesn't find one, include the global version instead. I happen to have such an autoloader handy if you need code to start with.
If the includes don't match the one-class-per-file structure, you would have to build a custom include() function that fetches the local version of the file or, failing that, the global one.
Pseudo-code:
function fetch_path($name)
{
if (file_exists(LOCAL_DIRECTORY."/$name")) return LOCAL_DIRECTORY."/$name";
if (file_exists(GLOBAL_DIRECTORY."/$name")) return GLOBAL_DIRECTORY."/$name";
return false;
}
Web resources
The second part is going to be the web part (i.e. Web URLs with local or global files). I think this should be pretty easily solvable using the -f switch in a .htaccess file. You would build a rule that rewrites failed requests (!-f) to the local web resources directory (example.com/css/main_stylesheet.css) to the global one /home/commonfiles/public_html/main_stylesheet.css). You would need to fiddle around with Apache's server config to be able to rewrite local requests to the commonfiles directory, but it should be possible.
That is maybe worth a separate question.
I run multiple websites all running off of a single installation of CodeIgniter on my server (separate application directories and a single system directory). This has been working fabulously and I don't see any reason to change it at this point.
I find myself writing library classes to extend/override CI all of the time and many times if I find a bug or improve effeciency I have to go back to several websites to make the same adjustments at risk of a typo that breaks one of the websites. Because of this it requires that I change each file and then test that site for bugs.
I have been pondering a solution of using a single libraries directory in a central location and symlinking all of my websites to that central directory. Then when I make a file change it will immediately propagate to all of the downstream websites. It will still require that I test each one for errors, but I won't have to make the changes multiple times. Anything that is specific to a single website will either be a non-shared file (still in the linked directory just not used elsewhere) or can be put in a local helper.
Also, I keep separate 'system' directories by CI version so I can migrate my websites independently if necessary--this central libraries file would be attached to a specific version to reduce possible breaks.
Does anyone see potential issues or pitfalls from taking this approach? Has anyone accomplished this in another direction that I should consider?
Thanks in advance!
I think this actually makes sense :] Go for it. Even on official CodeIgniter page, they mention it's possible.
Also, I don't see one reason why there should be any problem.
Edit: they touch the problem of multiple sites here: http://codeigniter.com/user_guide/general/managing_apps.html
also:
http://codeigniter.com/wiki/Multiple_Applications/
http://www.exclusivetutorials.com/setting-multiple-websites-in-codeigniter-installation/
How to Handle Multiple Projects in CodeIgniter?
http://codeigniter.com/forums/viewthread/56436/
I have a single system directory and separate application directories for my CI apps. In order to share libraries and some view templates between my apps, I have created a "Common" directory, in the same folder as the CI system and with the same structure as a regular app folder and used symlinks, but you can modify the Loader class so that it looks in the Common folder too. My setup looks something like this:
/var/CodeIgniter/
/var/Common/
/var/Common/config/
/var/Common/controllers/
...
/var/Common/libraries/
...
/var/www/someapp/
/var/www/someotherapp/
...
I'm not sure how you handle publishing your sites (assuming you actually do any of that), but I'd look into version control. For example, in SVN you can make external to another svn directory (or file) and then just update the current svn directory which grabs the external file. This approach gains one benefit from the others, which is when you modify the common library, the others aren't immediately affected. This prevents unwanted breaks before you have time to go test all the sites using the common library. You can then just update each site's folder whenever you are ready to test the changes. This is "more work", but it prevents code duplication AND unwanted breaks.
I wrote a MY_Loader to do exactly that.
http://ellislab.com/forums/viewthread/136321/