I'm looking to try and use codeigniter with different domains all using the same code structure, within the code igniter framework.
The libraries, models and database should be the same across all the domains, the only difference should be the controllers and views that are used.
Preferably I would like to have a setup similar to this:
controllers/domain1.com/index.php
controllers/domain2.com/index.php
controllers/domain3.com/index.php
Does anyone have any experience modifying code igniter to work in this way?
Take a look at the loader class page in the manual and scroll down to the Application "Packages" part. Combine this with the part of running Multiple Applications you should be able to be running multiple sites, with the same models and configs and avoid duplicating your code.
There is a manual page that describes how do you achieve this. Consult with Running Multiple Applications with one CodeIgniter Installation.
The only difference is that it looks like you'll have to duplicate your models/configs as well.
In my experience I need to build a system on a different subdomain, since the default domain has an existing base codeigniter and it was not design to handle multiple domains or subdomains.
And part of my goals are:
use the existing shared core objects in dir config, core, helpers and libraries.
and the existing public dir files, but separate images/mysubdomain/* and other dirs/subdomain/*
And so this is what I have done.
I've modified router.php in the same config dir and made a condition that routed a default controller in a separate dir inside mysubdomain/default if subdomain===true
ie. /controllers/mysubdomain/default.php
With a separate base controller that extends the main Controller inside /controllers/mysubdomain/.
Then mysubdomain are defined (ie models/mysubdomain/* and views/mysubdomain/* in all my controllers in mysubdomain.
and this works perfectly as I need it.
Related
I needed to know which folder is more suitable to host my Rest API in Yii2 template advanced, backend or frontend.
I also saw some examples where developers created a new directory, called it "api" and programmed the API from there, but I don't find much information by developing from this method.
If you know the most correct way to do it, I would apreciate if you could explain me.
That totally depends on your requirements if it is going to be a complete full app or just a single controller with a few actions or a single ActiveController.
But a good way is to keep things separate just like you are using the advance-app and you have the backend and frontend folders so that you can differentiate the code base, and keep the code in their concerned folders, those folders are actually 2 separate applications running separately with their own separate configurations i.e backend/config/* and frontend/config/*, and can share some common configurations like database and others from the common/config/*. Same like that you can create a separate application/folder where you can have all the code base and configurations related to api you are going to build.
You can find a very good reference for adding more apps into your existing application by Yii here on GITHUB which will clear your concept about how to add more apps.
Then you can go to this article by Budi Irawan's Tech Blog which uses the advance-app to add a new application for the API. You will find the directory structure with example models and controllers along with testing them with POSTMAN.
Backend and frontend are also just a folder in the Yii2 advance app with just namespace different, they are different for our understanding, it is not necessary that you use backend for backend purpose only.
So for the API, you can use any of these folders, but it is always recommended to put thing separately like we put backend thing in backend folder and frontend things in frontend folder.
It's totally up to you and your coding style.
i prefer putting Rest API into a separate module, for instance into "common\modules\api". that way i can "mount" the api in backend or frontend via configuration. Also, nice urls are automatically provided, like /api/<controller>/<action> (where api is the name of your module).
One more thing to consider is how to update your api. in case of modules everything is well organized. you could start with "v1" and put your controllers in here, and move up to "v2" with a different set of controllers. so your first api endpoint would read /v1/users, later on you can additionally provide /v2/users.
more about modules here
read "URL Rules" here
I have an existing website running on PHP, MySQL CSS, JS and Ajax.
For future projects, I would like to use the Laravel framework to create new pages or functionality to the existing website... let's say a blog, for instance.
Is this possible?
Is the Laravel framework compatible with an existing website that is not set up using the MVC framework?
The reason is that I would like to make my work easier and more efficient and the use of a framework would be helpful.
Please let me know if you need any other info, I know the question is a little broad.
Thanks,
Justin
yes it's possible but of course maybe with difficulties.
you should put your web files in /views directory, convert your php files to controllers or library files and put your assets in /public directory.
then you can assign routes to your controller and call it form outside of the application.
main job is put your code into controller or libraries. is it possible to split your code into separate logical units? and extract model logic (as php mvc says) from your main code.
so if you have a clean code with good design and minimum dependencies you can think more about it. this could be a good challenge if you go through it cautiously. be careful to not fail and waste your time.
What is the best way to create a single page module for Yii2?
For example using Ember, I will have index.html and assets folder to publish.
I see two ways, one would be to just put the application under web accessible folder, it will work fine.
But what if i want to check access to the application using existing RBAC?
Another way would be to create a module and in default controller have something like
return $this->renderFile('#path/to/index.html');
And load all assets with Asset Bundle.
The problem with this approach is that i will not know the folder where assets will be loaded (it can be solved with afterCopy callback or something, but all this doesn't look nice at all).
Please advise.
Certainly it is a personal choice technique, since control RBAC is manageable level action and does not pose any problem. Once the controller is easy applicarre your organization's access control using a suitable configuration of the Access Control filter.
Alternatively, the fact of creating a module appropriately for these purposes makes it all the better organized and, precisely, modular, beyond the greater complexity in the creation of the various parts in play (module, asset, cofig / main.php) yii2 handles very well and automatically the assets and necessariio not know a priori in the name of the folder where I finish the specific assets (Yii2 find what they need).
However if this is not a 'module' with reusable application characteristics I would opt for the first solution
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.
In every large application there is an ADMIN section.
In such cases, when not using ZF, I usually put all the admin stuff in a separate directory with extra security measures (like adding .htaccess based authentication and/or a second login etc). This also makes it pretty obvious in the file tree what file is what.
How can I achieve the same design in ZF? Or are there any best practices to create an admin section?
Should I do it in the router level (if there is "admin" in the url, then I use a different index.php/ bootstrap file....)
I guess the simplest was just using a controller for all the admin stuff, but I have too much of that. So I have several admin controllers side by side with the regular app controllers. It makes a mess in my controllers directory - which controller is admin and which is not?
I've done it as a module. In addition to the module link provided by Brett Bender see section 12.3.2.2 in the link I provided.
I generally create a separate "application" folder - complete with its own controller and view directory as well as a public directory for static content - for the entire administration system. The Administration usually has different requirements for key things such as access management, and might differ from the actual application in numerous other ways. Therefore I think it's a good idea to separate the source code entirely. Some of the source code can still be common, though. Examples include library folders and database models.
This approach also gives you larger flexibility when deciding where the admin utility should be available. You could use the apache alias directice to put it in a sub directory on the same domain, or put it on a separate vhost. It's all up to you.
You should check out using modules with ZF. You can have a default module to contain non-admin stuff, and an admin module to contain everything administrative. Using a default module will not change your current URLs and the admin module URLs will look like server.com/admin/controllername/actionname/params. This will solve your controllers all being in the same place and getting cluttered. Also, you can subclass Zend_Controller_Action and make a Master_Controller in your models to keep shared functionality. Then just make an Admin_Controller that extends the master controller for shared administrative functionality and have every controller in your admin module subclass that. You can use a similar structure to organize shared non-admin functionality in your other module(s).
Zend Framework - modular directory structure