Upload
cesar-salazar
View
2.918
Download
1
Embed Size (px)
DESCRIPTION
On this document, I'm sharing some of the best practices and guidelines I recommend at Devsu (http://devsu.com) for building Drupal sites. Some of the concepts are advanced.
Citation preview
Drupal Advanced Training & Best Practices 1Cesar Salazar
Concepts: The architecture documentTemplate:https://docs.google.com/a/devsu.com/document/d/1g8WZtYirI98iIrX6JqI7FYoHUPxGIzORKjYwuNwXwjE/edit
● Purpose● Sections
Concepts: d7base● Common code to boost the initial setup
○ .gitignore file○ Latest Drupal Core○ Useful Shell Scripts○ [project]_custom module○ global_settings content type○ Do not have any community modules
The guide5 simple steps1. Understand the project
a. Meetings: encouragedb. Assumptions: discouraged
2. Create an architecture documenta. Responsible: Tech lead + Team membersb. Before: You've read and understood the guidelines.c. During:
i. Meetings with clients: What you need.ii. Meetings with developers: How we build.
d. After: Share PDF, revoke GDoc permissions.
The guide (cont.)3. Prepare the codebase
a. Responsible: Tech Leadb. Double check if d7base is updatedc. Create the codebase & branchesd. drush dl the modules defined in Architecture
documente. Other initial scripts setup (coming soon).f. Commit to dev branch
4. Setup environmentsa. Responsible: Tech Lead + Developersb. Install on each local, configure local.settings.
php and local.config.sh5. Start working
Guidelinesfor building Drupal Sites
GuidelinesToday:● Content Architecture Guidelines● Custom Module GuidelinesNext:● Coding Guidelines● Content Display Guidelines● Security Guidelines● Usability Guidelines● Other Guidelines
Content Architecture Guidelines
Content Architecture Guidelines1. Think on what's editable2. Think on where to store the content3. Content Types Guidelines4. Fields Guidelines
Content Architecture Guidelines1. Think on what's editable2. Think on where to store the content3. Content Types Guidelines4. Fields Guidelines
1. Think on what's editableContent might be:1. Editable2. Dynamic3. Part of the theme
Example
ExampleEditable
The editor must be able to change it
ExampleEditable
The editor must be able to change it
Dynamic
Generated by the system
ExampleEditable
The editor must be able to change it
Dynamic
Generated by the system
Footer text: Most likely editable, but probably they might want the copyright year to be dynamic.
ExampleEditable
The editor must be able to change it
Dynamic
Generated by the system
Lists can be EDITABLE (the editor chooses) or DYNAMIC (automatically generated list)
ExampleEditable
The editor must be able to change it
Dynamic
Generated by the system
The client don't want the ability to change the logos, do they?
ExampleEditable
The editor must be able to change it
Dynamic
Generated by the system
The image on the background is obviously part of the theme
Editable Stuff● MUST ALWAYS provide a form● Usually, store on a content type● Global Editable Stuff
○ [Project] Settings Content Type○ A content type with one unique node○ Add Edit links where relevant (Contextual Links?)○ D7Base will contain this content type + code for:
■ Create one node automatically if it doesn't exist■ Don't allow the creation of more than one node■ Forbid the deletion of the unique node
Dynamic Stuff● Do not use Drupal blocks ("Do not store
code in the DB" principle)● If possible Use views or other "featureables"
block types.● Otherwise use custom code
○ hook_block_info○ hook_block_view○ hook_block_configure○ hook_block_save
Theme Stuff● Editable theme stuff
○ Rare cases○ Give the user the ability to change colors, logos,
backgrounds, etc.○ It must be part of the theme or a custom module
● Dynamic theme stuff○ e.g. The background must change randomically
depending on specific conditions.○ It must be part of the theme or a custom module
● Static theme stuff○ Burned in the theme.
Content Architecture Guidelines1. Think on what's editable2. Think on where to store the content3. Content Types Guidelines4. Fields Guidelines
2. Thinking on where to store the contentOptions:● Content Type● Taxonomy● A new entity● A new table● Drupal variables
Conclusion● Usually, use a content type● Review papers.devsu.com if you are not
sure.● Ask your team leader if still not sure
Content Architecture Guidelines1. Think on what's editable2. Think on where to store the content3. Content Types Guidelines4. Fields Guidelines
Content types guidelines● Must be stored on its own feature● Descriptive names● If aliases (short names) are needed,
describe them in the architecture document○ my very long content type name: myct
● Make edit forms easy to use○ Hide information that's not relevant
■ Permissions■ Alters
○ Group content■ Fieldsets■ Vertical Tabs
Content Architecture Guidelines1. Think on what's editable2. Think on where to store the content3. Content Types Guidelines4. Fields Guidelines
Fields Guidelines● Descriptive name. Avoid aliases.● DO NOT reuse fields in multiple content
types● Name must start with the content type name
(or alias)○ field_page_whatever○ field_myct_whatever
● Use taxonomy fields when need to re-use among multiple content types
Custom Modules Guidelines
Custom vs Community● Community Modules, themes and libraries:
○ sites/all/● Custom Modules, themes and libraries:
○ sites/default● Almost always we must use the default
folder for our site.
Custom REUSABLE modules● Can be reused in multiple sites● Don't have business logic● RULE: if it requires business logic, it's not
reusable● Choose the name carefully. We might want
to contribute it.● Do not use any prefix.● Examples?
Custom Site Specific Modules● Start with a prefix● Prefix: 2 or 3 letters (if possible), if it doesn't
make sense, use the full project name.● One main custom module
○ [project]_custom○ Contains most of the customizations and custom
code of the site○ Contains any function needed by any feature
module.● Create others if we really need them
○ A lot of additional code○ Very specific functionality
[project]_custom module● DB Layer: database.inc● Core Layer: core.inc● UI Layer
○ Folder: theme/○ Main file: theme/theme.inc
● Admin Stuff. admin/● Forms. forms/● Pages: pages.inc● Blocks: blocks.inc● Other hooks: [project]_custom.module
ImportantPlease do not use this document as the reference, since the information and guidelines might change.
Always refer to papers.devsu.com instead, which always have the latest information.