Замяна на нативните Open Badges на Moodle с Badges Ninja (по-добър дизайнер, същото API)
Moodle предлага нативни Open Badges, но дизайнерът е ограничен, а преживяването на получателя е заключено вътре в Moodle. Вместо това издавайте credentials на Badges Ninja въз основа на завършванията в Moodle.
Nacho founded Badges Ninja to make issuing verifiable digital credentials as simple as a single API call — Open Badge v2.0 badges and certificates, minted, hosted, and verifiable without standing up your own issuer infrastructure.
Moodle издава нативни Open Badges още от версия 2.5 и за много администратори на курсове това е достатъчна причина никога да не потърсят друго решение. Вградено е, безплатно е и технически произвежда credential, съответстващ на стандартите. Тогава защо толкова много администратори на Moodle се оказват разочаровани, докато издадат петдесетия си бадж?
Честният отговор: системата за баджове на Moodle е проектирана да отметне квадратче за съответствие, а не да бъде продукт за издаване на credentials. Работи, но работи както работи функция, прикачена към LMS — функционална, остаряла и ограничена от рамките на платформата, в която живее. Ако някога сте се опитвали баджа на Moodle да изглежда като нещо различно от кръгла clip-art икона, или сте чували завършил студент да пита „чакай, къде всъщност виждам това нещо?“, вече познавате тази празнина.
Това не е критика към Moodle — той е отличен LMS и неговият механизъм за критерии на баджове (завършване на курс, завършване на дейност, ръчно присъждане, членство в кохорта) е наистина добре обмислен за задействане на credential. Проблемът е всичко, което идва след задействането: инструментите за дизайн, преживяването на получателя и видимостта на баджа извън вашата инстанция на Moodle. Точно за тази част е създаден badges.ninja и не се налага да се откажете от логиката за завършване на Moodle, за да го използвате — просто насочвате задействането към различен механизъм за издаване.
Къде нативните баджове на Moodle не достигат
Дизайнерът е компоузър на изображения, базиран на координати, а не инструмент за дизайн. Редакторът за баджове на Moodle ви позволява да изберете базово изображение, да добавите няколко предварително зададени икони отгоре и да коригирате позицията с пикселни отмествания. Няма библиотека с форми, няма система от палитри, няма избор на шрифтове извън вградените в набора икони. Ако вашата организация има бранд — лого, цветова палитра, специфичен визуален език за вашите сертификати — редакторът на Moodle не може да го изрази. Повечето институции в крайна сметка проектират графиката на баджа в Photoshop или Canva и качват плосък PNG, което обезсмисля наличието на вграден дизайнер.
Получателите се нуждаят от вход в Moodle, за да видят собствените си баджове. Присъдените на обучаем баджове живеят вътре в неговата профилна страница в Moodle. Ако той вече е напреднал след курса, забравил е институционалните си credentials, или институцията междувременно е деактивирала акаунта му, баджът на практика изчезва от негова страна — макар че основното твърдение (assertion) може все още да се разрешава чрез backpack конектора на Moodle или публичната страница на баджа. Няма отделно, брандирано, винаги достъпно място, където получателят може да влезе само с имейла си и да види всеки credential, който някога е спечелил във всеки курс.
Споделянето е второстепенна мисъл. Moodle може да изпраща баджове към услуга, съвместима с Mozilla Backpack, и излага публичен URL за верификация за всеки бадж, но няма вграден поток „Добави в LinkedIn“, няма бутон за споделяне с едно кликване и няма анализ на ангажираността дали някой изобщо е погледнал баджа след издаването му. За програми, които искат баджът да работи като маркетинг от уста на уста — bootcamp-и, доставчици на продължаващо обучение, корпоративни обучения — това е реална пропусната възможност.
Груповите операции са тромави. Присъждането на бадж на цяла кохорта работи, ако всички завършат задействащата дейност вътре в Moodle едновременно. Но ако трябва да попълните ретроактивно баджове за минала кохорта, да импортирате исторически завършвания от електронна таблица, или да издадете бадж за нещо, случило се изцяло извън LMS, се озовавате да пишете SQL срещу базата данни на Moodle или да се борите с инструменти за импортиране на CSV, които не са създадени специално за баджове.
Моделът за замяна: запазете задействанията на Moodle, сменете издателя
Не е нужно да мигрирате от Moodle, за да решите това. Най-чистият модел е да оставите Moodle да продължи да върши това, в което е добър — проследяване на завършването на курс, завършването на дейност, членството в кохорта — и да го накарате да извиква API-то на Badges Ninja в момента, в който се задейства условие за завършване, вместо (или заедно с) присъждането на неговия нативен бадж.
Moodle поддържа това по няколко начина:
-
Webhook за завършване на курс / polling на Moodle Web Services (REST). API-то core_completion на Moodle излага състоянието на завършване за всеки потребител по всеки курс. Лека планирана задача (планирана cron задача на Moodle или външна cron задача, която удря REST API-то на Moodle) може да прави polling за новозавършени записвания и за всяко от тях да извика крайната точка за награди на Badges Ninja.
-
Кука в локален плъгин. Ако имате разработчик в екипа, системата от събития на Moodle (
\core\event\course_completed) може да бъде наблюдавана от малък локален плъгин, който изпраща HTTP заявка в момента на завършването — без забавяне от polling. -
Zapier/Make/n8n като свързващо звено, ако предпочитате да не докосвате кодовата база на Moodle — Moodle може да изпраща събития за завършване към получател на webhook-ове, който инструмент за автоматизация без код превръща в извикване за награда.
Ето и реалното извикване за награда, щом разполагате с име и имейл на потребител, завършил курса:
curl -X POST https://api.badges.ninja/awards \
-H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
-H "Content-Type: application/json" \
-d '{
"badgeId": "badge_moodle_course_completion",
"recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
"issuedOn": "2026-08-31"
}'
Или в Node, вътре в каквато и планирана задача или получател на webhook да използвате:
const response = await fetch("https://api.badges.ninja/awards", {
method: "POST",
headers: {
"X-Api-Key": process.env.BADGES_NINJA_API_KEY,
"Content-Type": "application/json",
},
body: JSON.stringify({
badgeId: "badge_moodle_course_completion",
recipient: { name: completedUser.fullname, email: completedUser.email },
issuedOn: Date.now(),
}),
});
const award = await response.json();
Имейлът на получателя се хешира с SHA-256 при съхранение, наградата автоматично получава уникален URL за верификация, QR код и A4 PDF сертификат, и — от решаващо значение — получателят може да я потвърди чрез вход с magic-link на badges.ninja/me, без да е нужен отделен акаунт в Moodle. Вижте пълната форма на заявката/отговора в референцията на API-то за награди и ръководството за автентикация за това как работят API ключовете от край до край.
Ако предпочитате да го правите на партиди — да речем, ретроактивно попълване на завършванията за цял семестър наведнъж, вместо свързване на събития в реално време — експортирайте завършванията от Moodle като CSV и използвайте директно потока за групово присъждане, който поддържа пауза/възобновяване за големи файлове. Това е разгледано подробно в как да издавате Open Badges от CSV.
Проектиране на самия бадж
След като инфраструктурата е налице, реалният дизайн на баджа отнема минути, а не тикет до вашия уеб екип. Визуалният дизайнер ви предоставя над 80 шаблона за форми, истинска система от цветови палитри, библиотеки с икони и качване на персонализирани шрифтове — така че бадж за „Advanced Statistics — Completed“ наистина може да изглежда като принадлежащ на бранда на вашата институция, вместо като общ иконка за постижение на Moodle.

Всеки API ключ има зададен обхват и може да бъде отменен от същото табло, от което управлявате баджове и издатели, така че предаването на интеграционния credential на разработчик (или инструмент за автоматизация като Zapier) не означава споделяне на входа на основния ви акаунт.

Едно до друго: преживяването на получателя
| Нативен бадж на Moodle | Badges Ninja | |
|---|---|---|
| Къде го преглеждат получателите | Вътре в профила на Moodle, изисква вход | badges.ninja/me, magic-link, без парола |
| Публична верификация | Да, публичен URL за всеки бадж | Да, крайна точка Open Badge v2.0 JSON-LD |
| Инструменти за дизайн | Фиксирана икона + отмествания на позицията | 80+ шаблона, палитри, персонализирани шрифтове/икони |
| Споделяне в LinkedIn | Ръчно, без вграден бутон | Нативен поток Add-to-LinkedIn-Profile |
| Групово ретроактивно издаване | SQL или ръчно CSV решение | Вградено групово присъждане с пауза/възобновяване |
| Видимост на ангажираността | Никаква | Статистика за преглед/споделяне на награда |
| Достъп след напускане на институцията | Обвързан със статуса на Moodle акаунта | Постоянен, собственост на получателя |
Moodle все още печели в едно отношение: ако единственото ви изискване е „баджът съществува, технически съответства на Open Badge v2.0 и живее вътре в LMS-а, който обучаемият вече използва“, нативните баджове не струват нищо допълнително и не изискват никаква интеграционна работа. Компромисът се проявява в момента, в който ви е грижа за качеството на дизайна, преносимостта след края на курса, или превръщането на издаването в сигнал за набиране на персонал/маркетинг — а това с времето важи за повечето институции.
За по-широк поглед върху това как другите платформи за Open Badges се сравняват по цена и функции, вижте сравнението на най-евтината платформа за Open Badges. А ако вашата институция претегля Open Badge v2.0 срещу по-новата спецификация за проверими credentials, обяснението Open Badge v2 срещу v3 разглежда коя от двете реално да пуснете днес.
Готови ли сте да издадете първия си проверим credential? Започнете безплатно на badges.ninja — визуален дизайнер, страница за публична верификация, PDF сертификат, изход в Open Badge v2.0. Не се изисква кредитна карта.
Как беше създадена тази статия
Някои публикации в този блог се изготвят с помощта на AI асистент, след което се преглеждат, проверяват и редактират от екипа на Badges Ninja преди публикуване. Всеки примерен код и цена се проверяват спрямо реалния продукт. Прочетете повече за нашия редакционен и AI процес на нашата страница за редакционния процес .

За автора
Nacho Coll
Founder & Engineer at Badges Ninja
Nacho founded Badges Ninja to make issuing verifiable digital credentials as simple as a single API call — Open Badge v2.0 badges and certificates, minted, hosted, and verifiable without standing up your own issuer infrastructure. Writes about the Open Badges spec, credential verification, and running a credentialing platform serverless on AWS, from the operator side of the wire.
Още от Nacho Coll
- Автоматизирайте Open Badges с Zapier, Make и n8n (рецепти без код)27.08.2026 г. · 10мин четене
- Как да добавите бутон „Add to Profile“ на LinkedIn към вашите Open Badges20.08.2026 г. · 10мин четене
- Open Badges vs. PDF сертификати: кое е подходящо за вашата програма през 2026 г.?10.08.2026 г. · 6мин четене

