В WooCommerce часто смотрят как на «еще один магазинный плагин», а по факту это набор типовых инженерных вопро

В WooCommerce часто смотрят как на «еще один магазинный плагин», а по факту это набор типовых инженерных вопросов, которые всплывают в каждом втором проекте: где хранить кастомные поля, как не убить производительность на каталоге, что делать с интеграцией CRM и как пережить обновления без сюрпризов.

У себя в проектах я обычно раскладываю WooCommerce по схеме:

плагин → хуки → кастомная логика → внешние системы

Именно на стыках чаще всего и ломается архитектура. Например, один раз заказчик хотел «просто добавить пару полей в карточку товара», а в итоге это потянуло за собой пересчет цен, отдельные правила кеша и доработку выгрузки в учетную систему. Классический типовой кейс из проекта.

Если смотреть на WooCommerce как на платформу интеграций, а не только на витрину, то вопросы сразу становятся правильнее: где расширять ядро, где достаточно фильтра, а где уже нужен отдельный сервис.

В следующих частях разберу те самые практические вопросы без маркетинговой пены — только то, что действительно влияет на поддержку и развитие магазина 🔧