- Top level libraries, modules, themes, and profiles directories are where you should put all shared modules. Core stuff is in
core/ - Hooks are replaced by annotations
- Can have custom block types, blocks have fields now
- Tour module lets you add hints as to what the UI/page is supposed to do
- Views are saved to disk, not database.
- Views will export/render JSON
- Info hooks should instead be in YAML config (Views plugins work the same as any other D8 plugin)
- Views UI can be replaced by contrib modules
- Configuration information like enabled modules, field instances, menus, and settings are in
sites/*/config_*/activeinstead of the database. Destroy this and your site will not work. - uuid in core so you don't need to worry about syncing
- Project page, has a dependency on job_scheduler
- Import 3rd party data in many formats including xml, html, rss, etc and save it as nodes, terms, users, whatever.
- Can schedule imports which will recognize data that has changed (can update entities)
- Parsers can use xPath, QueryPath, etc to transform raw data to make it useable by Drupal. Good for scraping data from xml, html, etc.
- This looks like a helpful Chrome plugin for writing and evaluating xPath queries, https://chrome.google.com/webstore/detail/xpath-helper/hgimnogjllphhhkhlmebbmlgjoejdpjl?hl=en
- Processors are available for most entities
- Mappers provide links between parsed data and Drupal objects (fields mostly)
- Goal is to be clutter-free, reusable, testable. Create functions where the bulk is specific to the task being handled. Write code that is "ignorant"
- The more your class knows about other classes, the more dependent it is that they stay the same.
- Constructor Injection: Avoid tightly coupled dependencies and having to handle instantiating objects by passing dependencies as parameters in the constructor.
- Good to expect an interface (eg:
MailerInterface) instead of a specific class. - Setter Injection: pass dependency through a setter (eg:
$class->setMailer()) - Framework is the active party, your code is passive and called by the framework. Inverted control (Hollywood principle, "Don't call us, we'll call you.").
- Manual injection, factory, container/injector
- In framwework, Service Container assumes responsibility for constructing object graphs. Keeps infrastructure seperate from logic
- A service is not a data object
- "The scope of a service is the context under which the service key refers to the same instance."
- Service keys are strings
- Service definitions allow you to specify additional methods to be called on the object after it's been instantiated.
- Default scope: container
- Symfony's DI component parses config and outputs compiled PHP.
- Compiler passes are classes that process the container and give you a way to manipulate existing services
- Add tags to services to flag them for certain compiler passes
- Add compiler passes in class that extends
BundleInterface
- Default db connection:
database - Module handler
module_handler - HTTP request object (synthetic)
request - To use a core service either...
- Service locator anti-pattern (procedural):
Drupal::service('some_service') - Prefered method:
drupal_container()->get('some_service') - Controllers shouldn't be made services themselves, instead implement an interface that has a factory method which accepts the container
- Don't inject the container... unless you absolutely need to.
- You probably don't want to be loading/testing the dependencies as well as your own code. PHPUnit will allow you to mock up the dependency and tell it how to behave
- Some hooks have been replaced by Symfony's
EventDispatcher. Currently something being worked on. Go to http://drupal.org/list-changes to see if a hook has been converted - Slides for DI talk are available at http://katbailey.github.io
- Everything after mymodule/lib/ is the PHP namespace. Vendors go in lib. There is a composer manager module attempting to solve the issue of having duplicate vendors
- Rules or Login Redirect module to take user away from default post-login page.
- Use Drupal's core dashboard and customize with Views
- In views, enable global contextual links
- Enabled revisions on your content types
- "Don't make a Drupal site that sucks.", lulz.
- Better Formats: More flexibility for specifying input modes
- Node Form Settings: Customize form and remove unneeded default functionality
- Field Group: Organize form fields
- Short Cut Per Role: Allows different short cuts depending on user role
- Publish Button: seperates publish and submit button
- Views UI: Edit Basic Settings: Allows you to specify parts of the view to be editable
- Views Bulk Operations: Add bulk operations. Useful for dashboards
- Field Validation: adds an extra tab to each field instance, allowing you to specify validation rules
- Clientside Validation: Form validation through Javascript
- Diff: Show variations between node revisions
- Override Node Options: allows permissions to be set to each field within the Authoring information and Publishing options field sets on the node form
- Conditional Fields: Define dependencies between fields based on their states and values.