Drupal Architecture ~ An architectural vision

The first few times you come to Drupal, you do not consider its structure as an important location to manage multiple portals.

Drupal developers themselves even begin to orient the possibilities and importance of good architecture files.

Seeing it is a grave error to put everything in "modules."

The opportunity to qualify in "sites / all / modules' different approaches and different groupings of modules.

This ability to discern the common needs of specific options for one or other portal is architecture.

It is important to the proper approach of the websites we want to deploy and is important to understand the approach recommended by Drupal free and, where instead of seeking a single war is bidding for a sharing of knowledge and responsibilities in development.

What we have called Agile Collaborative Methodologies, where your success depends on the success of other companies and resounding in the complete success of the product.

Following this philosophy, the management of websites should not be a version control, for it's own product has its own version control.

Changes or improvements should be consistent and agree with the very perpetrators of these modules or themes.

It is this idea that Drupal gives us, and it is best to ensure the software quality criteria.

Therefore we can see ideal management structure of portals that have to be no version management.

In this structure we have a part directly related to the product such as folders:

-"includes" - "Includes"

-"scripts" - Scripts

-"profiles" - "Profiles"

-"modules" - "Modules"

-"misc" - "Misc"

-"themes" - 'Themes'

It could be a series of symbolic links "pointing to the latest stable version of the product.

Therefore partially delegate files and more generally in product customization sites.

Within files can raise a joint structure with customizations for documents such as icons, logos and images:

/files/ / Files /

This route can be configured to achieve a more optimal coupling of common components.

In the other line, we have the following sites in and structure provided by Drupal

/sites/all/ --> For all sites

/sites/default/ --> Default Settings

As I already said this structure increases the complexity of the site and does not allow us to make a simple approach.

In such a structure would, for example three sites:

sites/site1

sites/site2

sites/site2

sites/all

sites/default

As you can see everything is within the same sites.

We prefer to see the product more easily, where the entire structure is always similar whatever the site and where environmental changes are completely transparent to the internal structure:

In our vision we will:

sites/default --> Just setup

sites/all --> custom common components

This structure will be common to all sites.