I am building an application on top of the CodeIgniter framework. This will be a personal CMS for my company's projects.
What I would love to do is keep the application separate from the folders that our clients are able to access for our website. Essentially, I'd love a layout as follows:
/applications
/system
/public_html
- site1.com
- site2.com
- etc
When someone hits site1.com, it would use site1.com's DB config to pull in the settings and information that I have outlined for that website, but access the application from the applications folder.
Obviously, this is back a few levels from the domain, and I've run into issues with that kind of layout before... I'd love for the user to only have to worry about the following in their folder (for now):
/site1.com
- db.php (config file)
They would update the db.php with their information, and when someone visits site1.com, they will be served up the application from the applications folder with the settings pulled in from their db. Eventually, I'll add a way for them to upload views and assets unique to their website as I build out the application to allow those things.
So...
What is the proper (and best) way to go about doing this, while maintaining ONE framework for my application that I can keep on my server?
Additionally, if you'd like to give some helpful input, what are the advantages and disadvantages of doing something like this?
Thanks!
Old but still relevant -> http://philsturgeon.co.uk/blog/2009/06/How-to-Multi-site-CodeIgniter-Set-up . The base idea is to have the same codebase for every domain.
Related
Essentially, I'm looking to have a PHP development workflow that needs to be modular, but using a Single Page Application technology.
I understand it is recommended to separate the back-end from the front-end. Develop them separately. But is there a way to group all related code into one module (or folder), meaning all backend code with its own views presentation inside the same folder?
It's like MVC, but the "V" contains fragments of vuejs (or angular) files, which extends from a master file somewhere in your project.
For example
Assume we are building a modular CMS, where you can upload "plugins" (really, PHP modules), extending the CMS' functionality:
-project[root-folder]
----core[folder] # contains all infrastracture code, api routes, master view file, magic, etc.
----modules[folder] # uploadable modules goes here
--------User[folder] # sample module; follows the MVC pattern
------------Controllers[folder] # contains files, e.g. UserController.php
------------Models[folder] # contains User.php
------------views[folder] # where vue components is housed
----------------users/index.php # contains vue code
----------------users/create.php # etc...
----------------users/js/user.js
----------------users/css/user.css
--------Blog[folder] # another module
----index.php # the master view or just the bootstrap file
----gulpfile.js
Then inside the core/ folder, there is a master layout that binds all views together.
Will a folder structure like this be viable?
Obvious problem there is you can't use .vue files (as that would mean, every time you upload a new module, you need to run gulp or re-compile).
Hoping for your feedback. Thanks.
This question will strike a lot of folk as bizarre and twisted. That's the reaction I got when I asked it in the context of .net mvc. I'm with you 100%.
I'm too new to js frontend development (and too ignorant of PHP) to have much advice. It's going to be tricky. Ajax calls to PHP code will need to go to paths below the src directory. But then you want to stop your frontend resources being served from these same paths. Both PHP and gulp will want to use file paths for urls, but at least for Gulp this can be controlled.
I'll follow this with interest. My ambition is to keep in the same folder things you're likely to want to delete together, and for those things to be able to call each other with short, relative paths. The ideal would be to be able to specify the module route independently of the path on disk, and to have this route work for both frontend bundled resources and services. Good luck !
I came across this question whilst searching for an approach for exactly the same problem. I'm building a "platform" rather than an application with a plugin system along the lines of Wordpress. I have the additional issue of the platform itself being a 'multitenancy' environment, too - so any plugins cannot interfere with the core "Dashboard" that holds these things together.
So; posting for a few reasons, two years on...
Did you get anywhere and would you care to share any thoughts?
I came across a quite extensive article for PHP Phalcon that has certainly given me a few ideas. Sharing incase it helps you/others:
https://blog.antsand.com/singlepost/index/5619/How-to-integrate-php-(Phalcon)-and-Vue.js-components
There's a line buried in the series that says "As a rule of thumb. Structure your code, based on the application and NOT on the programming language and frameworks." I'm not sure how wise or not this is, but it certainly gave me something to crack on with.
So right now, I have a module folder a bit like:
/mymodule
/Controller
/Model/
/Template
thing.vue
/Assets
/js
/css
MyModule.php
Assets are handled via a framework route (i.e, /assets/{path:.*} )
Templates are handled via the (PHP) module install script to make sure webpack knows where they live.
Still at proof-of-concept stage but rightly or wrongly, it seems to work well enough!
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.
I have my main site kansasoutlawwrestling.com which will be using Codeigniter, and then I am also creating a CMS for myself that is a separate entity which will be located at kansasoutlawwrestling.com/kowmanager.
My CMS will use different CSS, javascript, and image files, so I'm wondering if I should just have two different installs of CI. I tried looking at PyroCMS, but there's way too many folders and I was having a problem understanding its file structure. What is the proper set up for this is?
The basic structure of Codeigniter is that you have 2 folders and 1 file in your root folder:
root/application/
root/system/
root/index.php
Now, obviously, you might have many more files and folders in there as well, but these are the basics upon which every Codeigniter app runs.
What do each of these do? To begin with, every page request starts at index.php. This page set's up some configurations and some constants, and then hands over the reigns to Codeigniter.
Where is "Codeigniter" located? That would be the system folder. This folder should never be touched, by you or anyone else. Everything pertaining to your app is stored within the application folder. This includes all your configurations, your controllers, your models, your views, even your library extensions (although you could store other stuff outside this folder, like images/css/js/fonts etc.).
So, the correct way to set up shop would be:
root/application/
root/system/
root/index.php
root/kowmanager/application
root/kowmanager/index.php
But, you have to inform your kowmanager's index.php that the system folder is not located in the same directory. So, within the index.php (inside of kowmanager), at around line 25, you should see this:
$system_path = "system";
Simply change it to:
$system_path = "../system";
and you're done.
Now both your apps (your main site and you CMS) will be sharing the same Codeigniter base. When the time comes to update CI, you'll do that once within the main system folder...
I've done several Codeigniter CMS's and taken both routes:
Integrated (shared application files and assets)
Separate installation (only shared system files, if any)
At first I liked the convenience of the integrated approach: when I needed a custom library or icon file for the front and back end, it was available without duplication. I've since changed my mind.
My opinion now, after 4 years or so of working on these, is that the benefits of having an integrated CMS is short-lived.
90% of the code is in the back end, so you end up with lots of helpers, libraries, etc. that are only used for administration.
Any shared resources that you need to tweak can end up working great on one side, but breaking the other, or being overkill/useless.
Models tend to be bloated for use on the front-end when they are full of code that's only used for the back end.
Shared templates, js, and css files almost never work. The control panel probably doesn't need to work in IE{insert version here}, but your front end should.
It makes updates and upgrades to either end sketchy, unless you know exactly what you need to update and what not to touch, and where you may have made customizations for a particular site's front end that should not be altered.
Auth logic is much easier when your admins and regular users aren't in the same bucket
Separate installations are easier to set up, and they can be "tacked on" to an existing site rather than having to integrate it.
My advice: Go with a separate installation.
If I were you, I would probably not go the separate applications path. If you're sharing things like code that renders a page or logs a user in, you'll be repeating it for both installs. Obviously two separate installs would only require one system folder of which you'd share as nothing changes in system. If it were me, I'd probably just set up a route in your config/routes.php file.
Something like the following (presuming you have a controller called 'kowmanager' inside a folder called 'kowmanager' in your controllers folder):
// This would redirect all calls to kansasoutlawwrestling.com/kowmanager
// to the kowmanager controller.
$route['kowmanager'] = "kowmanager/kowmanager";
// Redirects all kowmanager/method requests to the kowmanager folder
// and a particular controller
$route['kowmanager/(:any)'] = "kowmanager/$1";
// Redirects all kowmanager/method requests to the kowmanager folder and a
// particular controller and method inside controller.
$route['kowmanager/(:any)/(:any)'] = "kowmanager/$1/$2";
Might not be the best option, but it means you won't repeat the same code twice and you've essentially created two applications inside one. There are numerous other ways of doing this including some rewrites in your .htaccess file.
If you want the easier option, go separate installs and be mindful of code repetition. Stick to the DRY (Don't Repeat Yourself) methodology.
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