Welcome Guest, Not a member yet? Register   Sign In
Help us to decide
#1

(This post was last modified: 08-10-2015, 01:15 AM by Blair2004.)

Since Tendoo CMS is evolving, we are discussing about security measures.
Recently, we were discussing about where modules and themes folders should be created, within "APPPATH" or at the root ?

We're facing a huge problem, since tendoo cms should be also a tool for developpers, we did'nt want to change CodeIgniter structure such as editing the root .htaccess provided per default.

But if we didn't do that, modules and theme assets within APPPATH wont be accessible.

What's your point of views ?
NexoPOS 2.6.2 available on CodeCanyon.
Reply
#2

Don't put web-assets under APPPATH - definitely.
Reply
#3

Or, you can, but then access the assets using PHP scripts and for good asset names prepare .htaccess rules. I have seen something similar on Yii2 skeleton. I'll probably try such an implementation in the future.
Reply
#4

(This post was last modified: 08-10-2015, 04:57 AM by orionstar.)

Put every asset to the application/modules/fancy_module/assets/ and publish them to a public folder (for example ./assets/cache/fancy_module/) or to an another domain (static.fancywebpage.com) or CDN (akamai, s3) on install.
If ENVIRONMENT === debug then you should publish the assets on every request to see the changes...
On production if you change the assets and you have to republish them, you should implement a reinstall feature on the admin or simply give a CLI command or stg like that to republish...
Reply
#5

Hi,
that was the main idea, we wanted to move modules assets to public directory, but it's not handy (i think) to ease development.
Maybe changing .htaccess to allow access only on "application/modules" is a better solution.

Two days to decide, still needing more advices.
NexoPOS 2.6.2 available on CodeCanyon.
Reply
#6

(This post was last modified: 08-10-2015, 02:48 PM by jdriddle.)

For development, the developer would have control of the web directory structure, so it would make more sense to use the following Structure (which I currently use for the app I am developing, both in dev and production):

AppName
  -- CodeIgniter
      ---- application
      ---- system
      ---- user_guide
  -- src (the user's application source)
  -- www (all static plus the web root)
      index.php
      ---- static
         ------ images
         ------ js
         ------ css
 

You could easily add a modules folder under CodeIgniter, plus another under either www or static, with appropriate subdirectories for each module.

This is easiest for deployment (and for composer deployment especially!), and allows the end user/developer to just point the webserver at the www for webroot.

Dennis
Reply
#7

(08-10-2015, 02:46 PM)jdriddle Wrote: For development, the developer would have control of the web directory structure, so it would make more sense to use the following Structure (which I currently use for the app I am developing, both in dev and production):

AppName
  -- CodeIgniter
      ---- application
      ---- system
      ---- user_guide
  -- src (the user's application source)
  -- www (all static plus the web root)
      index.php
      ---- static
         ------ images
         ------ js
         ------ css
 

You could easily add a modules folder under CodeIgniter, plus another under either www or static, with appropriate subdirectories for each module.

This is easiest for deployment (and for composer deployment especially!), and allows the end user/developer to just point the webserver at the www for webroot.

Dennis
 
Not bad idea actually. a new feature has been introduced to the 3.0 branch, this feature let developer to compress and download a module on which he's working on development environment such as wampserver, this would ease module share (for sure this feature can be disabled through the dashboard).
NexoPOS 2.6.2 available on CodeCanyon.
Reply
#8

Here is the current structure of tendoo CMS

-- application
----- cache
----- config
----- controllers
----- core
----- helpers
----- hooks
----- language
----- libraries
----- log
----- models
----- modules
----- ----- [module namespace]
----- ----- ----- inc/
----- ----- ----- views/
----- ----- ----- config.xml
----- ----- ----- main.php
----- temp
----- thrid_party
----- views
-- system
-- public
-- index.php

We're thinking about using the following

-- application
----- cache
----- config
----- controllers
----- core
----- helpers
----- hooks
----- language
----- libraries
----- log
----- models
----- temp
----- thrid_party
----- views
-- system
-- public
-- modules
-- -- [module namespace]
-- -- -- inc/
----- -- views/
----- -- config.xml
----- -- main.php
-- index.php

But we're not sure that development will be easy (e.g for browsing faster modules and application path).
NexoPOS 2.6.2 available on CodeCanyon.
Reply
#9

(08-10-2015, 02:26 PM)Blair2004 Wrote: Hi,
that was the main idea, we wanted to move modules assets to public directory, but it's not handy (i think) to ease development.
Maybe changing .htaccess to allow access only on "application/modules" is a better solution.

Two days to decide, still needing more advices.

I can't see your problem. Whats is wrong with INITITALLY assets are in the application folder then AFTER INSTALL copying them to a public folder outside the application directory, as I recommeded in the earlier post? I follow that method in the previous years in my own CMS and never caused any problem! Please explain me why don' t you like this solution?!
Reply
#10

Without going into the details of your particular directory structure, I'm going to state unequivocally that you should always setup your project so that it can be installed with all of the code outside of the public directory.

If you want people to be able to distribute modules which include assets which should be in the public directory, but don't want people to have to manually copy those assets into the public directory, then you should include some sort of library or installer for modules which copies those assets for them.

Bonfire's Assets library has a pair of methods (add_module_css() and add_module_js()) which allow developers to add CSS/JS assets which are stored in their module's assets directory to their views. When the library is preparing to output link/script elements to the page, it checks for and/or builds a cached version of the module's files in /public/assets/cache/ (assuming a default configuration), with the module name added into the file name to prevent name collisions. Since this requires some careful configuration for security reasons (after all, the application has to be able to write to that directory AND it has to be readable by the public), the developer has the option of building the cache him/herself, though it requires a significant understanding of how the files or generated (though you could allow the files to be generated in a development/test environment and migrate them to your production environment).
Reply




Theme © iAndrew 2016 - Forum software by © MyBB