WP-Recall. Подвожу итог.

Не знаю, каким получится данный опус, но я бы хотел получить на выходе некую ретроспективу для самого себя, и раз уж основное место в ней будет занимать вполне себе когда‑то великий, а для кого‑то до сих пор ужасный плагин WP‑Recall, то размещу эту публикацию именно здесь, где по сути всё и начиналось.
Я уже давно чувствовал необходимость дать какую‑то конкретику о том, что же происходит, но так и не смог выстроить для самого себя корректной модели развития событий тогда, когда это действительно было необходимо, а сейчас это скорее похоже на пук в пустоте — бесполезный, но в то же время такой необходимый, ибо нельзя всё вечно держать в себе, поэтому получайте. Начну издалека, но не переживайте, постараюсь кратко, зато станет понятна общая мотивация и причины некоторых поступков или их отсутствия.


Начало

Я уже не помню точно, но где‑то в 2011–2012 году во мне проснулся настоящий интерес к программированию. И хотя сейчас я бы не назвал свою деятельность в то время программированием, мои попытки засунуть нос в код плагинов WordPress казались мне очень увлекательными, а результат почти всегда удивлял и нередко повышал самооценку, толкая к новым свершениям. Когда я почувствовал в своих действиях достаточную уверенность, то увидел перед собой целый мир нереализованных возможностей, которые непременно необходимо реализовать. Помню, была местечковая доска объявлений на BuddyPress, в которую мне удалось напихать кринжовых идей и которую даже удалось успешно продать за 5 тысяч рублей (позже проект переедет на новый домен avito.ru, шутка). А как‑то вечером меня осенила потрясающая идея реализации проекта платного доступа к контенту. Суть была в том, чтобы пользователи могли публиковать текстовый и видеоконтент, закрывать его неким платным доступом и стимулировать своих подписчиков к его приобретению. Со своей стороны я должен предоставить только возможности для этого, ну и далее жить поживать, удерживая малую комиссию себе на радость.

И вот тут надо, видимо, сделать отступление, чтобы в полной мере прочувствовать момент. У меня по сути не было никаких навыков, позволяющих реализовать подобный проект, у меня не было никаких ресурсов. В то время я умел править чужой PHP‑код и пытался применять сей навык на фриланс‑бирже, большую часть времени подрабатывая контент‑менеджером. Но мне было на всё плевать, я видел цель и не видел препятствий. Я не анализировал рынок на предмет конкуренции, не пытался получить консультации со стороны или хотя бы соотнести свои возможности с масштабом задачи. Зачем, если я уже умею в PHP, а под боком есть такой удобный WordPress с зоопарком плагинов, правда? Madness... Madness and stupid.

После того как развернул сайт и проштудировал репозиторий WP, я быстро понял, что подходящих плагинов под эту задачу нет. Далее пришло понимание, что необходимо менять основную ценность — не просто закрывать какой‑то контент, но обеспечить продажу файликов, в которых этот контент будет находиться. Нужна была кастомная форма публикации, какая‑то загрузка, какая‑то оплата, какая‑то витрина — в общем, нужен был вполне себе полноценный интернет‑магазин цифрового контента. Имеющиеся плагины не покрывали текущих потребностей, я понял, что всё это дело придётся мне писать самому. А так как я понятия не имел о глубине этой жопы, то не остановился и приступил к реализации.

Собственно, моя наивность меня и берегла, потому что, имея довольно примитивные предположения о достаточном минимуме требуемого функционала, я довольно быстро этот примитивный минимум и реализовывал. Простая форма — есть, кнопка для загрузки файла на сервер — есть, кнопка на оплату — есть, взаимодействие по API с платёжкой — есть, витрина через архивные страницы записей — есть. Чек‑поинт, можем запускаться!

А нет, не можем. Должен быть личный кабинет. Для отзывов покупателей продавцам.

Я сразу решил, что в админку WP никто попадать не должен, а BuddyPress в моём проекте делать нечего. Мне нужен был простой личный кабинет — пароль там задать или имя, но главное — надо было прикрутить публикацию отзывов, это была бы имба, а раз я уже столько наговнокодил фоном, то сделаю и этот функционал быстро, и так же качественно, как и всё остальное.

Действительно, у меня получилось сделать задуманное довольно быстро — весь код ЛК поместился в одном файлике на сто строк. OMG, я чувствовал себя Цукербергом, чертовым гением, который уложил всё нужное в один файл, не то что этот BuddyPress — он просто распух на десятки, а может, и сотни файлов с кодом, который хрен пойми что делает. Не то что мой код, верно говорят: краткость — сестра таланта!

Итак, требуемый функционал моего супер‑пупер проекта был готов. Теперь‑то можем запускаться? Ну, наверное, можем, но не хотелось зазывать потенциальных клиентов на пустой сайт, необходимо чем‑то наполнить каталог. И как‑то недолго я думал, чем наполнять, решение было очевидным — выделить всё то, что я уже наваял, в отдельные плагины и разместить в каталоге. Так там появились: плагин формы публикации записей, плагин для загрузки и продажи файлов, плагин интернет‑магазина, плагин отзывов с личным кабинетом.

Как были написаны эти плагины — предмет отдельного изучения для патологоанатома, но случилось важное: именно в этот момент я сколотил из говна и палок телегу, на которой буду ехать более 10 лет.


Расцвет

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

Наконец получив на руки готовую концепцию своего главного продукта, я ещё раз пробежался по сайтам и снова наспамил, но уже с фокусом на функционал личного кабинета — простого, лёгкого, но функционального!

Старожилы помнят, что в своих первых итерациях плагин содержал внутри себя весь функционал таких расширений. Со временем там появились группы, рейтинг, форма публикации, баланс пользователя, интернет‑магазин также был перенесён туда.

И знаете что? Это сработало. Люди активно посещали мой ресурс, интересовались новым плагином, его функциональными возможностями. Чувствовалось, что есть целый пласт людей, которым данное направление было интересно, а моя поделка оказалась востребованной. Я попал в точку.

К 2013‑му году на сайте сформировалась постоянная активность, а над плагином велась уже постоянная системная работа. Впоследствии все расширения плагина были выделены в отдельные товары каталога — дополнения к плагину, а их список стал стремительно расширяться. Причём перечень этих дополнений рос не только в количественном, но и в качественном исполнении — возрастала их сложность.

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

К середине 2022 года было реализовано и выпущено в каталог более трёхсот! различных дополнений, закрывающих пользовательские потребности в самых разных областях. К этому также приложили руку сторонние разработчики, у которых была возможность добавлять на продажу или для свободного распространения свои товары.

Максимальное количество установок на сайтах достигло 5000. Пусть это не фантастические цифры, но они позволяли сохранять интерес и вовлечённость. Плагин был востребован.


Смысл всего

Это время не было лёгкой прогулкой — весь период шла напряжённая работа, направленная не только на разработку новых дополнений, но и на поддержку уже имеющегося зоопарка в каталоге. Всё это отнимало много времени и сил, оттого время пролетало незаметно, годы проходили в постоянной погоне за недостижимым идеалом. Хотелось больше оптимизировать, сделать гибче, добавить возможностей, но всё это лишь набор задач. Знал ли я, ЧТО именно хочу получить в итоге? И знал ли я, КАК достигнуть этого?

Это главные вопросы, которые и определили причину падения.

10 лет — достаточный срок, чтобы оглядеться и подвести какие‑то итоги. Когда реализовал всё, что только можно, и идей больше нет, самое время остановиться. А когда останавливаешься после долгого бега, начинаешь замечать нечто другое.

Не знаю, верно ли это, но мне на ум приходит аналогия с птичкой или хомяком. Хотя хомяк несколько ограничен в своих возможностях, поэтому пускай будет птичка 🙂 Птичка долгое время обустраивает свой быт, обеспечивает себя водой, едой, даже что‑то сколотила себе из мебели — вот такая умелая птичка, живёт и радуется, а потом вдруг оказывается, что её дом — это клетка. Сидит такая птичка, и вроде всё есть, можно и дальше радоваться жизни, а смысл?

А какой у меня был смысл моей деятельности? Вроде всё очевидно: развивай свой продукт, зарабатывай деньги! Ну хорошо, а кем я себя позиционирую, чего я вообще хочу? А вот это интересный вопрос.

Одним чудесным днём, реализуя очередное расширение к плагину, привычно, на автомате, накидывая опции, проектируя CRUD, закладывая хуки, я осознал, что упёрся в потолок. Я уже давно не занимался ничем по‑настоящему новым, я не решал возникающие передо мной вызовы — все были решены уже давно, моё развитие остановилось. Много позже я понял, что в тот момент я потерял смысл своей работы.

Мне понадобилось много времени, чтобы понять, что вся моя деятельность крутилась вокруг собственного развития. 10 лет напряжённой и плодотворной работы над своим проектом нужны были лишь для того, чтобы просто идти вперёд. Рос и развивался проект — рос и развивался я как разработчик. Как только я узнавал что‑то новое, я это тут же применял на практике. Функционал становился сложнее — я получал опыт архитектурной оптимизации. Надо было разработать с нуля сложный функционал — я учился его проектировать, а затем реализовывать. Требовалось интегрировать платёжную систему — я изучал стороннее API и использовал его. И всё это постоянно, итерационно, год за годом. Это не могло не начать повторяться.

В 2020 году я принял решение выйти на рынок труда в качестве наёмного разработчика. Это стало переломом моего мировоззрения. До этого я гордился своим делом, обеспечивал семью, считал, что необходимо оставаться свободным и двигаться именно в этом направлении и дальше, а сам исполнил такое... Но на первом же месте я ощутил такой мощный прилив сил и мотивации при решении большой и сложной задачи, что мои сожаления я оставил позади и больше о них не вспоминал. Птичку выпустили из клетки! Наконец я увидел, насколько ограничены мои знания, насколько ограничен я был в применяемых инструментах — в первую очередь самим WordPress, я осознал, насколько широк и необъятен мир разработки, сложны проекты и решаемые задачи. За последующие годы я прочитал много книг по специальности, поработал с множеством проектов — от банка до многоуровневой партнёрской сети, участвовал в сложнейших миграциях проектов на новую архитектуру и ясно вижу СМЫСЛ своей деятельности и работы именно в этом! Постоянное движение вперёд и постоянное профессиональное развитие — это то, что задаёт драйв в моей жизни, и я благодарен судьбе, что смог это осознать не слишком поздно.


Заключение

Плагин WP‑Recall никогда не был целью сам по себе, он был лишь средством для достижения цели. Я благодарен ему за фундамент, который сформировал с помощью него, но он строился слишком долго. Есть ли у меня желание вернуться к нему, переписать или просто взять на поддержку то, что вроде и так, до сих пор, неплохо работает? (хотя, конечно, уже не уверен). Нет. В первую очередь из‑за имеющихся ограничений WordPress. Это уже порядком проржавевшая клетка, в недрах которой тихо доживает свой век WP‑Recall, и я в эту клетку уже никогда не вернусь.

Признаюсь, что у меня уже реализован плагин по мотивам WP‑Recall, я принес в него все лучшее, что было в WP‑Recall и все лучшие практики из своего опыта, но как оказалось я написал его в стол, просто, чтобы закрыть внутренний таск, который я поставил себе несколько лет назад, когда еще занимался внутренним самообманом о каком то возрождении. В одну реку не войти дважды и сейчас изменился уже я сам. Я не готов уделять время на поддержку и развитие продукта, тратить внутренние ресурсы на переписки с пользователями и проводить дополнительные часы после основной работы за его кодом.

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

Сайт на WordPress — путь в никуда?

WordPress — путь в никуда? Реальный опыт борьбы с архитектурными ограничениями

WordPress — это не просто система управления контентом, это целая экосистема, на которой работает 43% всех сайтов в мире. Его популярность объяснима: низкий порог входа, огромное количество тем и плагинов, активное сообщество. Однако за этой внешней простотой и доступностью скрываются архитектурные ограничения, которые превращают платформу в «путь в никуда» для проектов, сталкивающихся с ростом нагрузки и посещаемости.

Миф о масштабируемости

Часто можно услышать аргумент, что WordPress масштабируется, и в качестве примера приводят крупные проекты вроде TechCrunch или даже сайта NASA. Это действительно так, но за этим масштабированием стоит огромная работа по преодолению фундаментальных ограничений платформы. Сайты высокого уровня не растут на WordPress — они выживают вопреки ему, превращая его обслуживание в отдельную инженерную дисциплину.

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

Рассмотрим ключевые архитектурные ограничения, делающие WordPress тупиковой ветвью развития для серьёзных проектов.

1. Технологический стек: вы заперты в прошлом

WordPress по своей сути является монолитной системой, жёстко привязанной к PHP и MySQL. Это означает, что вы не можете использовать современные JavaScript-фреймворки для фронтенда (например, React, Vue, Next.js) без сложных и не всегда элегантных надстроек, таких как Headless WordPress. Такой подход, хоть и возможен, создаёт «налог на сложность»: вы фактически управляете двумя отдельными технологическими стеками, что удваивает требования к CI/CD, безопасности и обслуживанию. Более того, переход на Headless-архитектуру часто ломает привычные рабочие процессы редакционного отдела, например, функцию «живого превью», что влечёт за собой дополнительные инженерные затраты на её восстановление.

2. Неоптимизированные запросы к БД и «скидка масштаба»

Одна из главных проблем WordPress — крайне неэффективная работа с базой данных. Платформа генерирует от 20 до 100 запросов на одну загрузку страницы. Это само по себе создаёт высокую нагрузку, но в сочетании с неоптимизированными запросами от плагинов или тем ситуация становится критической.

Каждый плагин может добавлять свои собственные запросы, и их количество растёт пропорционально функциональности сайта. Проблемы усугубляются, когда запросы выполняются без должных индексов или используют глубокую пагинацию с оператором OFFSET. Например, в одном из кейсов WP_Comment_Query приводил к выполнению запроса, занимавшего 68 секунд, что, в свою очередь, приводило к простоям сайта. Причина — отсутствие индексов и глубокий OFFSET, заставлявший базу данных перебирать тысячи строк.

Другой пример: при 250–300 одновременных посетителей сайт на WordPress падал, загружая все 8 ядер на 100% процессора, несмотря на 32 ГБ оперативной памяти. Причиной была неэффективность запросов, умноженная на конкуренцию за ресурсы. В таких условиях «скидка масштаба» не работает — проблема не в железе, а в архитектуре.

3. Монолитная архитектура как «бутылочное горлышко»

Монолитность WordPress проявляется в мелочах. Например, настройки home и site_url хранятся в базе данных, что затрудняет управление конфигурациями при горизонтальном масштабировании. Встроенный планировщик заданий wp-cron срабатывает при каждом запросе к сайту, отнимая ресурсы PHP-воркеров, которые нужны для генерации страниц. А механизм сессий, хранящий данные на файловой системе каждого отдельного сервера, делает горизонтальное масштабирование (добавление новых серверов) практически невозможным без дополнительных «танцев с бубном».

Конец пути: необходимость сложной миграции

Когда проект вырастает из штанишек WordPress, его ждёт сложный и болезненный процесс миграции на более современную архитектуру. За примерами далеко ходить не надо. Известное медиа VentureBeat, которое на момент миграции насчитывало более 6 миллионов ежемесячных посетителей, ушло с WordPress на headless-решение на базе Contentful. Причина — устаревший стек, ограничивающий развитие и усложняющий внедрение новых функций. Миграция более 130 000 материалов потребовала разработки сложной системы на Python-скриптах, аудита данных и пересмотра всей инфраструктуры.

Вместо того чтобы «подпиливать» WordPress напильником, крупные компании двигаются в сторону сервисно-ориентированной архитектуры (SOA) и composable-подходов. Это означает:

  • Разделение фронтенда и бэкенда (Headless): использование Next.js или других современных фреймворков для отображения контента, получаемого через API.

  • Вынос критических компонентов: миграция медиафайлов в облачные хранилища (S3, CDN), а сессий — в Redis, чтобы сделать приложение «stateless» и способным к горизонтальному масштабированию.

  • Использование специализированных инструментов: применение Query Builder'ов или ORM для работы с базой данных вместо нативных, неоптимизированных запросов WordPress.

  • Использование компонентов Symfony: для узкоспециализированных задач, таких как консольные команды (замена wp-cron), брокеры очередей (для асинхронной обработки задач, например, отправки писем или генерации изображений) и событийный менеджер, позволяющий гибко реагировать на действия пользователей.

Собственный опыт

Когда я только начинал путь разработчика, то часто мог повторять, что «на WordPress можно построить любую платформу, запустить любой проект, было бы желание», просто потому, что я активно работал с этой CMS, видел гибкость, лёгкий старт, безграничные возможности. Сейчас я уже не так наивен. Имея за плечами многолетний опыт, я могу сказать твёрдо: если вы настроены серьёзно, то выбирать WordPress — большая ошибка.

В какой-то момент своего профессионального развития мне пришлось несколько раз буквально спасать бизнес, в котором крутились большие деньги, от тех проблем, с которыми они столкнулись. Вроде всё просто: разверни WordPress, подбери шаблон, плагины — и можно начинать. И там тоже так думали.

Первый проект — сложная витрина множества типов записей с переплетением категорий и метаданных. Главная проблема: при выключенном кешировании количество запросов на странице — от 1 до 3 тысяч в зависимости от наполнения и типа выводимого контента. Формирование ссылки только на одно изображение при их выводе приводит к появлению трёх дополнительных запросов, а изображений может выводиться несколько сотен. Сложная фильтрация записей по десяткам параметров работает крайне медленно. Разработчики не знают, что с этим делать. Попытка резолвить поиск через WP_Query приводит к диким перегрузкам. В качестве решения используется банальная выборка всех данных в оперативную память и перебор по этим данным для представления в качестве результатов фильтрации.

Тщательно проанализировав структуру проекта, я выделил основные сущности, работу с которыми необходимо было полностью снять с рельс WordPress, полностью изменить порядок их хранения в базе данных, перевести работу с запросами на собственный query-builder. Количество запросов на странице удалось уменьшить в сотни раз, практически полностью отказаться от кеширования, отдавая посетителям актуальные данные, и понизить потребляемые ресурсы сервера в десятки раз. В результате было сформировано ядро, на котором компания впоследствии разворачивала все свои сайты на WordPress и делает это до сих пор. Я уверен, что общий принцип был порядком доработан благодаря самоотверженным действиям уже других разработчиков.

Второй проект — крупный портал, также с множеством различных типов записей и огромным количеством метаданных для каждой записи. Также на борту — тысячи запросов на страницу, крайне сложная и тяжёлая система фильтрации функционала. Тут разработчики уже подошли с большей выдумкой: создавались многочисленные таблицы с промежуточными данными, которые формировали основной вывод пользователю на сайте, а также участвовали в подборе результатов при сложной фильтрации и поиске по контенту. Сами промежуточные таблицы периодически обновлялись по крону, и мало кто мог вообще что-то внятное рассказать о том, сколько именно было крон-задач на сайте и чем каждая задача занималась. Из-за специфики работы крона никогда нельзя было быть уверенным, когда именно применённые в административной части изменения будут предложены текущему пользователю: может, через 5 минут, а может, и через полчаса. Сервер периодически падал из-за наложения одной тяжеловесной фоновой крон-задачи на другую.

На этом проекте я подошёл уже более серьёзно к решению возникших проблем, поставив целью сформировать полностью новый фундамент из основных сущностей проекта, полностью отказавшись от промежуточных таблиц и использования крона. Тут я уже применил полноценную ORM, брокер очередей и несколько удобных Symfony-компонентов для организации консольных команд, шины сообщений и валидатора данных. Проект был спасён и продолжает развиваться по сей день.

И в первом, и во втором случае было сохранено самое, на мой взгляд, лучшее от WordPress — его админка, ведь именно она цепляет изначально своим удобством и задаёт тон в дальнейшей работе с сайтом для его владельца. Административная часть сохранялась и дорабатывалась, в ней наводился порядок, появлялся единый кодовый стиль создания и вывода полей, а также сохранения данных через них. А кодовая база обоих проектов получила сервисно-ориентированную архитектуру, с которой приятно работать другим разработчикам, а значит, решается проблема с нахождением разработчика, который бы согласился работать с проектом.

И не стоит преуменьшать масштабы решаемых проблем: в обоих случаях были месяцы напряжённой работы по распутыванию функционального легаси из клубка «мегаудобных» WordPress-хуков, потрачены сотни тысяч рублей.

Прошло уже много лет с тех пор, как я только начинал работать с WordPress, и, оглядываясь назад, я не вижу какого-то качественного скачка в его развитии, к сожалению. Он застрял в прошлом с теми же проблемами, которые были у него изначально. Всё новое накручивается сверху, лишь усложняя функционал и усугубляя эти проблемы.

Так ли всё плохо?

Давайте вернёмся к тому факту, на который мы указывали в начале этой статьи, а именно к заявлению, что WordPress используется на очень большом количестве сайтов. Значит, очень большое количество разработчиков работают с этой экосистемой, разворачиваются сайты, разрабатываются и поддерживаются плагины, и эти разработчики всячески поддерживают эту CMS и её популярность. Они даже сбиваются в целые группы, где всячески пропагандируют общие подходы WordPress-разработки, обсуждают последние тенденции в его развитии и т.п. Я также состоял непродолжительное время в такой группе, но, к сожалению, не увидел в дальнейшем смысла в этом, так как общий настрой этой группы я нисколько не разделял. Зачем они этим занимаются? Можно ли говорить о том, что эти разработчики просто глупы, чтобы увидеть очевидное? На самом деле, и да, и нет.

Всех подобных разработчиков можно разделить на две группы. В первой окажутся те, кто пока не способен понять текущих проблем, и им достаточно той степени свободы, что платформа даёт. А во второй — те, кто уже давно использует в серьёзной работе совсем другие инструменты: Symfony и её компоненты, Laravel, но при этом остаётся востребован как WordPress-разработчик, ведь кто-то же должен обслуживать то, что уже работает на WordPress. Получается такая самоподдерживающая система, где первые активно разворачивают сайты для домохозяйств и бизнеса, а вторые эти сайты развивают или оптимизируют, но при этом вполне активно продолжают развиваться в совсем других направлениях.

Хотя, вспоминая опять же случай из практики, мне пришлось однажды включиться в работу над одним проектом, где подобный «оптимизатор» уже успел наследить, оставив после себя множество сомнительных бессистемных решений. Одной из наиболее заметных было: разбить функционал проекта на некие модули и выделить каждый модуль в виде отдельного плагина WordPress. На первый взгляд, это может показаться вполне логичным решением, но необходимо понимать, что плагин — это нечто отдельное от всего остального, и проект должен уметь работать без плагина. По философии плагина его можно отключать, а тут в плагины были вынесены критичные для проекта части, отключение которых делает работу проекта в принципе невозможной. К таким решениям приводит отсутствие элементарных понятий о какой-либо архитектуре, и это решение было лишь попыткой изобрести собственную архитектуру, не заботясь о её смысловой нагрузке. Возможно, где-то такие решения принимаются до сих пор, я не буду удивлён.

Именно поэтому для пользователей и разработчиков WordPress всё выглядит не так плохо. Необходимо дойти до определённой степени напряжения проекта, чтобы узкие места платформы начали выпирать острыми и болезненными гранями, заставляя обращать на себя внимание. Но будем честны: много ли проектов доживают до такого уровня? И много ли разработчиков работают с такими проектами? Большинство варится в «большом бульоне» кратковременных, несложных сайтов, куда заходят три с половиной посетителя. Возможно, эти сайты предполагали долгую жизнь, но так и не узнали об этом. Большинству никогда не случится познать проблемы роста, при которых WordPress станет костью в горле, просто потому, что никогда не вырастет ни проект, ни сам разработчик с этим проектом.

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

Заключение

Сказать по правде, я был несколько предвзят в этой статье к WordPress, нарочито активно указывая на его проблемные места. На самом деле их решение или обход уже описаны в документации ядра в виде Best Practices, так что работать с этим можно, но необходимо держать в уме много переменных. Знаменитая 5-минутная установка станет для кого-то обманчивой ловушкой на пути построения бизнеса или развития идеи.

Из всего вышесказанного я вывожу интересный парадокс: легкость разворачивания WordPress предъявляет высокий уровень к его эксплуатации!

WordPress — это идеальный инструмент для быстрого запуска простого сайта-визитки, блога или небольшого интернет-магазина. Но как только ваш проект начинает расти, CMS превращается в источник проблем, масштабируемых экспоненциально быстрее вашего бизнеса.

Архитектурные ограничения, неоптимизированные запросы, устаревший стек и монолитность делают долгосрочное развитие на WordPress дорогим и рискованным. Вместо постоянного гашения пожаров на «костылях» и плагинах для кеширования эволюционным путём становится переход на современную сервисно-ориентированную архитектуру с использованием компонентов, которые изначально проектировались для решения сложных, высоконагруженных задач. WordPress — это не тупик, но он слишком часто становится «путём в никуда» для амбициозных цифровых продуктов.

Плагин WP-Recall удаляется из репозитория

Дорогие пользователи,

После долгих лет развития и поддержки мы приняли непростое решение: с 1 июня 2025 года плагин WP-Recall будет удален из официального репозитория WordPress.

Этот шаг не был спонтанным — мы долго взвешивали все «за» и «против», но в итоге пришли к выводу, что больше не можем уделять проекту достаточно внимания. Время идет, технологии меняются, и мы решили сосредоточиться на новых приоритетах и направлениях.

Что это значит для пользователей?

  • Последняя стабильная версия WP-Recall останется доступной для скачивания на codeseller.ru.

  • Плагин продолжит работать на сайтах, где он уже установлен, но официальные обновления и поддержка прекращаются.

  • Безопасность и совместимость с новыми версиями WordPress и PHP не гарантируются.

Возможность продолжить развитие

Если среди вас есть разработчики или компании, заинтересованные в поддержке и развитии WP-Recall, мы готовы рассмотреть варианты передачи проекта. Вы можете связаться с нами:

  • Через личные сообщения на codeseller.ru

  • По почте поддержки сервиса

Мы искренне благодарим всех, кто использовал WP-Recall, делился идеями, сообщал о багах и помогал делать плагин лучше. Ваша поддержка была для нас очень важна!

С уважением,
Команда WP-Recall 🚀

Сервис приостанавливает возможность оплаты заказов

Уважаемые посетители!

С 1-го января 2025 года сервис CodeSeller перестает предоставлять возможность приема платежей через текущие способы оплаты, а вместе с тем прекращается и возможность оплаты заказов с платными товарами.

Все платные товары будут сняты с публикации 1-го февраля 2025 года. Просим авторов платных товаров в течении этого срока обеспечить перевод своих товаров в бесплатный формат, снять товары с публикации или опубликовать товары на других площадках.

Все бесплатные товары будут доступны для скачивания в прежнем режиме.

Всем спасибо! С наступающим Новым Годом!

 

Изменения в порядке предоставления поддержки к товарам

Всем привет!

Наш сервис очень положительно относится к публикации пусть и простых, но бесплатных товаров. В прошлом году мы даже какое то время проводили конкурс, чтобы мотивировать разработчиков добавлять бесплатные товары в наш каталог. Безусловно, каждому покупателю очень нравится загружать бесплатный продукт, но разработчики реагируют на перспективу публикации такого товара очень вяло, ведь простой публикации мало - даже бесплатный товар необходимо поддерживать, а запросы от пользователей товара ничем не ограничены.

Сегодня, как нам кажется, мы нашли решение как повысить мотивацию к публикации бесплатных продуктов.

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

Теперь разработчик может опубликовать бесплатный товар, но при этом также назначить стоимость его поддержки на форуме. Пользователь может как и ранее загрузить такой товар совершенно бесплатно и далее пользоваться им, но если у него возникла необходимость обратиться за помощью к автору товара, то достаточно на странице товара отдельно оплатить поддержку товара, получив тем самым доступ к его форуму, чтобы уже там опубликовать тему в обычном порядке.

Данную возможность следует рассматривать в позитивном ключе как для продавцов, так и для покупателей.

Разработчики получают больше мотивации для публикации бесплатных товаров, с расчетом на окупаемость своей поддержки, а покупатели получают доступ к большему числу бесплатных товаров для возможного ознакомления с необязательной оплатой поддержки к этому товару. Набор инструментов продавца для организации стратегии распространения своей продукции стал шире и удобнее, а покупатель получает возможность получить бесплатно товар, который будет уже чуть сложнее и функциональнее, а значит полезнее, чем то, что публиковалось бесплатно ранее.

Например, теперь дополнение RegPay распространяется совершенно бесплатно! И это стало возможным только потому, что я, как его автор, могу теперь изменить концепцию его распространения и монетизировать не сам товар, а только услуги прилагаемые к нему.

Конечно, не все сразу, но мы верим, что это только начало и со временем это позволит изменить подход к реализации большинства товаров на нашем сервисе.

Оплата заказа на платные товары, как и ранее, будет означать автоматическое назначение доступа к поддержке этого товара.

Итак, убедительно прошу наших уважаемых продавцов обратить внимание на поле "Стоимость поддержки" в форме публикации/редактирования товара, оно стало чуть более важным и его заполненность напрямую влияет на организацию поддержки товара.

Важно! Если в данном поле не указана стоимость поддержки, значит доступ на форум поддержки товара ничем не ограничен и является бессрочным.

Просьба пройтись по своим товарам, проверить и установить корректные значения в этом поле.

Спасибо за внимание, всем хорошего дня!

О медалях, наградах и прочем варезе

Друзья, всех приветствую!

Администрация сайта CODESELLER.RU, в моем лице, считает нужным высказать свое мнение на непростую тему.
Мы всегда следим за соблюдением авторских прав на товары в нашем каталоге и стараемся принимать товары только от их непосредственных авторов, но, как оказалось, у нас не было сформировано четкого отношения к публикациям в определенной товарной категории. Категория "Графика и дизайн", как оказалось стала рассадником варезного хлама, который представляется под видом различных сборок и наборов медалек, наград за достижения, а также подарков для пользовательских профилей.

Пришло время сформулировать ясную точку зрения на публикации подобного рода.

Давайте определимся, что всякое изображение, как какой-нибудь плагин или дополнение, является чей то авторской собственностью и распространять его, установив произвольную стоимость может только его автор.

В дальнейшем, мы отказываемся принимать сборки или наборы изображений под соусом "их свободного хождения в сети интернет", также как будем отказывать в публикации наборов, например, бесплатных плагинов из репозитория WordPress, хотя, вроде как и они, распространяются свободно. И то и другое имеет своего автора и только он может решить где и на каких условиях будет распространяться его работа.

Впоследствии, в каталог нашего сервиса будут приниматься работы от только их непосредственных авторов. Это непреложное правило впредь будет действовать на все товарные категории каталога.

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

Давайте вместе уважать и соблюдать авторское право. Всем хорошего дня. Спасибо.

Ведение бизнеса в интернет, прием средств, налоговая, онлайн-касса. Стрим.

Всем привет!

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

Поскольку подобные вопросы поступают довольно часто, я решил провести по этой теме стрим на нашем youtube-канале, где постараюсь ответить на наиболее частые вопросы и опишу все необходимые шаги для запуска вашего интернет-бизнеса.

Во время трансляции мы коснемся следующих вопросов:

  • Следует ли регистрироваться ИП или ООО для ведения бизнеса и как это сделать
  • Куда поступают деньги принятые на сайте в качестве оплаты, как их вывести
  • Нужна ли онлайн-касса, как ее приобрести и использовать
  • Взаимоотношения с налоговой, отчисления в пенсионный фонд

Итак, если вам интересна данная тема, то будем ждать вас на нашем youtube-канале, в воскресенье 1-го декабря 2019 года в 18.00 по мск.

Также приглашаю поделиться своим опытом, тех, кто уже ведет свою деятельность!

Жду ваши предложения по данной теме в комментариях ниже, а также вопросы, на которые я постараюсь ответить во время проведения трансляции.

Стрим закончился, спасибо всем!

Смотрим в записи:

Итоги за октябрь

Всем привет.

К сожалению, от проведения ежемесячного стрима мне пришлось отказаться из-за продолжающейся уже неделю болезни, поэтому тут кратко пробегусь по итогам за прошедший октябрь.

В нашем каталоге за октябрь было опубликовано семь самых различных дополнений, как платных так и бесплатных.

В октябре у нас только один участник конкурса "Дарим деньги за Бесплатно", проводимый среди разработчиков бесплатных дополнений к плагину WP-Recall. Пользователь garry (Игорь) опубликовал бесплатное дополнение Yworld RSY and AMP, в связи с чем он и становиться победителем октябрьского этапа конкурса и получает на свой баланс призовой фонд в размере 1400 рублей, собранный с помощью нескольких замечательных спонсоров в соответствующем проекте.

Спонсоров, участвующих в указанном проекте набралось тоже не так много, всего двое, поэтому я решил не проводить среди них розыгрыш VIP-доступа, а начислить каждому из них по три месяца VIP-доступа. Спасибо им большое за участие.

Пока я решил приостановить проведение конкурса "Дарим деньги за Бесплатно", к сожалению, нам не удалось привлечь достаточное внимание среди разработчиков к этому конкурсу, но я надеюсь, что за время его проведения нам удалось должным образом отблагодарить рублем тех, кто все же решил в нем поучаствовать.

Поставим конкурс пока на паузу, пусть разработчики поднакопят жирок идей для реализации в виде бесплатных дополнений в будущем.

Буду рад ответить на возникшие вопросы в комментариях.

Всем добра!

 

Итоги за сентябрь. Стрим.

Всем привет!

Сегодня состоялась запланированная трансляция на нашем youtube-канале.
Подвели итоги сразу нескольких конкурсов заявленных в сентябре, а также обсудили несколько интересных вопросов.

Кто не успел к нам присоединиться можете просмотреть все в записи:

Благодарим всех кто поприсутствовал на нашей трансляции. Поздравляем победителей прошедших конкурсов!

Друзья! Не забываем участвовать в нашем ежемесячном конкурсе "Дарим деньги за Бесплатно", благодаря нему в нашем каталоге появляются новые интересные бесплатные решения для плагина WP-Recall. Поддержите разработчиков, сделав посильный взнос на странице проекта https://codeseller.ru/project/pooshhrenie-pobeditelyu-v-konkurse-darim-dengi-za-besplatno-oktyabr/

Имеем ввиду, что среди спонсоров этого конкурса 1-го ноября будет разыгран VIP-доступ на 3 месяца, старайтесь не упускать эту возможность!

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

Всем добра.

Приглашаем на стрим 1-го октября!

Приветствую, друзья!

До конца сентября осталось совсем немного, а значит на нашем youtube-канале очень скоро пройдет очередной стрим.

Приглашаем вас посетить нашу трансляцию 1-го октября в 18.00 по мск.

Подведем итоги проводимых конкурсов, ответим на ваши вопросы.

Переходите в назначенное время на страницу нашего канала, а далее просто присоединитесь к проводимой трансляции.

Обязательно будем ждать Вас и будем рады если Вы поприсутствуете на мероприятии.

Присоединяйтесь к нашему каналу на Discord для живого общения по ссылке https://discord.gg/ZcmCYFY

Напоминаем, что Вы также можете повлиять на запланированный ход проведения обсуждения внеся свои предложения в комментариях ниже. Задавайте вопросы, в том числе, неудобные тут или прямо во время проведения стрима, сделайте его интересным для себя.

Авторизация
*
*
Генерация пароля