14-day Drupal study plan

Drupal Developer · study plan

Build it. Explain it. Then test it.

Use this schedule to strengthen theming and backend skills. Adjust the time spent on each topic using your own practice results.

The official Acquia Developer guide lists 60 questions, 90 minutes, and a 65% pass mark. The domain weights are 10% web, 30% site building, 25% theming, and 35% backend. This lab keeps that distribution. Its questions are original practice material; difficulty and scores are not calibrated against the official exam.

A practical 14-day schedule

Plan for 75–90 minutes a day: 15 minutes reading, 40–50 minutes building or debugging, and 20–25 minutes answering questions and recording mistakes. Extend the schedule if you cannot complete a lab independently.

  1. Days 1–2: trace the theme layers. In a disposable Drupal 10 site, create an Event bundle and a custom theme. Add node--event--teaser.html.twig. Render Event teasers in a View and as full pages. Enable Twig debug locally and identify which template renders each element. Add a body class in HTML preprocess and a node variable in node preprocess. Verify non-node routes still work.
  2. Days 3–4: Twig and browser behavior. Build a partial with explicit variables, a for/else loop, and translated text. Attach a library with core/drupal and core/once. Use a Drupal AJAX interaction to insert new elements; confirm old elements do not gain duplicate event handlers. Inspect a real stacking-context overlap in browser devtools.
  3. Days 5–6: Form API and services. Create a custom module with a permission-protected route and a form. Read a top-level value and a nested #tree value. Validate input, then use a constructor-injected entity type manager in a service. Explain the difference between get() and getValue() without notes.
  4. Days 7–8: cacheability. Build a personalized greeting and a list of node titles as render arrays. Test with two accounts, edit a displayed node, and edit a user name. State which contexts separate variants and which tags invalidate dependencies. Add a time-limited badge and verify its expiry under the actual cache layers.
  5. Day 9: configuration lifecycle. In your disposable site, install a module with default configuration. Change its install YAML and observe that cache rebuild does not update active configuration. Write a narrowly scoped update hook that changes one key, run database updates, and verify another customized key survives.
  6. Day 10: Views. Create one View with page and block displays. Share filters and sorting; override only the block pager. Group rows visually by taxonomy without aggregation, then build a separate aggregate report. On a user profile, filter comments by the route user and test while signed in as a different account.
  7. Day 11: content modeling and access. Reference a shared vocabulary from two bundles, configure a term-targeted comment type and field, and test permissions as a non-admin. Review view modes versus form modes, field cardinality, and configuration versus content.
  8. Day 12: recover weak areas. Use Topic practice to work through Front End and Back End separately. For every mistake, write: the deciding requirement, the correct mechanism, why your chosen alternative fails, and one experiment proving it. Review these concepts after a break, then practice the topic again.
  9. Day 13: full timed mock. Work without documentation for 90 minutes. Budget about 75 seconds per question on the first pass and keep 15 minutes for flagged questions. For multiple-response questions, evaluate each option independently and respect the requested answer count.
  10. Day 14: prove readiness. Rebuild the tasks you missed without following a tutorial. Aim for at least 80% overall and at least 75% in each domain on fresh practice, with an explanation for every selected and rejected option. These are preparation targets, not official pass requirements or a guarantee. Repeating memorized questions is weaker evidence than solving new variations.

Drupal concepts to review

Use these concepts as prompts for hands-on practice. Explain each mechanism and build a small example to check your understanding.

QuestionBest answer / lesson
1 · GroupingGroup by Market Sector in the View format settings; keep the field available but exclude it from row display. Aggregation is for query-level grouping/calculation.
2 · TopicsAdd taxonomy-term entity reference fields targeting Topics to the three content types. Modern Drupal calls this an entity reference.
3 · InheritanceTemplates and CSS from attached inherited libraries. Regions are explicitly declared in the subtheme; not every theme property inherits.
4 · Form values$form_state->getValue('location'). Form-state storage and submitted values are different.
5 · Overlapz-index is the intended property. In practice, positioning and ancestor stacking contexts determine whether a high value can work.
6 · UpdatesRun update.php or drush updatedb to execute the implemented update hook. The hook must explicitly update active configuration safely. The runner does not automatically re-import changed install YAML.
7 · Event teasernode--event--teaser.html.twig. It applies to Event teasers wherever rendered, not exclusively to the sidebar.
8 · StandardsSame-line opening braces for control structures; UpperCamelCase class names; uppercase underscore-separated constants. Drupal PHP uses two-space indentation.
9 · Shared ViewAdd a block display to the existing View and keep the relevant settings inherited from defaults.
10 · Twig iteration{% for type in types %}…{% endfor %}.
11 · Body classhook_preprocess_html(). Page preprocess targets a different template layer.
12 · Fresh variableSet $variables['fresh'] in apex_preprocess_node(). hook_entity_view_alter() receives a render build array, not the node template’s variables array, so assigning template variables there is not equivalent. Also account for cache expiry when the one-week boundary passes.
13 · AJAXUse Drupal.behaviors; use once() per matching element to prevent repeated initialization.
14 · Visibilityprotected permits access within the class and subclasses; it is not public access.
15 · Entity cacheEntity cache tags invalidate cached output when those entities change. This assumes output is otherwise cacheable; tags alone are not a complete caching implementation.
16 · InjectionDeclare arguments: ['@entity_type.manager'] in the service definition and accept the dependency in its constructor.
17 · Profile commentsUser ID from route context. The viewed profile owner can differ from the logged-in account.
18 · OOPAn abstract Report base class with report subclasses supports common implementation while preventing direct base instantiation.
19 · Term commentsCreate a taxonomy-term-targeted comment type, add its comment field to Locations, and show the field in the appropriate display. Also verify posting permissions and open comment status in actual use.
20 · PersonalizationCache contexts and tags: vary by user, retain the user entity’s tags, and include dependencies for the picture and any other rendered data.

Documentation to use while building

Keep an error log by concept, not by answer letter: “viewer versus route user,” “HTML versus page preprocess,” “tags versus contexts,” and “install defaults versus active config.” Options in this lab shuffle for every attempt.

Start practicing