Becoming A Drupal Master Builder
-
Upload
philip-norton -
Category
Technology
-
view
694 -
download
1
Transcript of Becoming A Drupal Master Builder
Becoming A Drupal Master Builder
Philip Norton
Blog at #! code (www.hashbangcode.com)@philipnorton42 on Twitter
Technical Lead at
Philip Norton
Creator of Vlad Helps run NWDUG
==
https://www.flickr.com/photos/chrish_99/6730952349/
http://buytaert.net/album/birthday-axl-2011/dries-with-lego
My Experience
● 10+ years in programming
● 8+ years in the web industry
● 6+ years building Drupal sites
● 4+ years as Technical Lead at Access
● Development, system design, database and server administration, consulting, SEO, usability, training, mentoring
Other People’s Projects
● Reviewing projects built internally
● Migrating existing Drupal sites
● Third party sites that we need to host and maintain
● Rescue jobs
The good thing about PHP, is it’s really easy
to learn.The bad thing about
PHP, is it’s really easy to learn
Ben Dechrai
Contents
● Drupal File Architecture
● Coding
● Configuration
● Contrib Modules
Drupal File Architecture
Drupal File Structure
● Custom/contrib for the modules directory
-- sites---- all------ modules-------- contrib-------- custom
● Easy to spot what the custom modules are
● Makes analysing custom code much easier
● Always use sites/default/files to store your files, it will make life easier in the long run
Multi-site Setups
● Use DNS entries to auto-detect your file directory
sites/www.example.com/filessites/www.example.com/modulessites/www.example.com/settings.php
● Nice idea
● In practice it causes more problems than it solves
● This is used even when not needed
Themes
● Use the template.php file for theme overrides and helper functions
● Do not use the template.php file to run database commands
● Do not hardcode ID’s all over the place
● Use generic templates and stop template proliferation
● Drupal 8 forces you to stop using logic in your templates and instead use preprocess hooks
Overly Specifying Specific Specifics
● More specific custom code means more stuff to break
if ($node->nid == 1234) {}
● Node ID and Block ID specific templates
● Use of taxonomy term ID to control things
● If you have to use specifics then use configuration to set these values
Drupal Module File Structure
● Lots of Drupal 7 hooks come with a file parameter
● Use it to move functionality into different files
● Namespace your module functions in Drupal 7
my_custom_module_some_function()
● Put all classes in their own files
● Use the X Autoload module to use PSR-4 in Drupal 7
● Drupal 8 Forces PSR-4! :)
http://www.jpstacey.info/blog/2015-06-22/architecting-drupal-7-module-multiple-files
Drupal Module Documentation
● Add documentation to your modules
● Write more than the basics in your info file
name = Tool Tips moduledescription = A module for tool tips
● Add a readme file and detail to the drupal.org module page
● Also think about adding install and configure help
Drupal CHANGELOG.txt
● Don’t allow information leakage by including the CHANGELOG.txt file in your Drupal install
● Restrict access via webserver configs
● Can also remove them from your codebase but the Hacked! module will complain
● Alternatively, simply remove them as part of your deployment process
Drupal Custom Code
● Don’t reinvent the wheel, use Drupal’s framework
● Use third party modules to provide functionality as much as possible
● Use Drupal’s hooks to accomplish actions or change existing functionality
Coding
Don’t Hack Core
● There are a million good reasons not to do this
● This includes contributed module and theme hacks
● Patching is ok as a last resort, BUT document your changes!
● Do it the right way, learn about hooks, overrides and child themes
https://www.drupal.org/best-practices/do-not-hack-core
Version Control
● Use version control
● Seriously, use it
● Git is good, so is Mercurial
● Commit often, use commit messages, describe your changes
Version Control Branches
● Git branching is cheap
● Use git flow (or a variant)
● The master branch is a copy of the live site
● All work should be done on a development branch and merged with master when ready for deployment
Version Control Etiquette
● Describe your work in commit messages
● Don’t add databases to your git repo
● Don’t include the user files directory in your git repo!
● settings.php file is debatable, just be careful of adding usernames and passwords to your repos
● Use a local settings file
if (file_exists(__DIR__ . '/settings.local.php')) { include __DIR__ . '/settings.local.php';}
Use An IDE
● Syntax highlighting, code navigation, debugging, autocomplete, auto formatting and more!
● Quickly spot unused variables
● Detect errors and problems before you commit the code
Development Environment
● Try to replicate your production environment when developing
● Stop silly errors creeping into the live site
● WAMP/MAMP solutions just don’t cut it
● Use Vagrant and a provisioning tool
● Vlad! :)
PHP Errors
● Syntax errors should never make it into production
● PHP Notices and Warnings are also NOT acceptable in a production environment!
● Understand the internal Drupal error processing (See _drupal_log_error() in Drupal 7)
● Don’t use @ to suppress warnings, it’s lazy and has performance implications
● Use try {...} catch() {...} block to catch exceptions
Coding Standards
● Pick a coding standard and stick to it
● Use the Code Sniffer tool, preferably with the Drupal coding standards files
● Implement a continuous integration system to auto check the code (e.g. Jenkins)
● Coder module (https://www.drupal.org/project/coder) has everything you need
https://www.drupal.org/coding-standards
Cyclomatic Complexity
● The total number of paths of execution through a block of code
if ($variable == TRUE) { do_something();}else { do_something_else();}
● High numbers are bad (harder to read and maintain)
● Use PHPMD to inspect your own code and refactor complexity
Cyclomatic Complexity = 2
Always code as if the person who ends up
maintaining your code is a violent psychopath who knows where you
live.
John Woods
Drupal Tests
● Drupal has a test module bundled
● Drupal 7 uses Simpletest, Drupal 8 uses Simpletest and PHPUnit
● Write tests!
● Test current functionality, re-run tests when refactoring or adding new functionality
● Can take time to write tests, but it’s worth it in the long run
Configuration
Drupal Content Types
● Content type != template type
Press ReleaseNews ArticleFront Page News Article
● A mistake that many site builders make
● Create functional content types, use data to control them
CSS/JavaScript Aggregation
● Turn it on!
● Reduce the size of your files and the number of files downloaded
● Reduces server load and decreases page load speed
● Try it before you deploy live, some CSS/JavaScript code can be broken by this
● Spot problems before they appear in live environments
Fieldsets And Vertical Tabs
● 40+ fields on your content types makes a long edit page
● Use vertical tabs and fieldsets to break the page up
● Field Group module has this functionality
● Try to avoid using “Unlimited” cardinality on fields especially on file fields
● Think about how your users will edit pages
Permissions
● General rule is to restrict user permissions to the core activities they will be doing
● Giving users too much access can be confusing, especially for new Drupal users
● Also don’t allow lots of ‘superuser’ roles as it becomes difficult to restrict access
PHP Filter
● The PHP Filter module is bad, never use it
● Execution of PHP is slow and uncachable
● Quickly creates an unmaintainable mess
● Lots of security implications
● Removed from Drupal 8 (with much fanfare!)
Running Cron
● Don't get your users to run cron, put it in crontab
● Use the Elysia Cron module to process cron tasks at different times
● Can see a massive (90%+) reduction in the cron footprint
https://www.drupal.org/project/elysia_cron
Updates
● Some modules use update hooks to run actions, usually to add or update database tables
● It is essential that you run update.php when you deploy an update to a module
● Using ‘drush updatedb’ also works well here
Uninstall Deactivated Modules
● Uninstalling modules is important as they leave behind tables and data that isn’t used
● Turn off and uninstall modules before deleting them
Contrib Modules
Views, Views, Views
● Use Views to show lists of content
● Built into Drupal 8
● Don’t duplicate a View to display the same thing on different pages
● Use contextual filters to alter the same View in different contexts
● Remember to add pagination and limits
Pathauto
● Seeing node/123 on production websites makes me cringe
● Use Pathauto to create pretty paths from node data
● Creates SEO friendly paths
https://www.drupal.org/project/pathauto
Context
● React to certain page level conditions
- Paths- Views- Content Types- Menu Items- Taxonomy Terms
● Much better and more controlled block placement in Drupal 7
● Fully exportable so placement can be kept in config
https://www.drupal.org/project/context
Advanced Aggregation
● Compress your CSS and JS even more
● GZips your code for smaller size when transporting
https://www.drupal.org/project/advagg
UI Modules
● Many modules come with a user interface (UI) sub module that wrap the administration interface
- Views UI- Context UI- Rules UI- Display Suite UI
etc...
● Turn them off in production
Devel
● Really powerful module
● Makes development easy in Drupal
● Awesome sub modules like Devel Generate and Devel Node Access
● Who doesn’t love Devel?
● Don’t, don’t, DON’T leave it running it production!
● Also, DON’T commit dpm() into your code!
Stage File Proxy
● Really good module for using uploaded files on a dev platform without having to download the user files directory from production
● No need deploy to production
https://www.drupal.org/project/stage_file_proxy
Features
● Features allows modules to be made that create Content Types, Fields, Views, Contexts, Rules, and many more types of configuration
● Allows you to see when things have changed and allows easy deployment of new functionality
● Try to add as much configuration into code as possible
● Group like items together
https://www.drupal.org/project/features
Spotting Problems
opensource.com
● JavaScript aggregation is turned off (but not CSS?)
● Messy module directory structure (due to Panopoly distribution)
Cisco Internet Of Everything
● Runs Drupal 7.24 (as seen from CHANGELOG.txt)
● Vulnerable to SA-CORE-2014-005?
belgium.be
● Lots of stuff done right
● CSS and JavaScript aggregation turned off
Greater Than Games
● Runs Drupal 7.41, as seen in CHANGELOG.txt
● Multi-site setup
Elite Dangerous Community Site
● CSS/JavaScript aggregation is turned off
● Some use of Path Auto so URL’s like ‘node/123’ are common
● Multi-site setup
● Hacked the Bootstrap theme to make a sub-theme
● Call me! :)
Top TipsSome things to take away with you
Top Tips
● Have a go live plan
● Think about the experience of all of your users
● Don’t overcomplicate simple functionality
● Don’t use specific templates, generalise
● Think about the long term life of the site
● Learn the system (i.e. Drupal)
?