We talked about relations between components, but we must also note the organization of the same.
Getting a simple system that allows localization of components and easy integration into an environment of that component or functionality, linking a range of components is a credit to good architecture.
No doubt a structural level a system of symbolic links facilitate this work.
We discuss below the recommended structure to Vector SF and other partners to Red.es and that is being used on servers Brqx.
The structure has an unmistakable character fit in any system.
The initial word "brqx" whatever that is identifying, serves two purposes:
1 . - Do not be confused with a directory where you install any systems (Unix, Mac, Windows).
2. - Do not be confused with any definite plan, it never made any plans that call brqx.
The second string defines the word level:
- Base : Product Level (Products level)
- Lnk : Level of links (link level)
- Proy : Project level (here, English is different: Project Level)
- Pers : Customizations
- www : Final level of sites (site level)
The third term of the string defines the product.
We start with Drupal, but the structure is designed to suit any product.
/brqx/base/drupal
The fourth word defines the version of the product.
It puts a letter because many systems have problems if a folder starts with number.
- v50
- v60
- v70
Once you have selected the version defined three levels:
- core - 'Core' unchanged for Drupal
- modules - 'Modules' Drupal Modules
- themes - ' Themes' Drupal Themes
For now we will not delve further into the structure.
We're just going to indicate an example of it:
/core
/core/v612
/core/v615
/modules/abc/c/captcha/captcha_2_1
Now about the level 2.
At this level indicate the components that are certified and / or final versions being used.
The initial path is similar:
/brqx/lnk/drupal/v60/modules/abc/c/captcha
Here we specify the functional cores formed with links (already certified versions)
We can see the core bas (base module) that defines the basic functionality required for all sites of architecture.
The path of this common functionality is:
/brqx/proy/drupal/v60/base
The modules that form:
a/ajax ' /brqx/lnk/drupal/v60/modules/abc/a/ajax
c/cck ' /brqx/lnk/drupal/v60/modules/abc/c/cck
This information is now obsolete, but certainly one way to teach when organizing a complete and complex architectural approach applies to a multi site development system with a philosophy of simplicity.
The advantage of using a homogeneous structure is that the processes can be automated, therefore Drush applications as well as our scripting architecture allows us flexibility in developing out of the común.
Althought sites functions are not completely updated, this architecture is downloadable from the internet:
Policies allow scripts to an agility that can not get in a web process.
Drupal knows. The Drupalers know.I invite you to learn how to create shell scripts to automate processes, customize settings.
There is so much to be learned that enhances the final product.