Skip to main content

Directory Structure

This article shows you in which directory of n2n which components are stored. Note that the directory structure of n2n is flexible in principle. The goal of this article is that you know what is stored in which directory and that you can orient yourself within the structure of n2n.

The Directory Structure​

In professional projects you do not develop on the production server. Therefore n2n is prepared for multiple environments. We recommend that, in addition to your production environment (live server), you set up at least one test environment for developing!

The following directories are important for creating your application:

  • app
  • lib
  • public
  • var

We will explain these in more detail.

The /app Directory​

Here all individual modules of an n2n application are stored. Practically all work on creating an n2n application takes place in this directory.

The /lib Directory​

The modules that are stored in the lib directory were created independently of your application. These modules are generally programmed for multiple applications. So that these modules can be updated continuously, you must not modify them! If you make changes in the lib directory, you risk losing them during an update. Requests for improvements to the modules in the lib directory therefore have to be communicated to the developers of the respective modules. In general it can therefore be stated that you should not do anything in this directory when programming your n2n application.

Typical modules in this directory are:

  • n2n: the n2n framework
  • rocket: the CMS Rocket, which was developed especially for n2n
  • util: various tools that are used by rocket or other modules

Attention

If you installed n2n via Composer, the modules n2n, rocket and page are copied into the /vendor directory. In this case it may well be that your /lib directory is empty.

The /public Directory​

The public directory contains all files that your web server should deliver directly. A production environment should be set up so that the web server can access only the public directory. All other directories of the framework should not be directly reachable!

Attention

In most cases it makes no sense to store PHP files in the public directory! PHP files in public pose an unnecessary security risk. Store the PHP files that you need for programming your app in the app directory.

One PHP file that must be in the public directory is the index.php. The settings of the .htaccess file ensure that all paths for which no file or directory is found in the public directory are passed on to the index.php. In the index.php n2n creates a ControllingPlan. It ensures that all requests are forwarded to the intended controllers.

Attention

In the default settings the index.php checks whether batch jobs are due. However, this slows down the system, especially with complex batch jobs. To prevent this, you can move the invocation of the batch jobs into a separate PHP file (e.g. batch.php) and call it regularly via a cronjob.

The public directory contains two subdirectories:

  • assets: here the files of the modules are stored, which the visitors of the application need to access directly from the internet. Typically these are images, CSS or JavaScript files.
  • files: here files are stored that are linked to business objects and may in principle be retrieved by all visitors (Public File Manager). This directory is created automatically by n2n as soon as the first business objects with linked files exist.

Attention

JPG, PNG, GIF, JS and CSS are stored in the public folder because they can be delivered directly by the web server and the framework does not have to be started for this.

The /var Directory​

This is the directory where configurations, logs and backups of the application are stored. This directory contains for example the following subdirectories:

  • bak: backups are stored here
  • etc: here the application and the modules are configured. This data should not change during runtime.
  • log: the log files are stored here
  • srv: here your application can store settings and data at runtime
  • tmp: temporary files are cached here

Other Possible Directories​

As already mentioned, the directory structure in n2n is flexible. The following additional directories are conceivable for n2n, but not mandatory:

  • build
  • hangar
  • test
  • vendor

Build Directory​

The build directory is for publishing scripts. That is, the scripts that prepare your project from the test environment (e.g. CSS and JS minification) and deploy all required components to another environment (e.g. production).

The Hangar​

The Hangar helps you create and configure your n2n application and is typically stored in the hangar directory. It takes many repetitive tasks off your hands. Hangar is documented separately.

Attention

Hangar is a tool independent of n2n, which is not published as open source. Hangar may be used free of charge now and in the future, but you do not have the right to make changes and distribute them.

Test Directory​

/test is the directory for all test scripts.

Vendor​

If you install n2n via Composer, the Composer creates a /vendor directory. It contains all modules that are loaded via Composer.