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.
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!
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 am developing a website which has two phases - front end for public users and back end for admin panel like all other websites have usually. I want to know that should i have to create separate includes and classes folders for front end and backend (under admin folder) or should i use common folder for both areas? The front end files are put at root level. There is another folder called admin which have all admin files and folders inside it. So if i create classes and includes folder in it (under admin folder) and use the same folders for using in front end also then would it be wise? Continuing with the same thoughts should the db configuration files be separate for both ends? How do professional do the same?
EDIT -
I am doing the project in core PHP and no framework is there. Can you guide me better professional directory structure?
It is better to use the same folders as there would be many common classes and includes in both levels of your site. This makes things easier to manage.
You might put 'admin only' classes in a subfolder so that you might distinguish them properly.
I think you should use MVC approach for this matter
and I think it depends on kind of work your doing, I don't think it matters that much.
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/
I’m new to CodeIgniter, I was wondering if it’s considered a good practice to restrict direct access to your view-files? Obviously they are going to contain a lot of php-code that relies on variables and what not passed to them from the controller, so the php-code could easily come up with an error if it’s directly accessed couldn’t it?
Bonus question: Why are the helpers, libraries, hooks etc. folders empty in the application folder?
Thanks for your time.
The main reason nobody bothers to restrict access to their view files is because they will either fatal error or show a useless page.
If people want to go to the effort of trying to work out your folder structure and file names, they will be rewarded with... absolutely nothing. You would have to write some really crazy code to make a view insecure.
If you REALLY want to secure them, go ahead.
At the top of your view, enter:
<?php if (!defined('BASEPATH')) exit('No direct script access allowed'); ?>
<h1>Whatever</h1>
I have never seen anyone restrict access to view files, but i dont see any reason why you wouldn't be able to do so. For better security you should really put your system and application folder below the web root and point the index.php back one directory to those folders. That way the possibility of someone directly accessing your files is slim to none.
As for why the folders are empty. The application folder is where you put YOUR code. The helper, libraries, and models folders in the system folder are filled with source code. The goal is to only put your code in application so when you upgrade to future versions of CodeIgniter your dont break any code or functionality you have implemented. You also can overload the codeigniter functions by doing what is says here...
http://codeigniter.com/user_guide/general/creating_libraries.html
and scroll down to "Extending Native Libraries"
user,
if you are on a shared host and they don't allow access to anything else than wwwroot folder, you can create a subfolder (name it "private") and write its .htaccess file to deny all requests to this subfolder. Then you can place the system and application folders of codeigniter in this subfolder and place your index.php folder in the regular location (changing the "system" and "application" variables inside index.php to correctly reflect the new paths) and that way all code is secure from direct access. :-)
edited:
About the folders question, its a scope thing. The helpers, libraries, hooks application folders are for application specific items. Maybe ones you custom create, or maybe ones downloaded from a third party. But the idea is that you have "system-wide" items and then you have "application-wide" items. Having application folders allows you to extend system-wide items to meet the specific application needs (see more # http://codeigniter.com/user_guide/general/creating_libraries.html). This doesn't make too much sense with one application, but if your installation has multiple applications, thats really where this comes in handy.