25 ноября 2017 в 3:30
Drupal 8 для многих задач избыточен. Разработка на нем требует бОльших трудозатрат для хомяков. Т.е. не-матерых ИТ специалистов и тех кто не готов содержать команду (обращаться к команде). Теперь конкретика: чего не хватает.
1. Feeds. Под 7-ку feeds был глючным, но рабочим с первого года 7-ки. Сейчас для импорта нужно ПИСАТЬ КОД. Кто-то кричит Stop Waiting for Feeds https://ohthehugemanatee.org/blog/2017/06/07/stop-waiting-for-feeds-modu...
кто-то пилит модули работающие только в комплекте с разработчиком contentimport
А воз и ныне там.
2. node_export. Отсутствует. Даже мейнтенер модуля экспорта https://www.drupal.org/node/2385179 заявляет “Drupal 8 is not Drupal ”. В 7-ке далеко не все можно экспортировать через views. Нельзя метатеги и текстовые области с html-разметкой. Справедливости ради и в D7 node_export через VBO "путает" мататеги.
3. views_fieldsets. Этот вроде разрабатывают. Пока работает глюковато. Пожелаем разрабтчикам удачи. Конечно можно ПИСАТЬ КОД переписывая поля views и задавая шаблоны вьюх.
4. context. Пока не дошел до уровня 7-ки. Видимость блоков в зависимости «от ситуации» в D8 частично решается путем создания копий этих самых блоков. Для того чтобы добавить html на станицу нужно ПИСАТЬ КОД.
5. breakpoints. Оно типа в ядре. А как подружить его с context я не пока не нашел.
6. views тоже в ядре. По мне темизировать views стало сложнее. Не помню для чего пришлось хакать.
core\modules\views\src\Element\View.php
и
core\modules\views\src\Tests\ViewElementTest.php
С обновлением Drupal надобность в одном из хаков отпала.
7. regionclass. Под 8-ку нет. И под 7-ку работал глюкаво. Задать классы региону — надо ПИСАТЬ КОД.
8. webform_calculator. 21 век! И для того чтобы сделать обычный калькулятор нужно ПИСАТЬ КОД!!!
Отдельно от модулей хотелось бы отметит сколько 8ка жрет ресурсов, но тестовые замеры я не проводил. Интернет витрина без возможности заказа имеет БД на 500 МБ что уже много.
Пока все. Будет ли список дополнятся или зачеркивать — будем посмотреть. Taxonomy_menu и menu_link_attributes вроде довели до ума.
Комментарии
Вот х.з. Для верстки в восьмерке практически неограниченные возможности, просто не надо воспринимать друпал с позиции только кнопочек. Он всего лишь создает таблицы в бд и помогает заполнить их через свой интерфейс и организовывать выборку из бд, отдать ее браузеру. Можешь вообще поставить минималку и написать своё на то, что нужно. Избаловался ты.)
Изучи поглубже сам twig он многое умеет.
Верстка с позиции кнопочек - до этого пока Drupal не дошел. Шо ж верстаки будут делать, когда этот день наступит
От того, что я поставлю "минималку" БД будет меньше на 10 МБ
Я не против twig. Но надо ПИСАТЬ КОД. Основную мысль поста улавливаете?
Кстати, дошел: https://www.drupal.org/project/mbase
taxonomy_menu лучше не использовать вообще, он подвесит Вам систему уже в D7 при мало мальском словаре.
Много об этом слышал, но пока не наблюдал. На маленьком сайте нормально выводятся категории. На большом надо сложнее чем taxonomy menu
Лучше сразу использовать турбо https://drupal.org/project/taxonomy_menu_block
Зато "внутри" он бесподобен-))
Наверное на данный момент он более Framework чем CMS.
Но современем "подтянут" до CMS, вспомните какие "возможности" были на шестерке и на тогда еще новой семерке-)
В 6-ке мне не хватало возможностей добавлять поля к пользователю и термину. Через модули это было криво. 7-ка эти возможности предоставила. Что там внутри волнует меньше.
Спасибо, поржал.
При старте проекта, если в команде есть голос против, все прислушиваются. Поэтому Семёрка... Мне смешно, но всегда кто то против, и доводы убедительные. Мотив? Да деньги конечно, тут всё просто.
По поводу команды и обидного слова хомячки - это слово я и запустил здесь. Поэтому безразлично. И хомячки даже после сдачи проекта не просят админку, предпочитая отслюнивать за работу контент-менеджера, им что Четвёрка, что Девятка, даже вопросов таких не возникает. Запилю на Джумле - не пикнут ))
Деньги? Серьезно?
Я подчитал время, которое я потратил на одном из маленьких проектов, создавая и обновляя фичи. Это было около 25-30% времени на каждую из задач, которые я делал
В Д8 этой проблемы нет вообще. Конфиги идеально применяются, экспортируются и пр. Кастомного кода меньше во много раз из-за возможности наследоваться, а значит и меньше багов.
Если одинаково хорошо знаешь апи 7 и 8, то на 8 разрабатывать быстрее.
За какой-то год своих фич для d8 накопилось больше чем лет за 7 на 7ке. ) Потому что очень просто и легко делать и вычленять частные решения для общего пользования. Очень экономит время. На d7 так было нельзя) ну или очень дорого по времени
С этой точки зрения D8, конечно лучше.
Но в большом количестве случаев, ещё лучше будет взять просто, хоть ту же Symphony, и избавиться от лишней универсальности в пользу простоты, надёжности и производительности специализированного решения. Точно также, при этом появится код, который будет переиспользоваться от проекта к проекту. А в целом кодовая база каждого проекта будет куда меньше, проще, и в итоге надёжнее.
Пробовали. Году так в 2013. Через месяцев 8-10 выходило что symfony-проекты поддерживать стоит раза в 3 дороже. Это если мы говорим о маленьких проектах до 50-80 часов. Может сейчас что поменялось, но сжигать столько денег сколько сожгли тогда как-то не хочется.
За счёт чего была такая разница в стоимости поддержки?
Какова была разница в стоимости/сроках разработки?
Пробовали-ли какой-нибудь yii, laravel, или какие-то другие фреймворки?
laravel не уверен что тогда был, yii не было разработчиков под рукой.
Разница была из-за необходимости привлекать на задачи саппорта, с которыми ранее справлялись просто обученные девушки с первой линии саппорта, полновесных разработчиков. В итоге оказалось проще все проекты перетащить назад на дру, бесплатно для клиента, чем платить за это развлечение дальше из своего кармана.
Laravel был, но ещё не было вокруг него такого хайпа. А Yii, был уже 1.1.х даже. И тогда это был очень неплохой выбор, кстати. Кстати, и symphony была совсем не той, что сейчас - 2.0 только вышла вроде?
По поводу поддержки: А в чём именно была разница? Какие проблемы решались, в том, и другом случае? Может просто была проблема с квалификацией архитектора? Как сейчас на Drupal 8, те же проблемы не вылезают?
Классы в менюшке проставить чтобы верстальщику задачку сделать. Покажите мне как это решить с себестоимостью 10-30руб. в мире симфони) Там разработчику нужно минут 15-30. С учетом разницы ставок - получалось 30руб vs 300-400руб.
Теперь представьте что таких задач в день может быть - 60-80. В мире где "поток и много саппорта" другие критерии выбора. От задач все зависит. Я гарантирую что в нашем наборе кейсов фремворки сильно дороже. В другом наборе кейсов - бывает и лучше и дешевле.
Так та же шаблонизация, и квалификация требуется ровно та же, что и в Drupal поправить тему. Т.е. должно же быть какое-то разделение обязанностей. И такая проблема не будет возникать. И должны быть приняты архитектурные решения, чтобы это было технически возможно.
Я понимаю, что от кейсов зависит многое , просто я и хочу понять, в чём именно разница в ваших...
Ну и делать это, на том же Drupal, мне бы не приснилось и в страшном сне - работы было бы куда больше.
Я, вероятно, действительно решал на основе фреймворков, совсем другого класса задачи, например специализированную хостинговую панель, или систему конвертации/каталогизации видео файлов. И конечно у моих клиентов идеи поменять класс в шаблоне не возникало.
Ок, теперь представь что у тебя тысячи простеньких визиток и небольших магазинов где надо кнопочку поправить, менюшку поменять, счетчик поставить и т.п.)
Про другого класса задачи - согласен, другие инструменты. Про видео или хостинг-панельки там вообще много вопросов, нужен ли php, ближе к go/python.
На самом деле, большая часть "под капотом", там была не на PHP, и не в контексте веб сервера, вообще. Но для мордочки, которая складывает задачи в очередь, PHP вполне не плохой выбор.
Про "тысячи визиток и небольших магазинов": шаблонизация, общий подход к проектированию однотипных решений, нормальная внутренняя документация, и так работает не мало студий, на самом деле. Заодно небольшой большой бонус: vender-lock, клиент не уйдёт так просто. Т.е. и в ваших кейсах бывают разные подходы.
бывают) мы вроде как парсим всех конкурентов всех "наших кейсов") но это уже не тема форумного обсуждения)
"Классы в менюшке проставить" - для этого на D8 переходить зачем?
Вообще, сравнение было между кастомным проектом на Symphony и Drupal 7, ещё вероятно, так на всякий.
А зафигачить это все в фичу и разворачивать сотнями и прогонять тесты через drush?)
upd, ну да, все верно, речь была про d7, а с d8 с фичами стало проще..
Можно подробнее? Вы же сейчас на восьмерке работаете. Или о чем речь?
Да, ещё есть проблемы в виде не портированных модулей, но, вашу машу, помогайте портировать их. коммитьте на д.орг, создавайте новые модуля, фиксите баги в старых или хотя бы создавайте ишью, чтобы была инфа о том, что что-то не пашет. Друпал это не коммерческий продукт, мы всем комьюнити его пилим.
Я понимаю что хочется всё хорошо, быстро и бесплатно, но так не бывает, увы
Топикстартеру:
Да, пиши код. Потом выкладывай его на друпал.орг, чтобы следующий такой хомяк не создал бесполезную тему на друпал.ру, чтобы развести срач и пожаловаться что он такой бедный и несчастный.
А кому вы предлагаете портировать и писать код? Пользователю, который хочет запилить себе сайтик? Rly?
Drupal сделал огромный шаг в сторону серьёзных разработчиков, но он же был в сторону от простых пользователей CMS, и от среднего PHP разработчика, заодно.
Причём, на мой взгляд, это было большой ошибкой - у серьёзных разработчиков уже есть отличные фреймворки, без излишеств и переусложнённой структуры хранения данных...
В итоге Drupal, и так не слишком-то популярный, после 7 потеряет много пользователей, и много разработчиков, и это отлично заметно по тому, что творится с модулями.
Полностью согласен с Борисом
Нормальный топик, я бы даже сказал - нужный..
Эдакая "обратная связь" от пользователей-"сборщиков" к разработчикам.
ТС, продолжайте - дело нужное.
Голосовалку, что-ли, какую замутите, чтобы "хомячки" могли четче обозначить, что на данный момент наиболее востребовано.
Глядишь кто и возьмется помочь бедным "хомячкам"-))
Повторюсь. Начиная с 12 года я видел баталии шестёрочников с семёрочниками, шестёрочники говорили что всё налажено и бабло идёт. Семёрочники говорили то что сейчас восьмёрочники. И тогда я принял сторону семёрочников, и не пожалел в будущем, хотя она и сыровата была.
Сравнивал шестёрку с газ-21 а семёрку с 31029, ну это по стариковски.
Хотя есть на памяти проекты на шестёрке, где гений разработки обошёл семёрку во всём, поэтому очень-очень всё спорно.
Мне жаль тех людей, которые отдали друпалу по 10 лет жизни и до сих пор считают себя хомяками.
Можно купить в "Детском Мире" модель самолёта/корабля, склеить детальки, поставить на полку и будет красиво. Можно так же собрать модель самолёта/корабля, которая будет самостоятельно летать/плавать, но для этого нужно знать как минимум физику + какие-то профильные материалы, выйти во двор/речку и продемонстрировать свой скилл.
Можно собрать настоящий корабль/самолёт, но для этого нужно знать ещё больше.
Пока данный топик напоминает: "Я могу клеить детальки, но хочу делать настоящие"
Если человек сказал о себе, что он мастер, это уже не мастер.
МАСТЕР постоянно совершенствуется, в различных сферах, не в узкой литографии или барельефах, это талант, гений ))
Да-да, я именно это имел в виду))
По тому, что говорит о себе человек, можно судить только о его ЧСВ, которое вообще никак не связано с мастерством.
Есть и скромные профи, и те что "знают себе цену". Точно также, как и профаны, есть как вполне осознающие свои ограничения, так и уверенные в том, что они просто первые в профессии...
Очень редко в АйТи можно встретить скромных) В основном все "мега профессионалы"
Они, просто, не так заметны.
Ой, а типа я не скромный)) Я по меркам одной из известных контор полгода назад чуть-чуть не дотягивал до мидла, сейчас правда может уже дотянул бы) И я никогда не скрывал этого.
Конечно нет - тебя очень даже заметно! =р
Помниться в ВУЗе, на самой первой лекции по AЯ и П (Алгоритмические языки и
программирование) самыми первыми словами лектора были:
Программирование без ошибок есть теоретическая абстракция.
Каждый программист считает себя - лучшим.
А ведь не сoврал, уважаемый.
Самую суть профессии ухватил-))
...
Опсс.. предмет назывался (АЯ и П) - без пробелов, но суровая цензура говорит что это мат-))
Чаще всего это из-за непонимания объёма самой профессии. Данный топик тому пример. Можешь накликать в админке - всё, уже спец. И главная проблема - "НУЖНО ПИСАТЬ КОД". На минуточку, вся деятельность в данной сфере сводится к тому, что нужно писать код. Это всё равно, что работать врачём и возмущаться - "Блин ну это ж НУЖНО ЛЕЧИТЬ ЛЮДЕЙ". В итоге всё равно приходим к тому, что НУЖНО ПИСАТЬ КОД, чтоб писать код, нужны знания ЯП, чтобы понимать, что писать - нужно понимание различных алгоритмов, паттернов, архитектур данных, протоколов... И в итоге у нас бескрайняя степь неизвестности. Прибавляем к этому колосальную скорость развития отрасли и в нагрузку получаем ещё и следование современным трендам. В итоге получаем кучу комнатных специалистов, которые знают как включать комп и печатать одним пальцем
А можно поинтересоваться? Зачем тогда цмс, если нужно пилить код? Кстати, наверное, многие прогеры будут ржать,что пользователи друпал рассуждают о коде))) Если можешь хорошо кодить, данный набор фэйлов тебе будет только мешать. Это не в вашу сторону, вы же сам не пользуетесь этой цмс.
Главное, не умение писать говн@код, и не тупо тыркать ЛКМ в админке, главное понимание важности, целенаправленности и полезности своих действий. Если вы понимаете пользу, как возможность купить алкоголь, то вы заведомо аутсайдер.
Мы как раз начали когда вышел первый в мире симфони lts - 2.3 или 2.4 .
С d8 есть конечно проблемы, особенно вначале - мы начали на нем делать уже с 8.0, уже забыл когда он там вышел, года 2 прошло почти? Но более-менее....
По поводу поддержки. Я не знаю как сейчас, но тогда для каждого симфони-проекта получалась РАЗНАЯ админка. под конкретные задачи конкретного проекта. Это конечно офигенно, но нельзя взять вообще ничего не знающего о проекте контент-менеджера и дать мелкие правки. а с друпалом - везде одна админка и можно.
делать унифицированный аналог symfony cms мы не могли - это надо быть большой крутой студией, да и эпоха "все делаем свои cms" к тому моменту уже прошла)
p.s. странно. когда наживал "ответить" - он ответы в ветку комментов писал, а как цитировать - закинул вниз.
Определение "хомячков" ТС таки не дал. Кого он такими считает? С чем их едят? И что вообще с ними делать?
Очень обобщенно: Те, кто не задумывается об АПИ и структуре БД.
Я походу вообще не шарю в теме, мне 8-ка нравится. А так же modx, yii, instantcms, и т.д. Самое главное, что она работает быстро и сервак грузит меньше чем 7, но это мой опыт.
Кстати, рядовому пользователю сделать сайт на 8-ке проще, по моему мнению. К комментам выше.
Пожалуй стоит начать с того, что cms это прежде всего конструктор, из которого можно собрать какие-нить тривиальные вещи, скажем так - стандартные архетипы сайтов. При чём собрать относительно быстро. CMS, как иструмент практически идеален для всяческих PM, создания прототипов и готовых продуктов, не представляющих основной вектор развития бизнеса. Проще говоря для того бизнеса в котором веб проект нужен только для того, чтобы был.
Что касается непосредственно друпала, то данный инструмент предоставляет возможность продолжать развитие проекта на том же фундаменте без смены инструмента. И вот тут НУЖНО ПИСАТЬ КОД))) Все "хомячки" остаются в первом абзаце и претендовать на последующие как минимум смешно и глупо. Но опять же - это cms, а значит имеет куда большие архитектурные ограничения, чем фреймворк или чистый ЯП.
Так же стоит отметить аспект вовлечённости. Как писал Борис:
Если у человека нет желания расти профессионально и его вполне устраивает тыкать мышкой в админке, то его даже разработчиком сложно назвать - он всего лишь пользователь интерфейса. Но и такие люди нужны, я бы даже сказал необходимы. Именно они избавляют разработчиков от рутины тыкаться в админ интерфейс. Правильное соотношение первых и вторых в команде значительно увеличивает производительность всей команды.
Надеюсь, что объяснил доступно
Да, вполне, даже в гугл не полез.....Вот только не понял аббревиатуры РМ. А вот по поводу разработчиком сложно назвать, я не согласен, программист делает код, дизайнер дизайн и т.д. А слово разработчик слишком общее. Есть вебмастера, чья работа не сводится к написанию кода, это скорее мастеринг, интернет маркетинг, вот для них и создаются цмс, так как простой пользователь интерфейса даже мышкой в админке друпала ничего не накликает, кроме слез. Есть множество самодостаточных профессий и ни одна не имеет преимуществ перед другой. Вот прогеры зачастую не смогут раскрутить сайт, как это сделают маркетологи.Я видел простые html сайты приносящие владельцам сотни тысяч, в то время как существуют супер сайты с идеально чистым кодом,но не приносящие ни копейки.
Выражение разработчик вошло в обиход, чтобы не оскорблять true программистов )) Потому что некоторым из них не нравилось, когда создатели сайтов называли себя программистами . Это было довольно давно, но так и осталось
Project Manager
Да, пожалуй определение разработчика весьма размыто. И я всё время говорил, что каждый должен заниматься своим делом и не тянуть на себя одеяло. Я не умею продавать, поэтому не учу сеошников это делать, возможно не достаточно компетентен в дизайне, хотя имею художественное образование и в целом знаю теорию. (Вчера до 5 утра бухали с дизайнером из яндекса и философствовали об интерфейсах, состояниях и иконках), Но я умею писать хороший код и проектировать архитектуры как отдельных модулей проекта, так и всего в целом. Я отлично понимаю важность каждого подразделения в проекте. Но проблема даже не друпала как такового, а сообщества, это сведение всех подразделений в одного разработчика, который на самом деле может вообще ни к какому подразделению не относиться - Тыкать мышкой особого ума не надо. И получается, что разработчикам-сеошникам нужна "магия", которая сделает их сео-мусор более пользователеориентированным, разработчикам-публицистам нужна "магия", чтобы их сайт был на первой странице гугла, и только, наверно, кодеры понимают, что никакой "магии" не существует, есть только логика приложения. Кодеры могут заблуждаться, что придумать интерфейсы просто или что для продвижения достаточно списка ключевиков в мета страницы и для постраничных списков каноникал.
Вся проблема в том, что подавляющее большинство надеется на "магию", что изначально является ошибкой.
Однако, здорово написал
Миллиарды человеко-часов написания кода. Отсюда надо смотреть на важность Друпал. Каждый из нас, даже дюже умный, песчинка во вселенной.
Кстати, даже чуваков, которые кодят на ассемблере, можно назвать пользователями интерфейса, так как, даже у консоли или терминала есть свой интерфейс.......что тут сказать проблема понятий, философия...попробуй сформулируй мысль.... а может GUI and NO GUI))) И, вообще, ребят цените себя,обыватели даже не знают, что такое домен)))
Тут вспоминается старая история о том, что для мака код программы, выводящей на экран текст, был написан даже не на ассемблере, а на бумажке))) Что в принципе логично.
Паша, порадовал старика, спасибо ))
Вредный ты.. ну вставил на всякий пожарный.. а вдруг кому-нибудь нужно-))
дубль раз
Соглашусь, и что печально - знать не хотят. То есть - все мои запугивания и рассуждения слова на ветер, кто купил, кто продлит, кто выключит им плевать, знай башляют без каких либо вниканий.
1. Возрадуйтесь! ХомЯки!
https://www.drupal.org/project/feeds/releases/8.x-3.x-dev - радости прям полные штаны!
"There is no UI yet to configure the CSV parser, which basically makes this parser unusable"
Кстати а вы хоть понимаете что значит "хомяк" в сленге веба?
не угадали
У меня провайдер Лурку забанил, там доходчиво всё про хомячков.
Почему не угадал? Хомячки - это социальная прослойка (http://www.lurkmore.to/%D0%A5%D0%BE%D0%BC%D1%8F%D1%87%D0%BA%D0%B8), а хомяки - home page (http://lurkmore.to/%D0%A5%D0%BE%D0%BC%D1%8F%D0%BA)
Давай свою версию.
Home, личная страница, "хомяк", ну вроде вы, старичье, должны это знать.
Вот у меня тоже именно такая первая ассоциация.
Ну да, губки домиком, бровки бантиком.
Сразу видно, кто не смотрел Масяню в детстве.
Не для всех тут, Масяня совпала с детством.
Приветульки, хомячки!
))