WWW directory or below/outside of WWW.

[PeterBubresko]

Quote from a book:
Instead of repeating this code at the top of every file, we can move it to an
include file. Include files are just like normal PHP files, but typically they
contain snippets of code that are only useful within the context of a larger
scripts. As such, as with templates, we don't want people to be able to navigate
directly to these files by typing the filename into their browser, as they only
Structured PHP Programming 224
contain small snippets that won't produce any meaningful output on their
own.
We'll solve this problem the same way we did with templates: by creating a
directory outside the public directory, so that any files are placed in this new one
directory can only be accessed by other PHP scripts. We'll call this directory
includes, and use it to store our code snippets.
Inside the new includes directory, create a file called
DatabaseConnection.php and place the database connection code inside it:
Quote end.

Does this mean that I/you create an area outside the www directory on the server, or is the new "includes" directory placed in the root of www directory?

[maxxd]

Outside the webroot - whether that's called www/ or http/. The whole point is that you don't want the casual browser to be able to access the files directly, only php can access them. So from within the webroot you'll use something along the lines of

include_once('../includes/myPhpFile.php');

The contents of myPhpFile are now accessible from the calling script.

[PeterBubresko]

Thank you Maxxd. Could this be done without moving the includes directory outside the www directory by only changing the permissions on the includes directory while inside the www? directory?

[maxxd]

Admittedly I'm not a server admin by any stretch of the imagination, but I guess it could be if you set up the right user/group permissions on the files. I will say - to me - it seems a bit more convoluted than actually just moving the files - a lot of modern IDEs will automatically update any include/include_once/require/require_once statements for you when you move a directory. Hopefully any of the multitude of people on the board that are better with server setup than I will weigh in with a more grounded opinion.

[Moorcam]

I personally find it pointless moving the files to outside the www or root directory.

I just use the following to protect any file from direct browser access:

In this example, I will display config.php with database credentials:

<?php
// config.php
if (!defined('ACCESS_GRANTED')) {
    die('Access denied.');
}

$databaseHost = 'localhost';
$databaseUser = 'root';
$databasePassword = 'password';
$databaseName = 'my_database';

function connectToDatabase() {
    global $databaseHost, $databaseUser, $databasePassword, $databaseName;
    $connection = new mysqli($databaseHost, $databaseUser, $databasePassword, $databaseName);
    
    if ($connection->connect_error) {
        die('Connection failed: ' . $connection->connect_error);
    }
    return $connection;
}
?>

    return $connection;
}

And, in the file that I want to grant access to:

<?php
// index.php
define('ACCESS_GRANTED', true);
include 'config.php';

$connection = connectToDatabase();
echo 'Connected successfully to the database.';
?>

Moving files outside the www for example, is a royal pain in the buttox and requires some file permissions etc.

Just my opinion.

[PeterBubresko]

Thanks to both of you. I am so new to this so got to admit I don't know what is or what, or what is the best way to do this or other things, but I am learning.

So for now I move the file(s) outside of the www dir, and later when my experience has grown, I will use Moorcams solution. I Choose to do it this
way because I don't need more scripting to remember now. So, for a later time when I have other things under control, I keep in mind Moorcams solution.

 

[gizmola]

With modern PHP sites, you don't want your php class and source files to be in the webroot.  For the most part modern websites use a "front controller" pattern where bootstrap, config and routing is done through one script (index.php).  There are many reasons for this, but even if you don't have a project that uses a front controller, you still want to move any config and include directories outside of the web root for security reasons.  It also makes finding the path to those scripts simpler, but I won't go into the techniques to do that.

This is all (and should be hopefully) facilitated by setting up a composer.json file for each of your projects.  

You can set one up for code you already having by running "composer init" in the project directory, and answering a few questions (most you will just answer no) so that it generates the composer.json file for you. You can then issue other commands or hand edit the composer.json file as per your project.

For all these reaons, and as many people also use composer to generate the autoloader, you put your classes under project_name/src.

Hopefully you understand PHP namespaces.  You can namespace inside the src directory if you want, or not.  Typically this is just a decision of having a subdirectory with some name for your company/organization etc. but you can also just forgo that and creates directories for individual types of components.

So for a simple symfony project you might find in project_name/src

Controller/
Twig/
Doctrine/
Repository/
Kernel.php
Form/
Entity/

For any classes or function libraries you write, you should put those under the src directory, either in their own directory or (as in the case of this example, for the Kernel.php script) just at the root. The organization in there is up to you.  By default, initializing a composer.json file in the project directory, will configure the autoloader to load anything inside the src/ directory so that it can be referred to via the App namespace.

This is via a composer.json setting like this:

 

    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },

  

Another reason for doing this, is that when using composer, component libraries are placed in a vendor directory, but beyond that there might be tests and other artifacts.  If your site uses docker, even if it is just for development you want a place for project files and directories to go that is not in web space.

So the defacto standard is to have a project/public directory, which is where files that should be in webspace go. Then you map your webroot to that. 

 

There are different ways to run and configure PHP today, but the important thing is that the process that needs access to the php files be able to read them.  This might be apache, but it also might be a different user, if you are using php-fpm or perhaps not even using apache as the web server, as you might with nginx.

This structure has been formalized and I found this helpful repo which documents the structure and the purpose of each directory.

So when developing websites this is what you typically will want to use, or will see with a framework skeleton:

 

project_name/
├── config
├── public (web root)/
│   ├── js
│   └── css
├── bin
├── docs
├── src/ (your classes here)
├── tests
└── vendor (composer will create)

 

So essentially, things in webspace go in the public directory.

Anything else stays out of webspace.  That should be all files that are required/included.

If you have any command line utility scripts put them in bin.

For deployment on linux, often there's a default mapping of /var/www for apache, and what you can then do for any project is to move/copy/git checkout the project to /var/www/project_name.  

You remove the default setup and for each site, you have a vhost that sets the documentRoot to be /var/www/project_name/public for each project.

This standard structure works very well from local development to eventual production deployment.