Drupal Architecture ~ An architectural vision

No doubt the life of a site should not be considered until his creation, but rather, that should be the beginning.

The ability to increase functionality with little additional cost is one of the great strengths of free software and of course the robustness of a product like Drupal.

Therefore any new functionality provided by components and used can lead to increased functionality grateful for most websites that are taking place.

That is why a site should not be considered as a single portal, but as an entire project.

A project to life, which has always parallel environments.

Because this functionality we have other two methodologies.

The first is Live Backups.

It is focused on providing that sense of continuity to the sites, with ability to visualize the future and the past.

Feeling of absolute control of the evolution of portals.

We have to turn control of several projects, the first one intends to manage all sites and domains:

Architecture Control Sites - Brqx

On another site aims to auto verify operation of all sites, in order to anticipate problems.

Servers and Control Sites - Brqx NG

This philosophy fits perfectly with the methodology five environments - Five Environments.

Where you can see the evolution and status of any of our sites.

There are many techniques that simplify management and optimize the development, with absolute finality of quality criteria and an approach to real customer needs.

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.

It is a universal standard in programming, trying to identify the functionality of the variables, functions, applications, etc.

This identification implies an appointment seeking maximum simplicity and characterization of components.

The aim is to fight for a maintainable system that involves the least effort to learn the functionalities implemented.

Therefore, in addition to betting on a document management, we must also consider the appointment of components suitable as another important point to keep the architecture appropriately.

For example, one should view with only the name of it to know:

- What kind of view is, focusing on the guy format it.

- What content to display

- If the view are receiving and how many parameters would

- If the view are going to belong to a data type or is a general view

All this information should give it to us the name of the hearing.

Why is it important to complete coding systems?

Because our goal is to reuse the same view and to be able to diagnose the functionality we are valid or not without having to reach the moment of release.

Without doubt, this and many other architectural parameters are beginning to see its meaning when the number of views and number of sites increases dramatically.

There is nothing new, these techniques are contrasted and methodologies of systems, good programming practices in systematic approaches such as CMMI and ITIL today, are common features of any architecture.

Another important feature of free software is its great capacity for change, improvement, new features.

This philosophy is so variant in a short time a good solution becomes obsolete.

It is therefore important for an architect in Drupal to keep up to date on new components, their adaptation to the versions.

Well aware of the Update Status and the Upgrade Status of their portals.

Anticipating problems and when to act, be prepared for it.

It is important to test new features, contributions to the product test, learn about the benefits provided.

Browse product comparisons, analysis of new features made to be able to decide if the news is important for improving the site or simply a code that does not fully expanded new functionality.

Drupal has more than 5,000 modules currently four versions in dance, more than 500 contributions, many information.

All this makes the product complete and complex.

There are a thousand variations and many different ways of doing things has to be any better, except some exceptional cases.

So a good architecture that Drupal should devise ongoing effort in research of new components and upgrades to existing components.

We are all partakers of inadequate documentation in most projects.

Excessive, impractical, too complete.

The aim is to prepare a dossier closest to the customer's needs, a documentation Abstract unnecessary details and get closer to the real objectives of each project.

We have a system that simply can represent almost any web project.

This methodology is partially detailed on our website Agile Methodologies .

We want to minimize all documents involved in a project and transform the traditional documentation system in a more agile system made fully operational documents and a documentation system that provides all the information that supports fully categorized and documentary aspects of each project.

It's time to forget about PDF documents, Word of countless pages.

It's time to address adequately the concerns and deploy a system to streamline the consultation process, to avoid redundancy and bet on the philosophy of "living document".

This role is vital to good architecture.

We analyze the needs of each role and to prepare documents according to them, and wrapped in a flexible, intuitive and well categorized.

Therefore the definition of the abstractions necessary to achieve this goal both content and in terms of final documentation will be another parameter to consider in a portal architecture.