WP Composer: независим, community-funded заместител на WPackagist за WordPress пакети в Composer
Ако поддържаш WordPress проекти с Composer, вероятно WPackagist е бил в основата на workflow-а ти с години. Реално той се превърна в де факто хранилище (Composer repository) за инсталиране на плъгини и теми от WordPress.org директорията, когато искаш dependency management извън wp-admin.
През март 2026 г. WPackagist беше придобит от WP Engine – хостинг компания, подкрепена от private equity. Това вдига съвсем резонни въпроси за независимостта на инфраструктура, която е критична за огромна част от WordPress екосистемата, и за това как се взимат решенията около наличност, посока и поддръжка. На този фон Roots излязоха с алтернатива: WP Composer.
Какво представлява WP Composer и защо е важен
WP Composer е независим, финансиран от общността и изцяло open source Composer repository за WordPress плъгини и теми. Проектът е изграден и поддържан от Roots и е замислен като инфраструктура, която да не зависи от решенията на една корпорация.
Исторически WPackagist е създаден от Outlandish и е поддържан с години, но в по-късния си период започна да личи занемаряване: по-бавни обновявания, ограничена поддръжка и липса на реален community input. След придобиването притесненията закономерно се задълбочават – включително и около прозрачността: публичният GitHub репозиторий на WPackagist (https://github.com/outlandishideas/wpackagist) вече не отразява коректно живия сайт.
Когато фундаментален developer tooling се контролира от един играч, общността губи глас: решенията се местят от публична дискусия към „затворени“ бизнес приоритети. Затова независимостта и прозрачността тук не са идеология, а прагматичен инженеринг риск.
Roots поддържат и детайлна съпоставка на WP Composer и WPackagist (performance, metadata и разлики в поведението): https://wp-composer.com/wp-composer-vs-wpackagist.
Какво точно предлага WP Composer
WP Composer предоставя всеки безплатен плъгин и тема от директорията на WordPress.org, като ги прави инсталиируеми през Composer. Ключовото е, че идва с по-чисто именуване на пакетите и модерни Composer механизми за metadata.
Най-осезаемата промяна за ежедневната работа: плъгините са под wp-plugin/<em>, а темите под wp-theme/</em>. Тоест – край на префиксите wpackagist-plugin и wpackagist-theme.
{
"repositories": [
{
"name": "wp-composer",
"type": "composer",
"url": "https://repo.wp-composer.com",
"only": ["wp-plugin/*", "wp-theme/*"]
}
],
"require": {
"wp-plugin/woocommerce": "^10.0",
"wp-theme/twentytwentyfive": "^1.0"
}
}WP Composer е и препоръчителното хранилище, когато го комбинираш с пакетите на Roots за WordPress core – roots/wordpress, roots/wordpress-full и roots/wordpress-no-content. В типичен Bedrock проект това означава: roots/wordpress за core и WP Composer за плъгини/теми.
Миграция от WPackagist към WP Composer (стъпка по стъпка)
Ако вече имаш проект с WPackagist, преминаването е буквално няколко команди. Идеята е: (1) махаш старите пакети с префиксите на WPackagist, (2) сменяш repository конфигурацията, (3) добавяш пакетите отново, но с новото именуване.
1) Премахни wpackagist пакетите
composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive2) Смени repository конфигурацията
composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com3) Добави пакетите с новото именуване
composer require wp-plugin/woocommerce wp-theme/twentytwentyfiveАлтернатива: автоматична миграция на composer.json
Roots поддържат и shell script, който автоматично обновява composer.json: https://github.com/roots/wp-composer/blob/main/scripts/migrate-from-wpackagist.sh.
curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.shАко използваш GitHub Action-а на Roots за следене на обновления на плъгините, имай предвид и промяна в именуването: WPackagist Changelog Action вече е WP Composer Changelog Action и поддържа изцяло новите формати wp-plugin/<em> и wp-theme/</em>: https://github.com/roots/wp-composer-changelog-action.
Performance: защо WP Composer е значително по-бърз
WP Composer използва Composer v2 metadata-url протокола, който позволява на Composer да изтегля metadata само за пакетите, които реално са нужни за dependency resolution.
При WPackagist картината е по-старата: provider-includes подход, при който Composer трябва да свали големи index файлове с metadata за хиляди пакети, преди изобщо да може да резолвне зависимостите ти. Това се усеща веднага при „студен“ resolve (без cache) и при CI.
Времена за resolve (cold resolve, без cache)
По-ниско е по-добре. Данните по-долу са за Composer 2.7+.
- 10 плъгина: WP Composer 0.7s срещу WPackagist 12.3s (около 17x по-бързо)
- 20 плъгина: WP Composer 1.1s срещу WPackagist 19.0s (около 17x по-бързо)
Metadata и caching разлики
- Composer v2
metadata-url: WP Composer – Yes, WPackagist – No - CDN caching: WP Composer –
public, max-age=300, WPackagist –no-cache, private - Per-package файлове: WP Composer – immutable, content-addressed, cached indefinitely; WPackagist – not content-addressed
Бележка за benchmark-ите
Тестовете са пускани от една локация с Composer 2.7+. Възможни са разлики по региони и мрежови условия. Benchmark скриптовете са публични: https://github.com/roots/wp-composer/tree/main/benchmarks.
Изцяло open source (и форкваемо)
Целият проект – application code, документация и deployment конфигурация – е публикуван като open source в GitHub: https://github.com/roots/wp-composer. Това не е просто витрина: всеки може да форкне проекта и да подкара собствена инстанция, ако има нужда или иска да валидира имплементацията.
Финансиране от общността
WP Composer се финансира изцяло от общността чрез GitHub Sponsors: https://github.com/sponsors/roots. Това покрива инфраструктурата, разработката и поддръжката – с идеята tooling-ът да остане независим и свободно достъпен за всички, които разчитат на Composer в WordPress.
Накратко
- WP Composer е независим Composer repository за WordPress плъгини и теми, поддържан от Roots и финансиран от общността.
- Пакетите са с чисти имена:
wp-plugin/<em>иwp-theme/</em>(безwpackagist-префикси). - Миграцията от WPackagist е директна: remove → swap repository → require с новите имена (или през готовия migration script).
- По performance линия WP Composer печели с Composer v2
metadata-url, по-добро caching поведение и значително по-бързи cold resolve времена. - Целият проект е open source и може да бъде форкнат и пуснат като собствена инстанция при нужда.
Елена Димитрова
Специалист по дигитален маркетинг и анализи. Интересувам се от Google Analytics и вземане на решения, базирани на данни. Измерването е първата стъпка към развитието.
Всички публикацииОще от Елена Димитрова
WordPress Studio 1.7.0 и новият Studio CLI: локални сайтове, preview среди и WP-CLI от терминала
WP Media Cleanup: как безопасно да изчистиш неизползваните image вариации в WordPress и да си върнеш дисковото място
WP-CLI и Abilities API за Wordfence: управление на сигурността през терминал и AI агенти