Website folder structure / flie inclusions

integration
#1

Dear all,
I guess most of us is used to create some secure-as-possible sites and apps. Proper folder structure is one of that routines.

root
|- _docs/
| |- prezentation_to_client_or_whatever.pdf
|
|- config/
| |- config.php
| |- connect.php
| |- router.php
| |- etc…
|
|- templates/
| |- footer.html
| |- header.php
| |- navigation.php
| |- page-content.html
| |- etc…
|
|- www/
|- css/
|- img/
|- vendor/
|- sitecake/
|- index.php
|- sitecake.php
|- .scpages

  • Main question is - any way how to manage sc-content elements stored upper than website root?

I didn’t saw around any suggestion that folder architecture as example above should work, so i don’t expect much - just want to be sure and help comunity with knowledge completion as also in documentation this wasnt specificaly excluded/confirmed (just that paths should be relatve in PHP section).

Is there any recommended folder structure by design reflecting best security practices, convenience of separating code in reusable blocks (files) and preserving SC features?

Desh.

#2

Hi,

sitecake.php, sitecake dir and all source files that should be handled by Sitecake should be under site root dir (When I say ‘site root dir’, I don’t mean directory root. Sitecake can be installed under specific folder under directory root on your server and in that case it will handle only files under that folder). Can you give me scenario where you would store any files outside of site root and that it concerns security?

As for folder structure, there is no any specific recommendation. If in your example above www dir is setup as directory root, Sitecake won’t work. You need to access your site through sitecake.php to be able to edit it, and if it’s not under directory root you won’t be able to access it.

As for re-usable code blocks, It is recommended that repeatable content is marked with named container, so you don’t need to change it on each page where it repeats. Also, if your site is written in PHP, best practice would be that you store named containers in separate php files and include it where it’s needed.
This is because when something is changed in named container, Sitecake looks for container with same name in other site files and change it’s content where found. If named container is in one file that will be accomplished much faster because content that needs to be changed will be processed just once.
Consider situation where you have site with 100 pages and in each page you have logo in header. If you wrap it in sc-content-logo container in each page, when you for example resize it, Sitecake needs to go in each of that 100 pages and apply your change. If that sc-content-logo container is in separate file that is being included in each page via include/include_once or require/require_once, Sitecake would need to go to just that one file and apply the change. That’s 100 times less work (and time consumed) for saving all the changes. Same goes with publishing your changes. In first case 100 files needs to be published, and in second just one.

#3

Hi @predragleka,

thanks for reply.
First of all, let me correct my post, there is tabulation missing making unclear my question:

However you did answer this question in second paragraph.

Simple logic behind that scenario could be:
Why don’t hide everything what necessarily don’t need to be accessible in browser directly (- not just config files) somewhere above (- css, js, images, etc.)? It is just approach, but imho good habit preserving scalability from few pages presentations to bigger apps.
So sample of index.php in site root:

<?qhq /* first to be included logic from ../config/*.php and then */ include ('../templates/header.php'); include ('../templates/navigation.php'); include('../templates/'.$_GET['page'].'.php'); include ('../templates/footer.php'); ?>

Yes, I understand these benefits of repeatable blocks of content (navigations, footers, side bars, etc.). Just as a newcomer trying to understand Sitacake’s capabilities to handle less-simple-concepts than one html file per page.
If I see your answer properly, following structure (even with multi lang separated folders) should be for SC fully accessible and understandable, right?

Thank you,
Desh.

If I login, can I move between pages and still edit?
#4

Hi,

your’e right. Directory layout you provided would work.

As for storing some files outside of site root, I understand your approach, and I agree. If something is not needed in site root, why put it there? But current concept is based on simplicity of installation and configuration. Any other concept would need some IT knowledge ether in Sitecake installation, or server configuration.

We are always open for new ideas so I’ll think more about this one.

Thanks fo your input

#5

Hi @predragleka,

thanks, understood, agreed.

See you around :slight_smile: