Moodle H5P activities and content bank

Moodle H5P activities: when a team needs to plan them before building courses

Plan H5P activities before courses are built whenever interactive content will be reused, shared across departments, or treated as an institutional asset. The H5P activity is a core Moodle activity that a teacher adds to a course to present interactive content, and the content bank is where reusable H5P content can be kept and drawn on across courses. Teams often start by placing content directly in courses because it is faster, then discover later that the same item is duplicated in twenty places. Deciding early which content belongs to one course and which belongs to a shared library is the most important planning step.

Before any course template is built, the design team should answer a short set of questions. Who authors interactive content: teachers, instructional designers, or a central team? Will a change to a shared item need to reach every course that uses it, or should each course keep its own copy? Who may edit items in the content bank, and who may only add them to a course? For example, in an illustrative case, a compliance refresher used by three departments needs one owner and one approved version, while a single-course quiz-style activity may not. Record these answers in a content inventory so the build does not depend on memory.

Self-hosting changes the planning picture. Moodle is licensed under GPL-3.0, is maintained by Moodle HQ, and can be run in infrastructure the client controls, or through MoodleCloud or Moodle Partners. When the organization hosts Moodle itself, it owns backup, restore, storage capacity and upgrades for every H5P item, including content in the content bank. The target release also sets the server baseline. Moodle 5.1 requires 64-bit PHP 8.2 or later and a supported database, and Moodle 5.3 requires PHP 8.3 or later, so confirm the version and its requirements before the content library is populated. Moodle 4.5 is a long-term support release with security support until 4 October 2027, which may matter for teams that cannot upgrade on a six-month cycle.

Several H5P behaviors determine whether a shared library will hold up over time, including how content is packaged and copied, how content type libraries are versioned, and how results reach the gradebook. This section does not describe those internals. Confirm each behavior you depend on against Moodle's documentation for your target version, and test it in a non-production course. Check that copies, restores and course backups carry content as expected, and that an edit to shared content behaves the way your governance model assumes. Ask the implementation partner to document the same checks in writing as part of the scope.

Before build starts, the team should agree on five things: a content inventory with owners, a reuse map showing which courses depend on which items, a decision on whether H5P results need to be graded, a backup and restore approach for the content bank, and a process for retiring or updating shared content. Grading and governance are covered in their own sections, so treat them here as dependencies to be scheduled, not solved. Teams that complete this planning before course design avoid the most expensive rework, which is moving content after learners and instructors already depend on it.

What the H5P activity and content bank do in Moodle core

Moodle core gives teachers two connected tools for interactive content: the H5P activity, which places content inside a course, and the content bank, which stores items for reuse. The cards cover how each works, where reuse creates shared risk, and which behaviors you must confirm for your target release before you design courses around them.

The core H5P activity

The H5P activity is a Moodle core activity module that places interactive H5P content directly inside a course. Teachers use it to choose content for a specific section and to set how learners open it. Confirm in the documentation for your target release which H5P content types ship with core and which need separate installation, because that list determines what your authors can build without extra work.

The content bank as a reuse store

The content bank is Moodle's store for reusable content, and H5P content is one of the types it holds. Saving an item once lets several courses use the same interactive exercise without rebuilding it, which matters when multiple teams teach the same material. Confirm which levels the bank supports for storing content and who can see items at each level in your release.

Adding stored content to courses

Teachers add bank content to a course by selecting an existing item within the H5P activity, so one source can appear in several courses. Keep a record of which courses use which bank item, because changing or removing a shared item can affect every course that reuses it. Confirm in the release documentation whether a course keeps a copy of the item or a live link to it.

Grading and results reporting

Whether an H5P activity sends scores to the gradebook, and what completion tracking records, depends on the Moodle release and on how each content type reports results. Do not assume a score will reach the gradebook because the content is interactive. Confirm the behavior with a test course on your version, and check how results appear to teachers and learners before you base assessments on them.

Permissions for authors and reusers

Creating, editing, reusing and deleting H5P content is controlled by Moodle capabilities assigned to roles in different contexts. A teacher who can add activities to a course may not be able to edit items in the bank, so map roles before rollout. Confirm the relevant capabilities for your release, and decide who owns shared items when an author leaves the institution.

Upgrades and content dependencies

H5P content depends on libraries and content types that must stay compatible through a Moodle upgrade. A release change can alter how stored content displays or reports results, so the same item may behave differently after an upgrade. Confirm library and content type behavior on a staging copy of your site before each upgrade, and keep a record of the versions your content was built against.

Configuration decisions to settle before authors start

This table compares the five decisions that shape how H5P content is stored, shared, graded and tracked in Moodle. Read each row as a question to answer with your governance owner before any course is built. The main takeaway is that storage level, edit rights and copy or reference behavior are costly to change once many courses depend on them.

Decision	Options	When it fits	Risk if chosen wrong
Where shared H5P content lives	System, category or course content bank	System level suits a central compliance library. Category level suits faculties, departments or subject areas.	Moving items between levels can break links and change who can find them. Confirm the move behavior in your version.
Who may create and edit shared items	Restricted authors, course teachers or open editing by staff	Restricted authors suit regulated or accredited content. Open editing suits fast-moving school or university teaching teams.	Unreviewed edits to a shared item can change content in many courses at once. Map capabilities to roles before rollout.
Copy or reference reusable content	Each course gets its own copy, or courses reference one master item	Copies suit courses that will diverge. References suit a single approved version maintained by one owner.	A master edit can alter live courses under reference use. Copies drift and need manual updates. Test both in a sandbox first.
Whether H5P results feed the gradebook	Graded activity with a maximum grade, or ungraded practice	Graded use suits assessed formative or summative tasks. Ungraded use suits practice that should not affect final marks.	Switching grading on later can leave earlier attempts unscored or misaligned. Decide grade categories and weights first.
How completion is set	Completion on view, on submission, or on a grade or score condition	View completion suits content review. Score or grade conditions suit mandatory training with a pass mark.	Completion rules applied after learners have started can show inconsistent status. Agree the rule with compliance owners and document it.

How the content bank changes reuse across courses

The first decision is whether each H5P item lives inside one course or in the shared content bank, because that choice sets who can change the item and how far a change reaches. Content created inside a course belongs to that course's context. Only people with editing rights in that course can change it, and an edit affects only the activity where it sits. Content in the content bank belongs to a bank context, either the system or a course category depending on where it was saved, and it can be used in several courses. Each course that uses a bank item holds either a reference or a copy, depending on the action used to add it. Confirm on a test site which model your Moodle version applies, and record who holds edit rights on each bank context.

Editing a shared item after several courses have used it is where most reuse problems start. Before the bank is opened to course teams, run a test on a site at your exact Moodle version. Change a bank item used in two test courses, then check whether each course shows the new content, whether the old content survives anywhere, and whether learners who attempted before the change still have a consistent record. The answers decide your governance rule. If edits propagate, shared items need a named owner and a change process. If courses hold copies, teams must know that a correction made in the bank will not reach them automatically. Do not carry assumptions over from other learning platforms or from older Moodle releases.

The data consequences fall into three areas. The first is which version learners see on a given date, which depends on the reference or copy model you confirmed. The second is how existing results behave. Attempt data is stored against the activity and the submitted answers, so a content change after attempts can leave reports showing marks for interactions that no longer match the item. Ask the team to confirm what the gradebook and reports display in that case and whether a regrade is needed. The third is accountability. Your own change log should record who approved each change to a shared item and why, because the platform's record of who edited what may not explain the reason.

After every Moodle upgrade, test a fixed set of cases before course teams return. Include at least one bank item used in several courses, one graded H5P activity with existing attempts, one item that was copied into a course, a course backup and restore that contains bank items, and gradebook totals after a regrade. Check the H5P library version and content types recorded for each item, because the H5P library can change between releases. Confirm the expected behavior in the release notes for your target version, compare the results with your test log, and only then schedule the upgrade for production.

How H5P results reach the gradebook and reports

Whether an H5P activity feeds the gradebook is a release-specific question, so it should be settled before any course template is built. Grading behavior can differ between major releases and can change in point releases, so the answer must come from the Moodle version you will run in production, tested on a staging copy with the same plugins and settings. Do not assume that an interactive activity behaves like a quiz or an assignment, because its grade settings may be shaped differently.

Confirm the following in the target release:

Grade setting: whether the activity exposes a maximum grade and where that setting sits in the activity form.
Grade item creation: whether a gradebook item appears when the activity is added or only after the settings are saved.
Category placement: which grade category receives H5P items, so that weights apply as intended.
Decisions for the grade design team: the weight of each H5P item, and whether it counts toward a course total or is informational only.
Pass marks: whether a pass mark applies per activity, per category or only at course level.

Before copying any course, run one graded H5P activity through the gradebook on staging and confirm that the grade item, weight and pass mark match the design document.

Implementation sequence for H5P activities and the content bank

This sequence moves H5P from a pilot to governed, reusable interactive content in Moodle. Each step closes with a document or record the client keeps, so the platform, permissions, grading and authoring rules are settled before authors work at scale.

Confirm Moodle version and server requirements
Confirm the target Moodle release, its support window and the server stack it requires, including PHP, database and web server settings. From Moodle 5.1, the web server document root must point to the /public directory, so the hosting team checks this before any content work begins. Also confirm your current version can upgrade directly to the target. The output is a configuration record listing the version, runtime components, document root setting and the H5P-related settings enabled on the site.
Define content bank structure and permissions
Decide how the content bank is organized: which categories exist, whether content sits at site, category or course level, and which teams can create, edit, reuse or delete items. Map each role to the Moodle capabilities that control those actions, and confirm in your release which H5P and content bank capabilities are available and how they inherit. Test the model with two or three test accounts. The output is a permissions matrix that lists each role, the actions allowed and the places they apply.
Pilot two or three H5P content types
Choose two or three H5P content types that match the courses you plan to serve first, such as interactive video, question sets or drag-and-drop exercises. Have real authors build them in a pilot course, reuse at least one item from the content bank in a second course, and record where editing, saving or embedding caused friction. Include a learner-view check on mobile and desktop. The output is a tested pilot course with a short log of issues found and how each was resolved.
Configure grading and completion
Decide which H5P activities report scores to the gradebook, how those scores combine with other graded items, and which completion conditions apply, such as a passing score or a viewed-and-submitted rule. Check how each H5P content type reports results in your Moodle version, and confirm what learners and instructors see on the grade report. Involve the assessment owner and a registrar or accreditation contact if grades feed a formal record. The output is a signed-off grading design that states each rule, its owner and its test result.
Write authoring standards
Document the rules authors follow: naming conventions for content bank items, required metadata, accessibility checks such as alternative text, reading level, and color contrast, and which content types are approved for each subject. Include rules for licensing and third-party media, and for when an item must be copied instead of edited in place, since edits to shared content affect every course that reuses it. Base the standards on the pilot findings. The output is an authoring standards document approved by the content owner and the accessibility lead.
Train authors on the approved workflow
Run training that follows the authoring standards and uses the pilot course as the working example. Cover creating and reusing content bank items, the grading and completion settings each author must set, and the review request process. Give each author a short hands-on exercise and a checklist to use after training. Record who attended and which exercises were completed. The output is a training record and a completed author checklist for each participant, which the content owner keeps with the permissions matrix.
Run content review before wider release
Before opening the content bank to all authors, review a sample of the first production items against the authoring standards, the grading design and the permissions matrix. Check that reused items behave correctly in every course that embeds them, and that completion and gradebook entries match the signed-off design. Record each finding, its fix and the reviewer. The output is a review log and a written release approval from the content owner that sets the date and scope of the wider rollout.

Governing shared interactive content over time

Governance decides whether shared H5P items stay accurate, lawful and useful after the first course has used them. Without named owners, a content bank fills with near-duplicate interactions, outdated quizzes and items that nobody can explain. Start by deciding who owns each item: the author who built it, the department that licensed it, or a central learning design team. Record that owner in the item's name or description, and make the owner the person who answers when a teacher, learner or auditor asks about it. Settle who may edit a shared item and who may only reuse it in a course. Map that decision to the content bank capabilities and course sharing settings in your Moodle version, and confirm the exact capability names before you assign roles.

Review should happen before an item enters the shared bank, not after teachers have started using it. Set a gate with a small group of named reviewers who check the learning objective, the correctness of answers and scoring, the wording of feedback, and the accessibility of the interaction. Keep the review record in a system you control, such as a ticketing queue or document register, unless your Moodle version provides an approval status that you have tested. Decide whether teachers may keep working items in their own areas of the bank and move only approved items into a shared category. Write down who can make that move, because the move is what puts content in front of many courses at once.

Naming and tagging make governance workable at scale. Adopt a naming pattern that includes subject, level, interaction type, version and year, so a teacher can find an item and an administrator can tell versions apart. For example, an illustrative label might combine a course code, a unit number, the interaction type and a version number. Keep tags to a controlled list of topics and outcomes so that spelling variants do not split one topic into several. For third-party or authored material, use the copyright and licence fields that the H5P editor provides to record the author, source, licence terms and date of last review. Items without those fields are the ones that cause problems during a rights review.

Retirement and checks keep the bank from becoming a liability. Set a review cycle, and flag items that no course has used for a period your governance group chooses. Move retired items to an archive category first, because deleting an item that a course still references breaks that activity and removes the evidence of what learners completed. Test each item for keyboard operation, screen reader support and captions on any embedded media, and record the result. Confirm that third-party licences permit your institution's use and reuse in each course. These records give internal reviewers and independent assessors something concrete to sample. They show whether your own policies were followed, which is what determines compliance outcomes. Moodle stores the content and its history, but the policy, the approvals and the decisions belong to your organization and its assessors.

What drives effort and cost for H5P work

This table lists the eight factors that move effort for H5P work in Moodle and explains how each one changes the work. Read each row as a question to answer before requesting a quote. DeployOpen does not publish a price list, so the written scope, built from these answers, sets the quote.

Driver	Why it changes effort	What to ask for in a quote
Number of authors and courses	Raises effort: more authors need training, and each shared H5P item needs an owner and a review path.	Named author count, courses that will use H5P, and whether content will be reused across courses.
Existing interactive content to migrate	Raises effort: packages must be exported, checked for broken media and mapped to the right courses and categories.	Item count by source, export format, and whether content comes from H5P, SCORM or other tools.
Content types in use	Raises effort: each H5P content type has its own editing behavior, test cases and possible library dependencies.	List of content types, library versions, and any custom or third-party types that need validation.
Grading and completion requirements	Raises effort: scores, pass marks and completion rules must be tested against the gradebook and course reports.	Which H5P activities feed grades, passing thresholds, completion conditions, and who approves the rules.
Gradebook and reporting integration	Raises effort: exports to reporting or HR systems need field mapping, scheduled jobs and reconciliation checks.	Target systems, data fields, refresh frequency, and the team that signs off on report accuracy.
Hosting topology	Raises effort: load balancers, shared file storage, caching and separate authoring and delivery environments add configuration and testing.	Environments in scope, where H5P files are stored, backup approach, and any air-gapped constraints.
Moodle version and server stack	Raises effort on older sites: Moodle 5.1 needs PHP 8.2 or later and PostgreSQL 15; 5.3 needs PHP 8.3 and PostgreSQL 17.	Current and target versions, PHP and database versions, and whether the web root moves to /public for 5.1.
Upgrade starting point	Raises effort when the site is behind: Moodle 5.1 requires starting from 4.2.3 or later, and 5.3 requires 4.4 or later.	Installed Moodle version, plugin inventory, and any H5P or content bank changes needed before the upgrade.

How H5P content connects to the rest of the Moodle platform

H5P activities and content bank items sit inside Moodle's wider platform, so identity, grading, course design and migration decisions affect them directly. The cards below cover the connections to scope early and the points where H5P-specific behavior must be confirmed in your own environment.

Core authentication plugins

Moodle core ships authentication plugins for LDAP, OAuth 2, Shibboleth and LTI, along with manual accounts, email self-registration and web services. The method you choose governs how learners and staff reach the course pages where H5P activities run. Confirm in a test site which roles can author, edit and reuse H5P content under each sign-in path before rollout, and check how LTI launches behave for H5P activities in your setup.

SAML 2.0 through auth_saml2

SAML 2.0 single sign-on is commonly provided by the SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT. It creates users using field mapping configured in Moodle, and its plugin directory listing shows support for Moodle 2.7 through 5.1. Confirm that your Moodle version falls within that range, then test which mapped attributes your course enrolment and H5P access rules depend on.

Gradebook and reporting

H5P results need to reach the gradebook in a form your course designers and reporting teams can use. Moodle documents many plugin types, including report plugins and admin tools, so reporting can be extended. Whether H5P scores, completion and attempts appear in grade items and standard reports depends on the activity configuration and your Moodle version. Ask the implementation team to demonstrate a graded H5P activity from learner attempt to gradebook export before approving the design.

Course templates and reuse

Course templates decide how H5P activities are placed, named and linked to content bank items when new courses are created. When a template duplicates an activity, confirm whether the copy references the original content bank item or stores a separate copy, because that choice determines whether a later edit reaches every course. Test duplication and restore with a sample course, including a restore into a different category, and record the result in the course design standard.

Content migration from other systems

Interactive content from another LMS or authoring tool may need to move into Moodle before H5P activities can run it. Inventory every package, its H5P library versions and its licence terms, then confirm the import route in your environment. Check migrated items for missing libraries, broken media and grade settings, because these failures often surface only after learners have started using a course. Test a sample of each content type before bulk migration begins.

Plugin and upgrade compatibility

H5P integration depends on the Moodle version you run and on any third-party plugins installed beside it. From Moodle 5.1, the web server document root must point to the /public directory, and sites must be on Moodle 4.2.3 or later to upgrade to 5.1. Record which plugins touch activities, the gradebook or authentication, then retest H5P content after every upgrade and plugin change.

Questions buyers ask before hiring help with H5P in Moodle

How much does hiring help with H5P in Moodle cost?

The cost depends on the written scope, so there is no standard price. DeployOpen does not publish a price list, and a quote follows from the agreed scope. The main drivers are the number of interactive activities to design, how much existing content must be inventoried, migrated or rebuilt, how many content types your authors need, whether H5P results must feed the gradebook, and how many test cycles the work requires. Ask for the quote to split one-time build work (design, configuration, authoring templates, testing, training) from recurring work (content reviews, library and platform upgrades, support). Ask which items are fixed in the scope and which are priced as additional work if requirements change.

How long does an H5P implementation in Moodle take?

Timing is set mostly by scope and by how quickly your people can review content. The largest factors are the volume of content to build or migrate, the number of courses and content owners involved, the number of approval rounds, and the availability of a staging environment with test accounts. If the H5P work is combined with a platform upgrade, add that effort to the plan. For example, Moodle 5.1 requires 64-bit PHP 8.2 or later, and sites must be on Moodle 4.2.3 or later to upgrade. Your Moodle version and hosting setup should be confirmed before the timeline is agreed in writing.

What must our team provide for an H5P engagement?

Your team must provide people and access, not just a brief. You need named authors who will build and maintain content, subject experts who check accuracy, and a decision maker who approves content standards, grading rules and the sign-off criteria. Engineering needs administrator access to a staging Moodle, test accounts for each role (student, teacher, and content author), and sample courses that reflect real use. Legal or accessibility reviewers should be named early if content must meet internal policies. Agree on who answers questions and how quickly, because slow review is one of the most common causes of delay.

Can our internal staff implement H5P in Moodle without outside help?

Yes, many teams can, provided they have Moodle administration skills, time for testing, and someone who owns content standards. Outside help is most useful for the decisions that are hard to reverse, such as how the content bank is organized, how H5P scores flow into the gradebook, and how shared content is governed across courses. Ask your team to estimate how many hours they can commit over the build and who will maintain the setup after go-live. If that capacity is uncertain, a fixed-scope engagement can cover the build while your staff take over operations.

How are grading decisions made for H5P results in Moodle?

Grading decisions are made in the design phase, before any content is built. The team should decide whether each H5P activity reports a score to the gradebook, what the passing score is, how many attempts count, how completion is defined, and how the score is weighted in the grade category. Not every H5P content type reports results in the same way, so test each type you plan to use in your installed Moodle version and confirm the grade passback behavior before you commit to a grading model. Record the rules in writing so teachers and auditors can see how a grade was produced.

What happens to H5P content after go-live in Moodle?

After go-live, the work shifts to keeping the platform and content current. Moodle ships major releases in April and October and minor point releases every two months, so the platform needs a planned upgrade cycle. Moodle 4.5 has security support until 4 October 2027, and Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Each upgrade should include regression testing of key H5P activities and grade flows. Ongoing content review, library updates and support can be handled by your team or through a retainer, and the split should be agreed in writing.

What should we test after a Moodle upgrade with H5P content?

Test a representative sample of each H5P content type, not only the home page or a single course. Check that activities render and respond, that scores still reach the gradebook with the same values, that completion and passing rules still work, and that reports and exports show the expected data. Confirm that the content bank items and their reuse across courses still behave as designed. For Moodle 5.1, also confirm that the web server document root points to the new /public directory, because otherwise the site may show directory listings or errors. Keep the test results so you can show what was checked and when.

How DeployOpen scopes and delivers Moodle H5P implementation

DeployOpen plans and builds H5P activities and the content bank inside a Moodle site that runs in infrastructure you control. Each engagement starts with a written scope that defines which H5P content types, courses and shared libraries are covered, then moves through build, testing, documentation and handover before any support begins.

How we scope

Inventory the H5P content types your courses need and confirm which ones your Moodle version supports.
Define which content lives in the shared content bank and which stays local to a single course.
Agree in writing who authors, reviews and retires shared interactive content, and how grades from H5P activities feed the gradebook.

How we build

Configure the H5P activity and content bank settings, including content reuse permissions and category structure.
Set up H5P library installation and update handling so content keeps working across planned Moodle upgrades.
Test completion and grade passback for representative H5P activities in a staging site before any course uses them.

How we hand over

Document the content bank structure, naming conventions, reuse rules and review workflow your authors will follow.
Deliver a runbook covering H5P library updates, grade checks and troubleshooting for common learner-facing issues.
Walk your course designers and administrators through the governance model and confirm ownership of shared content.

How we support

Ongoing support, upgrades and testing of H5P content after each Moodle release are available as a retainer.
Review the content bank periodically to retire duplicate or outdated interactive items, as agreed in the written scope.
Confirm with your Moodle version's release notes which H5P and content bank behaviors change before scheduling an upgrade.