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

Смотрите.

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

Вынесено в отдельный конфиг именно по тем причинам что вам не нравится в юии:

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

Еще отличия от Юии - правила распространяются далеко не только на валидацию.

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

Ну и конечно правила для сохранения, правила после чтения (что покрывает 90% всех кейсов бефорСаве и АфтерЛоад и прочих) и другие правила.

Опять таки - таблица у меня тут тоже одна, равно как и только один класс модельки для страниц (да и то сейчас можно было бы все фичи перенести в правила).

Контроллер пока да, создается, но только на фронте. В админке это уже просто запись в конфиге такого вида.

Здесь мы указываем по сути только по каким полям возможна сортировка да какие поля в какую вкладку засовывать.

Список полей с их типами по которым уместен поиск, как вы наверное заметили - в сценарии поиск, в конфиге моделек.

Ну конечно тут еще конфиги с языковыми строками идут, но это думаю очевидно.

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

Ну для фронта конечно контроллеры и шаблоны нужны. Иногда и вьювы (я разделяю логику вьюва от шаблона, но в большинстве случаев отрабатывают стандартные вьювы, без лишнего кода). Но контроллеры для стандартных видов страниц стандартны, и в будущих версиях тоже будут существовать лишь в конфиге, как и в админке. А вьювы? Ну красота то нам в любом случае нужна.

Но согласитесь, что сделать в шаблоне товара что-то вроде

это не сложнее чем в ВП писать (да и кстати как вы в шаблоне выведете логотип производителя товара? Плясками?

Сейчас у меня ключевые задачи это:

1 - отделение админки от фронта

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

3 - унификация контроллеров с выносом их настроек в отдельный конфиг, здесь же убрать костыли из роутинга (аналоги урлКонтроллера)

4 - сделать наследование свойств в конфигах. К примеру в конфиге модели явно видно, что большинство свойств у страниц общие, и их нужно указать один раз у модели page а дальше только отличия указывать, а в коде уже мержить массивы.

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

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

Учитывая что я занимаюсь этим сам, в свободное от живых заказов время, то доберусь не раньше осени.

---------- Добавлено 21.07.2016 в 16:05 ----------

ПС: кстати вот прямо сейчас сажусь гвонокодить в том стиле за который Вы тут ратуете) Буду использовать в последнем моем магазине на опенкарте модуль ХТМЛ-содержимого не по назначению)

Для термина таксономии "Производители" просто добавляется еще одно дополнительное поле с картинкой. В случае с ACF делается это через админку без правки конфигов. Само изображение можно вывести в шаблоне через функцию get_field в нужном размере и с нужными метаданными.

В OpenCart можно относительно быстро написать свой модуль и не городить лишний раз костыли. Вам же потом это все поддерживать.

Ну и наоффтопили! Где обсуждения Capistrano, Chef, Puppet, Ansible, Vlad the Deployer, Rex, Rocketeer, Phing вот этого вот всего?

Ну вы код приведите)

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

У меня одна строчка в конфиге, у вордпресса одна строчка в конфиге, разницы нет.

Вы код для вывода картинки приведите. Который в шаблоне товара будет.

Он конечно не намного страшнее будет, но вот к примеру другой вариант:

У постов есть комментарии и категории где эти посты расположены.

У категорий есть "владелец", т.е. пользователь ответственный за этот раздел.

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

У меня это будет что-то вроде

<?=$comment->post->category->owner->avatar;?>

Для ВП это почти непосильная задача.

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

Нашли мы пост, потом по его ид находим категорию, потом по ней владельца, и уже у владельца аватару, которую засовываем в генерацию картинки?

---------- Добавлено 21.07.2016 в 23:37 ----------

Кто все эти люди?)))

А если серьезно, то беглый гуглеж:

Capistrano - руби, нет винды

Chef - явный оффтоп. И руби, "и вообще"

Puppet - руби, да и причем тут шаредхостинг вообще? Нет, ну вот каким боком?

Ansible - питон. Почему не руби?!!!!!один. (опять таки, ну причем тут деплой на шаред?)

Vlad the Deployer - ну наконецто! А то подсовывают нам питон какой-то....

Rex - Перл??!один Что за перл такой? А где руби?

Rocketeer - php? правда чтоль?))

Phing - еще php? Где вы видели пхп на шаред хостинге! Верните руби!!!один1

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

<?php if ($field = get_field('image', 'vendor_' . $vendor_id)) { ?>
	<img src="<?php echo $field['sizes']['product']; ?>" alt="<?php echo $field['alt']; ?>" />
<?php } ?>

В примере product - это зарегистрированный ранее размер картинки, который требуется выводить на сайте, vendor - таксономия с производителями. Если сменить тип поля с картинки на галерею и поместить вывод в цикл, то для производителя можно указывать сколько угодно изображений.

Отдельно один комментарий можно вывести с помощью функции get_comment. Если дополнительное поле с аватаркой связать с пользователем, то оно будет выводиться абсолютно так же как показано выше с той лишь разницей, что вместо vendor будет user с соответствующим ID (свойство user_id возвращаемого объекта с комментарием).

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

Странно, что о WP-CLI никто не вспомнил. Если учесть специфику работы автора, то этот инструмент был бы очень кстати.

Это только половина кода, ведь $vendor_id еще получить надо.

Итого 5-6 строчек нечитабельного кода вместо одной строчки.

И на выходе специфичный код зависимый от плагинчика и в принципе не поддерживаемый самим вордпрессом, т.е. пишем на ACF а не на вордпрессе.

Не в тему. Функция то есть. А вот механизма вывода нету. Куда ее вставлять?

Как создать страницу где оно будет выводиться? Как генерить на нее ссылку? Как при желании изменить формат ссылок их менять? Мне нужно сделать вот так. Как это сделать в вп?)

Именно!

Только вот получение этого ИД, как и в прошлом примере вы "забыли". А оно будет строк на 15, если вы удосужитесь прочитать задачу, а не ограничитесь своими предположениями. Юзер не у комментария а у категории.

---------- Добавлено 22.07.2016 в 01:50 ----------

А с Вами чертовски полезно флудить)

Понял что даже для верстальщика нужно вводить стандарты кодирования.

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

Присвоение в условии опять же.

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

$queried_object = get_queried_object();

В свойстве term_id находится ID текущего термина ($vendor_id). Да, в 15 строк у меня не получилось вложиться.

Этот плагин хорошо поддерживается разработчиками, в число которых я вхожу. На данный момент разработкой ACF 5 PRO на GitHub занимается 32 человека, включая переводчиков и QA.

PSR-1 позволяет использовать как полный, так и сокращенный синтаксис, стандарт оформления кода WordPress разрешает только полные PHP теги.

mendel, я тут диагонально почитал что ты пишешь... По поводу ВП ты сильно отстал от реальности.

ВП давно уже не только не блоговый двиг, и даже не CMS в классическом понимании. Он уже CMF (мож пока не на 100%, но уверенно к этому движется). В нём и кастномные типы контента и таксономии давно существую. И вот уже и REST API внедряется.

Но при всём при этом сохраняется совместимость со старыми версиями. Не говоря уже за отличные АПИ и маны.

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

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

И да. "Каждый кодер должен написать свой движок, что бы в конце-концов прийти к ВП" (с) не моё ;)

это все еще половина от половины) Я не вижу здесь $vendor_id.

Просто вы ведь не под вордпрессом пишете а под ACF а изучать ненужный мне "фреймворк" чтобы написать пример за вас, это уж слишком)

Ну да, если я правильно помню тут выйдет 10 строк а не 15.

Запрос комментария

получение ид поста

запрос поста

получение ид категории

запрос категории

получение ид оунера

получение оунера

получение

и

вывод аватарки.

Ну и плюс еще пару строк "главного цикла".

Но все зависит от того как вы сделаете вывод комментария отдельно. Тут или куча кода, или опять говнокодить на "записях".

А мой фреймворк хорошо поддерживается мною, и я даже писал раньше под вордпресс. Но какое это имеет отношение к вордпресс?

Если бы ACF был бы частью вордпресс или хоть написан компанией вордпресс, то да, можно было бы его к вордпрессу относить, но при чем тут какой-то сторонний плагин?)

Вы пишете на ACF который требует для себя вордпресс.

Вы используете синтаксис ACF а не вордпресса.

Да, вы так сокращаете почти в два раза код который в других местах не пришлось бы писать, но разве это защищает вордпресс как фреймворк?

Серьезно?)

То-то я смотрю в ВП везде пишут

Если же вы про <?= и т.п. то все равно не совсем верно. PSR запрещает <? а разрешает только <?= и этому есть внятное объяснение. Я спорил с участниками PSR и меня убедили почему это можно, а это нельзя)

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

Быстро наговнокодить можно что угодно. Но зачем?

Говнокода тут два:

1 - если пишешь на Опенкарт то это говнокод по определению.

2 - я не стал копипастить админку модуля html а прямо использую его данные для подстановки в текст по хештегам (аналог вордпресовского [названиеБлока] в тексте статьи). Это не столько лень, сколько разумный выбор - один и тот-же текст может использоваться и как блок в дизайне, и как текст в описаниях/статьях и т.п. На эту мысль вы же меня и натолкнули, используя записи там где надо и не надо...

ПС: так я что-то не услышал как же вы собираетесь выводить комментарий отдельно?)

---------- Добавлено 22.07.2016 в 11:58 ----------

Нее. Это уже было. Правда пришел не к ВП а к юии.

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

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

Я не против таксономии как термина. Сам использую его при формировании ТЗ или в разговорах с коллегами. Просто в коде у меня нет необходимости в таком понятии. Есть модели и их связи. Весь код, что у "записей" что у таксономий одинаков. Я его использую осторожно в контексте вордпресса просто потому что опасаюсь, что я уже могу вкладывать в него чуть другой смысл.

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

Я видел даже что в вордпрессе некоторые городят плагины для псевдоMVC))

Но суть то от этого не меняется.

Ну это его основное преимущество.

Зазубри кукбук и поехали.

Чисто за счет кухарок он и оброс кучей плагинов и тем.

Чисто за счет кухарок его админка известна всем.

Почему винда обогнала линукс? Именно поэтому.

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

Именно благодаря домохозяйкам.

очередное подтверждение, что ты отстал в ВП лет на 10 :) (и вообще домохозяйки бы сильно удивились этому слову :) )

Сорри, "кукбук" прочитал как "кубрик" (первые темы ВП).

Ну это просто эпикфейл. :)

Не, фейс (и да, отличный фейс) и простота понимания (юзабилити) конечно сыграли роль в популярности винды. Но вот только в 198x-199x не то, что линуха не было, но были конкуренты, у которых, собсно этот фейс во многом и был стянут. Причина же популярности несколько в другом.

А если ты имеешь ввиду не линукс, а юникс, так он изначально затачивался не для хоумюзеров. И в своей нише (серверов) он был лидером.