Deploy на shared-хостинг, как с этим жить

Ладно, сорри, пацаны, захотелось чуток срачехоливара. Всем пис. :)

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

Зачем изобретать велосипед и писать вручную код для работы с какой-то очередной сущностью?

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

WooCommerce, например, для продуктов создает отдельный тип записей, для рубрик и меток товаров - таксономию, а атрибуты хранит с использованием Metadata API и все тех же таксономий. Плагин ACF также создает свой тип записей для групп и для отдельных полей. Работа со значениями полей производится через все тот же Metadata API. Чтобы это все работало быстро, в плагине реализовано кеширование с использованием все того же API WordPress. Стандартные функции также используются для работы с изображениями, редактором, для загрузки файлов и многих других вещей. Yoast SEO, например, активно использует Metadata API для хранения метаданных.

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

Баннерокрутилка.

Плагин автогенерации метаполей и наименований для перелинковки (прописываем у каждого товара несколько блоков "похожие", "рекомендуемые" и т.п., с РАЗНЫМИ названиями для улучшения внутреннего ссылочного, но писать эти разные тексты руками не хотим, а хотим чтобы если оно заполнено, то выводилось из базы, а если нет, то выводилось по алгоритму, а список алгоритмов настраивается).

Биллинг - счета, оплаты. Да даже корзина.

Тикет-система.

Хранение писем из фидбека в базе а не только отправка на почту.

График занятий для учебной группы с календариком (дни, занятия, преподаватели, группы, номера "уроков" и время их начала).

Шаблоны для почтовых рассылок и т.п.

Это так. Навскидку.

Всё это подразумевает ту или иную CRUD-админку.

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

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

---------- Добавлено 20.07.2016 в 17:21 ----------

TiA, глянул Вашу подпись.... Опенкарт.

Скажите еще что Опенкарт нормальный движок в котором всё есть)

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

Самое очевидное решение - это создать новый тип записи "Баннер" с поддержкой миниатюры и описания. Можно также с помощью ACF PRO создать страницу настроек и туда вынести настройки баннеров, включая загрузку картинок, сортировку и указание дополнительной информации. Создание доп. полей производится через админку и не требует копания в коде. Остается только организовать вывод баннеров в нужном месте темы оформления.

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

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

Если записи нового типа не должны выводиться на фронтенде, то это можно явно указать при регистрации типа. За это отвечает параметр public функции register_post_type. Указываете его равным false и все, не нужно городить костыли с фиктивными шаблонами, правами и прочей ересью.

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

WordPress постоянно меняется и при этом умудряется не ломать совместимость. API там более чем стабильно. Это большой плюс.

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

TiA, mendel, я уже не раз писал, что главная беда Вордпреса как раз в его плюсах

Простой и понятный движок для того чтоб начать. Но на нем стали пытаться делать все! И начали выползать проблемы. А это изначально была блогплатформа.

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

Но не все задачи ему под силу. Сегодня делал опять же форму обратного звонка на Джанге - земля и небо. Потратил в 3 раза меньше времени, при том что Питон знаю гораздо хуже чем пхп.

За фреймворками будущее)

Сделать можно всё. Вопрос в количестве кода.

Сделайте функционал ОпенКарта (про него вы кстати не ответили) на вордпрессе, и у вас получится.... опенкарт)

Вообще в некотором смысле вы правы. Для блогов ВП хорош. Особенно если использовать проверенные темы и плагины.

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

Но уже на простеньком "портале" с полсотни сущностей (такосономий и записей по вашему), да с поддержкой этого всего годами - всё будет уже не очень весело.

Портянки копипасты, портянки костылей, лабиринты процедурной каши...

Сделать можно много чего. Даже VQMOD придумать. Но вот зачем?

ПС: а вообще занятно. Если всё можно сделать, то чем же оно хуже?) В голове пролетают кучи вариантов, но понимаю что лет пять назад я бы их не воспринял.

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

Мир жесток и несправедлив)))

---------- Добавлено 20.07.2016 в 19:13 ----------

Ну я как раз сейчас и пилю свой фреймворк с куртизанками и покемонами.

Так что мне это доказывать не нужно.

Хочу совместить простоту вордпресса и возможность программировать без программирования с нормальными подходами.

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

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

Т.е. простота вордпресса и функциональность полноценного фреймворка.

Черт, вот как жить без миграций?

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

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

Неужели у вас нет собственных наработок по формам обратной связи? Если нет, то можно тот же Contact Form 7 развернуть. Многие заказчики знакомы с этим дополнением и им не приходится меня дергать, если вдруг что-то в форме нужно поменять.

В этом нет смысла. На WordPress есть чудесный плагин WooCommerce, который по многим аспектам реализован удачнее OpenCart. Около 39% всех магазинов в мире используют именно это дополнение.

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

У меня

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

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

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

Из стоящих альтернатив для WP есть CMB2, но там нельзя настроить поля через админку, приходится лезть в документацию. Есть также и Pods, но там возможностей меньше.

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

ВП это движок для блогов, ну максимум сайт-визитка с несколькими разделами статей да блогом новостей компании. Всё. Дальше уже говнокод идет.

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

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

Вы понимаете что VQMOD это бред, но не видите что использование сущности записи под всё это говнокод. Ну да это вопрос опыта. Когда есть с чем сравнивать, то понимаешь разницу. А когда опыта не хватает, то можно и не по делу использовать инструмент.

У меня есть нечто подобное)

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

Но пока движок сыроват, выкатывать на паблик рано, да и есть вещи которые важнее по функционалу а не по красоте...

А зачем вы костылями пользуетесь? По WordPress есть много отличной документации с best practices. Если во время разработки им следовать, то поддержка проекта кардинально упростится.

Да, действительно, изначально WordPress создавался как платформа для блогов, но в последние годы разработчики планомерно делают ее все более и более универсальной. Из самого последнего в данном направлении - это постепенное внедрение REST API на уровне ядра.

Вы сравниваете разные вещи. Основным недостатком VQMOD/OCMOD является то, что они правят исходный код системы, что создает огромные проблемы при поддержке. Грубо говоря, если Даниель опять захочет что-то поменять, вынести модули в папку extensions или перевести весь код на Twig (это не шутка), то вся совместимость ломается. Хуже всего, что она может сломаться по-тихому и потом очень сложно найти что именно поломалось. Именно это является основной проблемой.

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

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

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

В Yii2, например, для создания новой сущности требуется сначала создать модель, контроллер и представление, прописать нужные правила для валидации значений, написать код для CRUD, каким-то образом организовать дополнительные поля с помощью отдельной сущности и протестировать это все счастье. Да, Gii этот процесс несколько упрощает, но все равно на это все придется потратить гораздо больше времени. Переносить этот код из проекта в проект также сложнее.

Да, мне очень нравится работать с фреймворком Yii (1 и 2 версии), для многих задач он действительно незаменим, но для большинства стандартных проектов я предпочитаю использовать WordPress. Причина до жути проста: эта система позволяет получить требуемый результат гораздо быстрее и при этом ее поддержка не требует большого количества моего времени.

Если функционалом неудобно пользоваться, то им пользоваться не будут. Вообще создание качественного продукта требует огромного количества времени и сил. На написание чего-то сравнимого с ACF может легко уйти полгода-год. Вот, например, команда из 8 человек уже два года пилит на Yii2 систему DotPlant2. В своем нынешнем виде она все еще сырая.