I wish to use codeigniter NOT as a framework for building a site, but simply as a backend to handle some php stuff (eg. db in/out, image manipulation, file writing to the server).
In the default download of CodeIgniter3, there are 3 primary directories (application, system, and user_guide). Most of application is roughly empty, other than application/config; and user_guide is surely unnecessary.
So what parts of CodeIgniter3 are needed such that it is functionally complete?
TL;DR: All of it
If you want to use just a set of a framework's components, CodeIgniter is not the right pick.
Long answer:
In theory: it should be just system/core/
But most of that code assumes that you have constants defined in index.php, that you do have an "application" directory (containing "config/" and "views/errors/" subdirectories).
A lot of it also depends on language translations, for which the defaults are in system/language/, so you need that too.
Some badly written parts may also depend on a particular system/libraries/ or system/helpers/ component.
So while we started with just system/core/, you now need all of system/ and at least some of application/ (though that can be renamed to something else).
CodeIgniter has a monolithic architecture; it is simply not built in a way to allow you to do what you're asking for.
And those are only a few kylobytes of files anyway - it's not 1980 and that's not a problem; unless you actually load the extra components that you don't use, they wouldn't get in the way.
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!
I'm writing a web application and I would like to know how to initialize all constant (such as db connection data, directories etc), classes and so on.
I read about bootstrap file but I'm not sure I understand the technique ( more details here: https://stackoverflow.com/questions/9774105/htaccess-and-bootstrap-file).
A more specific case would be better. In this case, your question on settings, there are different approaches. Generally a config file is most used in projects. That way it can easily be excluded from version control systems.
Bootstrap files are not the location to store settings.
So bootstrap load the config file and following to that the bootstrap initiates the system.
Generally a config file is the most accepted choice.
For paths there are different parts. You have in-app paths. Keep them in your code, your system should be able to find the right files. Might be done with a PHP Autoloader for example.
Then you have paths to resources like images, pdf files and other data. Keep that part strongly separated from your application. Preferably via a class which handles all those files. That way you are free to move them to another server, move them to Amazon for example when your project grows etc.
So don't try to hardcode paths and keep things separated.
I'm trying to find a guide on PHP file/folder structure conventions.
I'm using GitHub and want to ensure I'm following a standard convention as to not confuse users.
Any help would be appreciated.
As speshak said PHP has no standards and no conventions (including its own standard library).
However:
In public directory (usually public_html) store only static resources (images/JS/CSS) and one PHP file index.php which is limited to something like this:
<?php
require '/path/to/app/outside/public/html/start.php';
$app = new App();
$app->run();
Application itself should be stored outside public directory.
File structure might reflect classes names, so: Project\Util\XML\Parser will be stored within /path/to/the/project/Project/Util/XML/Parser.php file.
Of course 3rd-party-code might be stored in separated folder, let's say vendor - that's quite common convention.
There is this:
https://github.com/php-pds/skeleton
Based on data collected from various open-source projects, this document proposes a naming convention for a number of root-level directories designated for various common purposes, as well as naming conventions for root-level documentation files.
I didn't find that this covers every imaginable scenario, but it's nice to be able to point at this and indicate you're making an effort to achieve some consistency across projects :-)
You are free to choose any directory structure. But if you would like to know about best practices, take a look at how it is done in frameworks, for example, symphony.
Take a look: http://www.flickr.com/photos/deia/402335716/
Here's few of them:
All the code that is included, should be put outside of the document root.
HTML templates should be in a separate directory.
Libraries and classes should be in 'lib' directory.
Mostly it's just a reasonable solutions, not strict conventions.
I think the most obvious one is your libraries. You should name your classes like YourCompany_Module_Class, if you want to be compatible. Using this standard, your libraries can be used along with any other similarly named libraries without clashes and problems. The new namespacing in PHP 5.3+ helps more in achieving this. You can have some guidelines for this at Zend Coding Standards - File Naming and at PSR-0 Standard Proposal.
Other than that, you'd better constantly keep the future in your mind and plan your folder structure accordingly. For example, let's say you are uploading images into user_images. Ok. But what happens when the project catches or gets bigger and now you have tens of thousands of files in a single folder. You must build some scheme that enables you to store ~1k images per directory at most like 12/56/154.jpg.
You will see many such problems and opportunities over time. But you can look at the current projects and learn from them for free :)
PHP really has no standard. If you are making use of some framework (eg CakePHP, Zend Framework, etc) it may impose some standard on you.
If you aren't using a third party library that forces a structure, just use common sense. (Put images in a images directory, included files in an includes directory, etc) People that download and install PHP apps will already be used to each app doing things differently. The fact that you're giving it some thought puts you a head of lots of the competition :)
I can't find much information about Yii's AssetManager for the management of JS and CSS files. My question here is what is the point of using the AssetManager? I'm not sure what value it adds to my development process, in fact, it seems like it complicates my code... every time I change my scripts or css code, I have to go in and delete my assets folder to make sure I have the latest versions.
Seems it is much simpler to just put all Javascript files under /webroot/js/ and just use the tags to load the files instead of going through the trouble of AssetManager. Plus, Yii's registerCoreScript function always places script tags inside the header tag, instead of placing them at the bottom of the code, near the closing body tag, as recommended by YSlow.
I think there must be a gap in my understanding of Yii's AssetManager. Anybody have any ideas why using the AssetManager is better than hard-coding the script tags inside the PHP code? I'm a bit confused...
Thanks!
I'm sure someone can answer this better than myself, but basically it's so that your source JS and CSS files can remain in your Protected folder.
This is a little more secure for one thing, but the main benefit to me is that you can compress and minify and otherwise process your assets with the asset publishing system, and it makes it easier to host your JS and CSS on a CDN since it's separate from your codebase.
Also, here's an official response from qiang (the guy who wrote Yii) about this.
The main benefit of Yii's asset manager is that it allows you to structure your components in a self-contained manner.
A tale of a widget
Consider a component that is a UI widget. Let's assume the distribution includes a couple of assets along with the component implementation, for example these files:
SuperWidget.php
superwidget.css
superwidget.js
image_for_css.png
Consider how you would incorporate this widget into your application if the asset manager did not exist. Typical steps might include:
Copy SuperWidget.php somewhere inside the protected/ directory
Copy superwidget.js to your js/ directory
Copy superwidget.css to your css/ directory
Copy image_for_css.png to your images/ directory or perhaps also inside css/ to help reduce the relative path dependencies
Then at runtime SuperWidget would emit appropriate tags to include the CSS and JavaScript; to do this, it would need to know where exactly you have placed these assets. In other words: some choices regarding the installation can be made arbitrarily, but then they are set in stone unless you go and edit the source.
Is the widget reusable?
If this widget were highly customized and meant to be an inseparable part of your application then this approach would work fine and there wouldn't be much need to have an asset manager. But what if it's a broadly useful component that you want to distribute?
Problems start arising.
First of all the deployment scheme we have examined requires users of the widget to copy different files into different directories, complicating the installation procedure and increasing the chance of error.
But the greater issue is that your deployment scheme could conflict with that of any other component developed independently of yours. What if someone else decided to have a superwidget.js file too?
If the installation instructions for these two components conflict then obviously one of them cannot be installed as intended, and then you resort to changing some details and hacking the source code of the component to accommodate these changes. If you later upgrade to a newer version of that component you will be forced to carefully account for your customizations, making a "copy/overwrite" upgrade impossible.
All of this is really not pretty, and while it can be unlikely to happen in practice it certainly doesn't feel right.
Asset manager, make it so
Here's where the asset manager comes in. Let's assume you decide to structure your component like this:
superwidget/
SuperWidget.php
assets/
css/
superwidget.css
js/
superwidget.js
images/
image_for_css.png
You can directly copy this somewhere inside your protected/ directory no matter what other components you have installed; the worst thing that could happen here is that you'd have to rename superwidget/ to something else if there was a conflict.
Using the asset manager, SuperWidget.php publishes the whole superwidget/assets/ directory, with the copy ending up at e.g. assets/1337c0de/ where assets/ is your application's base asset path and 1337c0de/ is a random hash created by Yii and guaranteed to not conflict with any other published asset.
This means that the assets for SuperWidget cannot possibly conflict with those of any other component, making SuperWidget truly reusable. And since the directory structure inside 1337c0de/ will be the same as in your distribution, CSS can refer to images using the relative path ../images/ without needing to refer to the value of the random hash (which is only know after publishing).
What the asset manager is not
It's not a way to increase security. Your component source would be somewhere inside protected/ anyway (so no improvement there), and the assets need to be web-accessible no matter where they end up being copied (no security for them no matter what).
It's not a catch-all solution for processing your assets (e.g. minifying CSS). While it is possible to install a custom asset manager that does this, don't forget that assets included with reusable components will a small minority among all of your "base application" assets; if you want minification across the board, you 'll have to also process everything else and the asset manager will not help you there.
TL;DR
The asset manager allows you make components that are easily distributable and can be included in applications without the fear of creating conflicts with other components.
Another perk that I like about the asset manager, is that it allows you to update your asset files without having to tell your users to clear their cache.
http://www.yiiframework.com/wiki/311/assetmanager-clearing-browser-s-cache-on-site-update/
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/