I'm currently working on a cms using this fantastic framework but I have ran into a big problem for what I had in mind which is caused by the fact that I cant make self contained modules in fuelphp. Modules will usually consist of different assets and I would like to have the assets in the module folder. From my understanding this is not possible without using Symlinks as suggested by nerdsrescueme in https://github.com/fuel/core/pull/268 since the modules folder is not under the document root thus assets wont be accessible. In the same conversation at the link I posted previously one of the core developers said:
You can use modules like with any view/config/lang file, either it's just available because the current controller is in the module (in which case the module is the first one checked). Or you can prepend "Module_Namespace::" before the filename, ex. the module "test" and file "base.css" would be "test::base.css"
Now I have been trying to do that and it does not work, and it actually seems impossible to work anyway since the modules are not under the document root, but if it is possible I would appreciate some help with the matter.
In the case that that is not possible, a solution would be to actually put the modules folder under the document root. The documentation suggests for security that neither the app, core or modules folders should be under the document root for security reasons. I understand the reason for that is that you don't want somebody running a php file directly without going through the system thus being able to circumvent permissions. Other than view files everything else seems to be classes and config files with arrays in them that dont execute any code on there own thus not being a security risk if put under the document root. Now for the views if we just changed their extension from php to an extension like ctp (this is what cakephp does) so that u cant run them standalone, or even forcing people to add a if(!defined('SOME_CONSTANT'))die('Dont hack me'); on top of their view files like many other CMS/frameworks do. Is there some other security risk that I'm unaware of? If so what would that be? I'm really eager to find a solution to this problem.
I'm sure that there are going to be plenty of people who share the same problem with me wanting modules to be self contained and not need to have module specific assets in another directory.
No replies here?
Having come as a long-term Xaraya CMS developer, I am also used to modules being self-contained, with controllers, models and views in, and default assets that can be included too (any of the views and assets of which can be over-ridden by a theme). It was very convenient.
Separating them the fuel way is fine for completely custom applications built up from scratch, but it does make distribution of modules that require assets a lot more difficult and fiddly. It would be nice to have a way to handle this, but I can't see the best approach.
When we were considering moving removing the modules from direct http access in Xaraya, ideas thrown around included the installation process copying the assets to a default theme in the public area during installation. That theme would sit as a fall-back behind the current active theme to provide default assets for the module.
If you want everything self contained as in one single module directory, you will have to make a modules folder inside public, exposing all your module code at the same time.
If you don't have a problem with that, fine, then your issue is solved.
If you do, there is no other option then to split it. For my modules I create zip files from the docroot, so they contain /public/assets/module/name/... and /modules/name ... (my modules folder is outside app), which I can simple unpack in the docroot of the site I want to deploy them in, and both will be installed in one go at the correct location.
If you have full control of your servers you could deploy other techniques, such as symlinking or copying if you use some kind of module installer system.
I use the same techniques for my themes, as they also contain code and templates I don't want to be public.
That sounds like a good approach - showing where things need to go by structuring them in the distribution zip file. many people have have their public and private folders in different places (e.g. public vs httpdocs vs public_html vs my/public/application_folder etc.) but so long as the *meaning* of the "public" folder is understood, then installation should be straight forward.
Now - assets/module/... or assets/modules/... ?
Which would the project recommend? Consistency between distributed applications or modules make it so much easier to plug things together.
Donate
