14 августа 2019 в 20:12
Незнаю можно ли создавать здесь такую тему, модераторы могут посчитать это за флуд. Но все же интересно послушать мнение продвинутых друпальщиков. Свои 5 копеек внесу, ставил D7 и D8, перескакивал с одной на другую, не совру раз 30 за 3 месяца обучения данной cmf. Семерка работает быстрее и не тупит все созданные страницы открывает мигом, в отличии от Восьмерки(это мои "5 копеек"). Сравнивал, сравнивал так и не нашел чем восьмерка превосходит семерку. С композером у меня не очень, с восьмеркой не могу нормально ничего установить все с какими то ошибками warnin-гами и предупреждениями(да, я плохо учил работу композера с drupal8), до этого учил laravel и yii2 там композером все устанавливалось без проблем. Композер и есть преимущество восьмерки??? Чем больше на D8 устанавливал тем и модулей(не нужно говорить зачем много всего устанавливать и т.д, прощупывал модули для всего что мне нравилось, настраивал и смотрел темы т.к я учусь) Восьмерка лагала не по детски, за семеркой такого не замечал.
Хотя и в семерке можно все композером устанавливать и drush есть. Не понимаю тогда.
P.S Уважаемые модераторы не баньте меня если что, просто удалите сообщения и скажите что здесь такие темы создавать нельзя. Очень хочется услышать мнение опытных друпальщиков, не только тех кто сидит на восьмерке.
Столько файлов нужно для того, чтобы структурировать проект, что сильно ускоряет навигацию по коду.
Комментарии
Вот пара тем навскидку, которые удалось найти быстро:
Ознакомьтесь с ними для начала.
Если не хватит - есть еще много таких, стоит поискать. Подобные холливары здесь весьма частые.
Если читать совсем лень - короткая выдержка: Drupal 8 лучше тем, что он "живой", и "за ним будущее". 7ка доживает свой век и все (на самом деле уже давно все, только вилку с розетки не выдернули еще).
Сайты в сети на друпал 6 есть еще. А 7-ка до 2021 года будет поддерживатся.
Основное отличие - в коде. В семёрке всё пишут меленькими буквами с подчёркиваниями, а в восьмёрке подчёркиваний очень мало, зато полно заглавных букв, даже в середине слов. В восьмёрке встречаются двойные двоеточия. В восьмёрке значительно больше тонких стрелок (вот таких ->). В семёрке меньше файлов, но они очень длинные, а в восьмёрке наоборот: много коротких файлов. В восьмёрке есть файлы, где много двойных фигурных скобок, а есть и наоборот - файлы, в которых совсем нет никаких скобок и тэгов - одни только отступы.
Именно поэтому я выбрал восьмёрку.
А ещё семёрка хорошо подходит тем, кто любит спагетти, но совсем не интересуется архитектурой.
На drupal перешел с yii2, на drupal все тоже самое можно сделать в 20 раз быстрее, мне не очень нужна архитектура и опять писать 800 строк кода, архитектуру знаю поверхностно ее и все и пока не понимаю зачем мне туда лезть. Да! я теперь позорный кликальщик, все гениальное просто на drupal можно такие вещи накликать (главное результат). Единственное в какую сторону я сейчас смотрю это в сторону темизации - создание своих тем (так как темы в drupal-e нет красивых, готовых, стабильных тем я в любой укажу на изъян! платные не рассматриваю). Там да свой css и js нужно будет писать. И создавать я свои темы пока только учусь.
P.S Спагетти в соусе с ермолинскими сарделями очень люблю и запивать тоатным соком ням ням ммм.
И ваще, 8 - длиннее!
Есть всякие маргинальные хостинги, где установлена квота на количество файлов.
чето многовато таких хостингов, и 20к+ файлов для проекта аля визитка, ну совсем не феншуйно, лучше бы просто перешли на ооп модель, а не городили огород с симфони
Начерта визитке, не то что Друпал, а вообще CMS??
визитки бывают разные 5-10-20+ страниц, и на друпале их делать, как и лендинги, мне весьма удобно,
а вообще сложилось впечатление что друпал повторяет путь винды:
6 - win xp
7 - win 7
8 - win 8
Ну да. Только 8-ка это Виста
Такие же мысли и у меня были. Хотя window 8.1 не хуже семерки будет. У меня ноутбук на 8.1 быстрее разряжается и wi-fi бывает вылетает.
Не бывает визиток на овер 3-4 страницы (и то! в современном понимании нет смысла и для этих нескольких в пользу одностраничников). 5+ это уже что-то заколхоженное под визитку.
Но и в этом случае, не факт что понадобится CMS (тут не в к-ве страниц дело).
у нас с тобой разный опыт на счет визиток, и
нужна или не нужна цмс определяет заказчик, но чтото я не помню хоть одного проекта где заказчик сказал мне что ему не нужна цмска для работы с контентом.
Да, опыт может быть разный.
В своем опыте я тоже, признаться, делал "визитки", и тоже делал с CMS. Но делал потому что умел только так, и в мозгу не было еще достаточно нейронных образований для того чтоб объяснять заказчику что и как работает.
Когда начал понимать, когда начал объяснять и приводить доводы - оказалось что заказчик вполне может внять, и вместе с ним можно определить реальную надобность CMS'ки для сколь небольших проектиков.
А так, если просто "парить сайтик", то конечно пользователь скажет "ннада", кто же откажется от "сможете в любой момент изменить любой контент, и картинки-там, контактики..."
И, даже если нужна она там, мне и на 7ку чота стыдно было тянуть на микросайты, а 8ку - это ж вообще вредительство. Как грит Г. Янг, "спроси разработчика что нужно чтоб написать бложиг - он возьмет J2EE, Spring и еще кучу ненужной биллиберды, начнет диаграмки рисовать, строить модельки, хотя можно вместо всего этого просто Wordpress (тьфуего) развернуть за 3 минутки". Оверинжиниринг - он такой
эх!
Такие же мысли и у меня были. Хотя window 8.1 не хуже семерки будет. Ноутбук на 8.1 быстрее разряжается и wi-fi бывает вылетает.
Надеюсь, ты понимаешь, что задавать такие вопросы не очень умно? Равно как и проводить градацию, сколько страниц должно быть в визитке.
Но я постараюсь ответить. Допустим, есть некий веб-разработчик, который делает сайты-визитки. Он набил руку, чтобы верстать всякий статичный html и делает по одному такому сайту в день, по 20 в месяц. По 240 в год. И вот теперь представим, что будет через год с этим разработчиком, когда по каждому из 240 сайтов нужно будет раз в месяц зайти поменять телефон/код метрики/текст об окончании акции и т.д.
Конечно, есть вариант отправить всех таких клиентов на какую-нибудь тильду, но там не каждый сможет сделать красиво, а если прибегнуть к помощи агентств, делающих на тильде, то по деньгам будет то же самое, что заказать визитку на цмс.
Ну и напоследок вопрос: если я неспеша делаю одностраничник по индивидуальному дизайну на друпал 8 за 4-6 часов, то какой профит будет, если я стану делать это же каким-либо другим способом?
Ну камон! Кому раз в месяц телефон менять нужно?
Тут в том то и смысл, что просят потому что менять можно будет, но в итоге никто ничего не меняет годами. А если меняется каждый день что-то на сайте, это явно уже не визитка. Это раз.
Два. Если и нужно будет менять, то не факт что вообще разработчик понадобится. Есть куча ГУИни способной билдить статику сейчас. Это не причина тянуть целый комбайн под капот, только потому что разработчику так удобнее, он так умеет.
Три. Если мы уже говорим о потоковой разработке, которая еще и на поддержке - нужно соображать какой-нибудь инструмент для сопровождения таких решений. Это уже за рамками кейса, но вот тут Друпал - действительно может пригодиться, и тем не менее и на эти случаи есть множество куда более удобных, специализированных инструментов.
Контраргумент: А ничего что этому разработчику (или владельцу) придется следить за актуальностью всего этого зоопарка, помимо внесения тех же изменений? Разве это не заведомая подписка на времяпровождение за этими сайтиками? И это только ради того, чтоб оно там "лежало и бездействовало".
Итого, получается: контент сайта, по-сути, статичный, а Drupal, который использовался только разработчиком, чтоб собрать этот сайт - тупо производит действия которые можно было бы и не производить. )))
В чем же тут профит?
В моем понимании, сайт нуждается в системе управления содержимым только если там есть реальная необходимость частых внесений правок или добавления данных. Это явно не про визитки и не про одностраничники. А навязывание системы разработчиком только ради собственного удобства - как-то не особо хорошая практика, как по мне.
Ну, и конечно кейсы, когда заказчик действительно просит "хочу друпал" и "упирается рогом" - тут, безусловно, он барин, хочет - получит.
А вот тут я не представляю какой ответ ожидается...
А какой профит сейчас? И какой ты ожидаешь получить от "другого способа"?
Разные системы, разные задачи, разные решения, разные ожидания и разный профит от всего этого.
Что значит "разработчик навязывает друпал ради собственного удобства"? Если сайт сделают в итоге на любой другой технологии, то точно так же можно будет сказать и про неё. В данном случае друпал - всего лишь инструмент.
Профит сейчас в том, что я могу сделать довольно быстро даже одностраничник на друпале - эта скорость разработки приемлема для меня и для меня это достаточный аргумент в пользу друпала.
Что я ожидаю получить от другого способа? Ну хз, это ведь ты утверждаешь, что визиткам не нужны ни друпал, ни цмс вообще, а сам не назвал никаких преимуществ других способов перед использованием друпал.
PS: аргумент о количестве файлов не принимается.
Значит что друпал не нужен ни для чего другого, кроме как для разработчика (он умеет только друпал, потому на нем только все и делает).
Все верно. Потому с навязыванием нужно быть крайне осторожным, и не навязывать там, где можно обойтись бе этого.
Чем быстрее сделать одностраничник с друпалом, чем на любой другой технологии, начиная с нексто-нукстов, продолжая тильдо-виксами, и заканчивая голым хтмл?
Преимуществ? В данном случае, использование системы для генерации динамики, в статичных, по своей сути сайтах - абсолютное излишество. По мне, это недостаток. Седовательно, избавление от этого недостатка - преимущество.
Я не говорю, что на друпале быстрее. Я говорю, что я на друпале делаю это достаточно быстро для того, чтобы не думать о смене технологии
Значит next/nuxt из твоего списка вычёркиваем по той же причине. Плюс там node_modules весит огого.
А ещё интересно, будет ли "статичным" сайт, у которого есть форма обратной связи?
Не значит. Они же не крутят пых на сервере просто, чтоб не ржавел. Да и им пых может и вообще не понадобиться, они сгенерировали, отработали и все, нет той кучи node_modules.
Будет. <facepalm>
Ты по ходу, никогда с некстом не работал просто. Некст не крутит пхп на серваке - это факт)))) но без ноды на сервере он никуда не поедет, то есть вместо шаред хостинга уже нужен сервак. Зато нет излишеств в виде "генератора динамики", очень смешно да.
Как предлагаешь на "статическом сайте без излишеств" реализовать отправку форм + сохранение результатов + отправку результатов в CRM + защиту от спама?
Йоу! https://nextjs.org/docs#static-html-export
Леха, я начинаю волноваться за твой уровень знаний.Ни отправка форм, ни передача данных, ни спамофильтры - не являются only-drupal-handled knowhow.
формы отправляются прямо на CRM, в 99% случаев (просто из-за того что я еще не встречал обратного) CRM предоставляет формогенератор, который просто "вставьте фрагмент кода". Они же и со спамом помогут бороться, когда рекапча будет пропускать таких.
А тебе не кажется, что держать целую CRM ради форм на статическом сайте - излишество?)))
Больше. Некоторые целый бизнес строят, ради того чтоб было что на статическом сайте разместить
Вообще, в сфере экономика такова, что чем больше излишеств будет у клиента на сайте, тем больше излишеств сможет себе позволить в жизни разработчик
Так-то оно так. Но, как показывает практика такие суждения не особо дальновидные.
Излишество === улучшение не приносит прибыли, соответствующей затраченому времени/деньгам
А это значит, что любое, даже охрененно сделанное излишество, по определению убыточно для клиента
И это также значит, что умный клиент (нам тупые не нужны же) дважды будет думать перед обращением за очередной эволюцией, так как предыдущая эволюция стоила ему денег, а прибыли не принесла (см. определение)
Всё не так. Админка сайта-одностраничника не приносит никакой прибыли. Но отсутствие админки сайта приносит убытки в виде оплаты работы разработчика при редактировании контента.
Меньше попаболи и клиент, который придёт в следующий раз - это как-то не вяжется с тем, что менять телефон или код метрики может только разработчик через исходный код.
Наша песня хороша...
Давай с другой стороны.
Хоть, телефон != контент (как и код метрики), но пусть будет сферой влияния CMS.
Для изменения только этих конфигов, снова же, целый Друпал - излишество. Это можно хендлить не только Друпалом и не только в исходном коде.
Но! Я уже задолбался доказывать что-то, что для меня является абсолютно очевидным. Я привел доводы. Нравится решать такие задачи Друпалом, считаете его подходящим инструментом для этого - дело ваше.
А почему это телефон != контент? А адрес - это контент? А название компании? А блок "наши преимущества"? А сео-текст внизу страницы? А картинки из слайдера? Не, ну ок, допустим, это конфиги, но у владельца сайта должен быть доступ к их правке, то есть админка, и друпал неплохо с этим справится, а ты так и не предложил достойную альтернативу в данном случае.
телефон != контент
адрес != контент
название компании != контент
блок "наши преимущества" == контент
сео-текст внизу страницы == контент
картинки из слайдера - могут быть контентом, а могут быть частью декораций. Зависит от контекста и/или необходимости внесения изменений в них.
Альтернатива - чистый, статический ХТМЛ, для сайтов, данные на котором не меняются (сайты-визитки, лендинги и т.п.)
ЗЫ - хз как кто, лично я, за таски вроде "изменить телефон" / "добавить счетчик" - никогда не брал денег, и не понимаю почему должен. И они не поступают в сумасшедшем количестве, но и проекты не такие, на которых такие таски могут превалировать.
В том то и дело, что денег за такое брать не принято. Но представь, у тебя работа горит, ты весь в делах, а тут надо поменять телефон кому-то на сайте. Ты такой "ок, конечно, уже бросаю все дела", а они тебе "и текст на слайдере поменяй плиз, вот это напиши". Ты такой "ок, без проблем". А они через полчаса звонят и говорят "ой нет, слышь, там фраза сильно длинная, на планшете текст вылазит - давай напишем короче", а ты такой "ок, без проблем". А потом берёшься за тот проект, который делал до того, как тебе позвонили, а тут тебе звонят с другого сайта.
Ну ладно, я поверю в твою безграничную доброту и в абсолютную адекватность твоих заказчиков, но представь другую ситуацию: ты сменил профессию/место работы/ушёл на повышение или на пенсию, тебе звонит клиент и говорит "Э, поменяй-ка мне телефон", а ты ему "Джонни, ты же знаешь, я давно отошёл от дел". Клиент весь такой в недоумении, как же ему поступить в этой ситуации, а ты ему "Зато у тебя на серваке пых не крутится вхолостую и излишеств нет!"
А если телефон сменится не на сайте, а у тебя? Тогда точно нужно искать на доработку спеца, который возьмёт деньги.
Еще раз.
Если есть необходимость постоянного внесения правок - фигачим цмс. Нет - статика. Визитки не предполагают частых изменений, по определению.
В том то и дело, что никто не знает наперёд, насколько часто придётся вносить изменения.
Ну, с тем же успехом можно клепать редактор стилей, вдруг захотят цвет фона изменить, в каждом блоке, и отступы, и шрифты, и домен, и мера города... Ну, шоб було.
есть еще шикарнейший https://www.drupal.org/project/tome . Который сгенерит статику с вашего drupal-сайта.
Интересная штука, спс.
А почему у него Драш в требованиях? Я Драшем пользуюсь, но для 7ки.
Но чаще(имхо) бывает так, приходит заказчик:
Он тебе: Хочу сайт, одно товарное предложение в 5-ти модификациях и телефон в шапку.
Ты ему: отлично, статика, тяп-ляп - готово!
Он тебе: Супер! Осталось добавить пару штришков: интерграция с АТС,CRM и т.п. и онлайн заказ.
Ты ему: Блииин! Этож все с нуля надо будет делать, на CMS.
Он тебе: ****************!!!...**.
Блин, снова какие-то овер-требования, к визиткам отношения не имеющие...
Какие же, блин, сиэрэм на визитке, на столько сложные, чтоб без друпала никак? Или формочку контактов уже слабо скопипастить у вендора?
зы - У меня чувство, что я сейчас превратился в друпал-хейтера, в глазах читателей. В то время как я говорю о том что друпал не не нужно использовать, а всего лишь не нужно использовать как воздух, везде где только получается к пыху дорваться, и особенно там где он совершенно не нужен.
Ммм. например какие инструменты?
Промы, тильды, виксы, другие саасы (не углублялся в анализ рынка). Если ручками - любой компонентный фреймворк, с инструментом для билда статы.
Фреймворк для билда статы - мне норм drupal + tome. Есть визивиг для контент-менеджеров. собирать аналогичное на ларавеле, это убить год.)
Я такие хостинги всего пару раз видел и не стал бы принимать во внимание их существование, т.к. не считаю это хоть сколько-нибудь нормальным.
А чем не угодил симфони? Что бы поменялось, если бы его там не было? У вас есть соображения, как переписать, к примеру, систему контроллеров так, чтобы не использовать симфони?
единственное что меня не устраивает в 8 это количество файлов
ничего против симфони не имею, но слежу и за Backdrop CMS
да и что спорить как лучше было бы написать/реализовать, уже все сделано/написано, остается только грызть кактус, нравится мне это или нет
Я так понимаю, инструментами для вёрстки, вроде gulp или webpack вы не пользуетесь по той же причине?
dima 2202, многим нравится 7ка за меньший размер файла и БД и относительную "шустрость", но они стесняются об этом говорить. Потому как надеются работать со звез
датыными международными компаниями и беспокоятся за историю своих постов в интернетах.Вы нашли в Друпале, то что хотели - пользуйтесь. Так, как сейчас вечно не будет. Хотите узнать преимущества 8-ки - попробуйте магазин с кастомной корзиной собрать - в 8ке накликать можно больше
Почитал ответы в комментах, ответы в основном одни - что за D8 будущие и что D7 не будет поддерживатся и все в этом духе. А чем D8 лучше D7 и что можно сделать на D8, чего нельзя сделать на D7??? никто никаких фактов не привел. А что:
Для меня безразлично, мне главное работа и результат.
Складывается мнение что D8 просто пиар. Это как айфон много шума вокруг а по сути телефон так себе, хуже самсунга.
1:0 В пользу D8! "Cвои 5 копеек" - На D7 kiskart можно накликать все что нужно для современного интернет-магазина. 0:1В пользу D7!
Понравился ответ VasyOK - человек с большим опытом в друпале. А Drupal - Русскоязычное сообщество на каком drupal ??? Не сомневаюсь что на D8, но все же....
Уже не первый топик по этому сабжу
Забавно что все, кто поднимает эту тему раньше с друпалом не работал (или работал мало)
Но гнет свою линию так, как будто написал фэйсбук на д8, потом понял что это говно и переписал на д7 и вот - пожалуйста - он теперь Цукенберг.
Всем, кто работает больше года с друпалом, ничего не надо объяснять.
Мне надоело убеждать людей. Есть десятки статей, там всё написано. Читайте. Познавайте. Пробуйте, в конце-концов.
Ни одного факта, как обычно. Линию я свою не гну, с друпалом я работал, да мало. Пробывал делать на D7 и на D8, потому и задал такой вопрос что можно сделать на D8, что нельзя сделать на D7?
Я меньше года работаю, хорошо им не надо объяснять, а мне вот надо, только вот до сих пор никто объяснить не может. Нет, нет! я не ферзь с горы, которому обязаны что то объяснять! Просто очень хотелось бы услышать мнение опытных друпальщиков.
P.S у меня слабый ноутбук и локалка openserver пробывал работать и на D7 и на D8. Семерка просто летает, в отличии от D8 (просто тормоз!) может это не довод но все же, если на локалке медленнее работает D8 (VDS? а если без?) то может и на боевом сервере тоже медленнее. -> Я не утверждаю, не нужно бросаться в меня помидорчиками, просто рассуждаю. Для чего такое количество файлов в D8??? На семерке меньше в разы! А по функционалу я так и не понял чем D7 уступает D8? И еще раз я не гну свою линию что D7 лучше! Мой контекст: чем же все таки D8 лучше D7? Что в нем особенного, что такого специфичного можно написать на D8, что нельзя на D7 ? Скорость создания(работа, наполнение контента, настройка тем, установка и настройка модулей и т.д и т.п...) какого нибудь сайта, тоже не заметил что в D8 разрабатывать быстрее. Может по другому вопрос задать? Вопрос: Почему не стоит сейчас разрабатывать современные сайты на drupal 7?
Добавьте в сравнение еще Drupal6. На нем тоже много сайтов в интернете живет, файлов еще меньше, чем в д7, и никаких композеров к тому же. И летает на локалке - рекомендуемые требования по раме кажется 32мб. Топ решение в 2019!
Точно, забыл. И Ядро чистенькое! Никаких тебе филдов, визивигов и вивсов в поставке - никто не навязывает этих ангажированных решений!
Функционал на drupal7 для современных сайтов думаю на много превосходит drupal6. Разве не так?
Кстати работает под PHP 7.2 и поддерживается
https://www.mydropwizard.com/blog/announcing-drupal-645-and-selected-con...
А не плохой сайт
Ничего лишнего что бы раздражало, все просто. Ссылка вернутся вверх не очень понравилась не плавно поднимает, пару строк в js и все норм. Что там не так я не понял.
Там ссыль на коробку и модули на гите
Я не гну свою линию что D6 лучше! Мой контекст: чем же все таки D7 лучше D6? Что в нем особенного, что такого специфичного можно написать на D7, что нельзя на D6?
очень смешно
Скорость создания(работа, наполнение контента, настройка тем, установка и настройка модулей и т.д и т.п...) какого нибудь сайта, тоже не заметил что в D7 разрабатывать быстрее. Может по другому вопрос задать? Вопрос: Почему не стоит сейчас разрабатывать современные сайты на drupal 6?
Может хватит паясничать?
Я всего лишь хочу понять, чем д6 хуже д7. Неужели так сложно ответить?
Хватит за мной все повторять.
Отсутствие полей в профиле и в термине. Поля туда приделывались через доп модули, которые делали общую картину администрирования сайта нелогичной.
Если вы собираетесь разрабатывать сайты, работая в админке сайта и верстая темы, то семёрки вам может быть вполне достаточно. Параграфы, панели, вьюсы на семёрке работают превосходно, поэтому делать сайты на семёрке вполне себе можно, если вам хватает этого функционала. Я даже могу сказать, что AJAX в формах на семёрке работает значительно лучше и правильнее, чем на восьмёрке. Есть только одно НО - новых модулей под семёрку появляется всё меньше, а существующие в основном перешли в состояние баг- и секьюрити-фиксов, то есть не развиваются. Опять же это не проблема, если вам хватает существующего функционала.
Если же вы собираетесь решать задачи, где нужно кодить какой-то очень нестандартный функционал, то тут восьмёрка выигрывает по всем параметрам. Это всё именно из-за архитектуры. И из-за того огромного количества файлов
Столько файлов нужно для того, чтобы структурировать проект, что сильно ускоряет навигацию по коду.
Пример:
нам нужно сделать функционал, похожий на восстановление пароля по одноразовой ссылке.
Способ решения
Посмотреть, как это сделано в ядре и сделать так же. Возможно, частично использовав существующий функционал.
Решение на семёрке
Идём в модуль user. Заходим в файл user.module, а там несколько тысяч строк. Пытаемся найти, где там объявлен hook_menu с нужным урлом, потом ищем его коллбэк. Потом выясняется, что половина функций вынесена в инклюды - постоянно скроллим тысячи строк кода, находим нужные функции, копируем в свой модуль с десяток функций, долго думаем, что там и куда менять, в итоге делаем, всё работает, но написано не меньше тысячи строк кода, из которых большая часть - копия строк ядра, но немного изменённая.
Решение на восьмёрке
Идём в модуль user. Заходим в файл user.routing.yml, находим объявление нужного роута -там указан класс контроллера и вызываемый метод.
Открываем файл с контроллером из папки user/src/Controller (он просто не может лежать в другом месте), там значительно меньше строк, чем в семёрошных файлах, т.к. в этом файле лежит только то, что касается самого контроллера, и смотрим нужный метод. Далее принимаем решение, что делать. Например объявляем свой контроллер, наследуем его от вышеуказанного и переопределяем только нужные методы, написав всего пару десятков строк и потратив значительно меньше времени.
В двух словах, почему это происходит.
В восьмёрке используется ООП, что позволяет для изменения функционала использовать наследование, поэтому переопределять нужно совсем немного.
В семёрке всё построено на хуках, но хуки вызываются лишь в определённых местах. У меня был случай, когда надо было заставить скидки работать с разными валютами, нужно было переопределить всего одну строку в одной функции, но хуком это было нельзя сделать. Функция вызывалась из другой функции, а та из третьей, и только третью функцию можно было переопределить хуком. Как выглядело решение - пишем хук, меняем имя вызываемой функции на мою. Копируем существующую функцию в приблизительно 100 строк, и меняем в ней имя вызываемой функции на другую мою, которую получаем аналогичным копированием. В итоге, чтобы поменять одну строку, пришлось скопировать 300 строк кода. А если в исходном модуле поменяется функционал, то мне опять нужно будет всё копировать.
Вот вот вот все четко и по делу!!!! Нашелся такой человек который расставил все по полочкам. Очень Вам благодарен.
До меня все дошло, спасибо огромное. Вот они доводы и факты. Осталось все взвесить и сделать выбор.
Не только.
P.S. Так много отличий для конечной производительности и для разработчиков, что сразу все и не перечислить.
Давайте говорить прямо.
а. Вам понравился ответ Васька, потому что просто понравился. Никакой аргументации и пруфов у него нет, на этом уровне выбор выглядит как ответ на вопрос "С какого конца правильно есть яйцо". Только субъективизм.
б. Вы используете устаревший и/или не самый подходящий подход для разработки. У вас Windows, у вас OpenServer, ещё неизвестно какая версия PHP и с какими настройками. Если у вас проверенный локальный сервер из начала нулевых, то естественно, D7 там будет работать комфортнее, потому что данный релиз тоже из этого времени.
в. Никакого особого маркетинга у D8 нет, ровно как он и не нужен, это РАЗНЫЕ продукты и каждый хорош для своего времени.
г. Для условного сайт-билдера разницы между D7 и D8 нет от слова СОВСЕМ. Если спросить в чём сложность, смогут назвать аж два модуля, установка которых крайне рекомендуется через composer. Один это Commerce, модуль для создания интернет-магазина, по моему скромному мнению, интернет-магазины и сайт-билдерство не самые совместимые вещи, а уж одну команду в терминале можно бы и научиться копипастить.
д. Аргумент с темами оформления - ну такое, судя по вашим прошлым вопросам, уровень знания фронта у вас околонулевой, с таким будет везде сложно. И вины друпала тут нет, никакой версии.
е. А вот если говорить о плюсах, то даже самый минимальный плюс D8 - возможность экспортировать и импортировать конфиги, оставляет далеко позади D7, более ранние релизы и 99% других CMS. Это правда очень удобно. Но естественно, требует культуры разработки, которой у тех, кто в 2к19 году топит за D7 - нет
Ну вот и факты и критика, настало время обо всем подумать. Спасибо.
На какой локальный сервер стоит обратить внимание для drupal 8?
А какой подходящий подход разработки в 2019?
С фронтом у меня все нормально просто подзабыл элеметнарные вещи такие как найти строку кода через инспектор кода раньше использовал mozila и забыл. Работа, семья, проблемы некоторые вещи просто из головы вылетели за ноут давно не садился. А темы у друпала и правда полное Г... и друпал здесь причем так как темы созданы для друпала! Нужно в каждую лезть и править код. С эти у меня проблем нет теперь.
Ну да куда нам до таких высот и правда.
Drupal учу не для интернет магазина до них мне еще как до китая раком. Учу для того что бы создать базу с фильмами, новостной сайт, блог и т.д.
То есть на drupal 7 без установки через композер интернет магазин никакой не сделать????
Если честно не совсем понимаю зачем мне пока это нужно.
Какую очень интересно? Да, я не сомневаюсь что с композером работа будет быстрее идти. Но не могу на него пока настроится. А не умеешь работать с композером фу-фу-фу. Как то так мне кажется выглядит.
Да я позорный кликальщик, может даже здесь ник теперь себе такой поставлю чтобы всем все сразу ясно стало.
Я одно понял что я все делаю не то и не так. А как? Мне ->Иди учись.
У меня нет задачи с вами бороться.
Если вы это воспринимаете как "фу, свали позорный", воспринимайте и далее./
Как будете настроены на конструктив - пишите
Стоит обратить внимание на операционные системы семейства Lunix и Docker.
Разработка под windows это всегда особенное удовольствие, тормоза и непредсказуемость.
Либо, качайте навык тюнинга веб-серверов под винду, опыт говорит, что быстрее освоить докер.
Использование современных инструментов, как минимум, давно уже никто не пишет сайты в блокноте, не заливает файлы по FTP и прочее, прочее.
Git, Docker, SSH, Drush, Composer, IDE (PHPStorm, VSCode) - слова для гугления.
Сюда бы, конечно, ещё вписать CI/CD и другие страшные слова, но уже уровень чуть выше.
Если это вам незнакомо или вы забыли, то вам действительно лучше оставаться на Drupal 7, если вы хотите использовать удобства предоставляемые данными инструментами - Drupal 8.
Я повторюсь ещё раз, Drupal 7 и Drupal 8 это прекрасные продукты, но каждый прекрасен только в своем времени.
Век Drupal 7 - прошёл, что некоторые энтузиасты его до сих пор используют, ну так и жигули многие тюнингуют и убеждают, что не хуже иномарки.
Увы, но я вам не верю, больше похоже на отмазку студента перед преподавателем:
-Я знал, но забыл!
-Беда! Когда не знал, да ещё и забыл!
Пока у вас будет такой подход, что все окружающие пытаются вас унизить - толку будет ровно 0. И да, вас будут пытаться унизить, вы сами это провоцируете, и в исходном вопросе, и в своих ответах.
Drupal 7 и composer - это вещи из разных времен. И мне за ~10 лет опыта с Drupal 7 ниразу не приходилось использовать composer.
Неиспользование же composer в Drupal 8 - сродни одеванию трусов на голову. Да, можно, да, никто не запрещает, да, солнышко в темечко не печёт, но выглядит глупо.
Если вас устраивает работать как работали 10-15 лет назад, то и правда нет смысла.
Это как Виллариба и Виллабаджо
Навертели на своём локальном сервере, закачали по FTP дамп базы на хостинг, развернули его там.
Вспомнили, что затёрли этим ранее созданный контент, погоревали, нашарашили его руками, не беда, времени много, жизнь длинная, можно тратить её на дурную работу.
Тот у кого жизнь короче - сделает
git commit -a -m 'some functions'
git push
drush cim
И сэкономит минимум час времени в свой рабочий день.
Я довольно часто общаюсь с разработчиками других CMS, они правда не понимают зачем какие-то конфиги, когда можно просто гонять бекапы и дампы. И так как у них этого нет, им невозможно объяснить плюсы.
Сложно обсуждать вкус апельсином с человеком, который их не ел.
Которая написана на странице модуля
Я её даже продублирую:
composer require 'drupal/commerce:^2.13'Согласитесь, невероятно сложно, гораздо легче тратить время и стирать клавиши на клавиатуре рассказами про то, что композер усложнил жизнь.
Толи дело раньше:
А если какой-то конфликт, версия php не подходит или библиотеки не те, то об это узнаешь узнаешь уже по факту, когда твой сайт отказывается работать.
Вот это была разработка, а сейчас всё усложнили!
Мне ни к чему коммерс.
А действительно что я перед кем то оправдаваюсь особенно перед такими как ты.
Не царское это дело, перед каждыми щенком кланяться!
Все можете банить.
Я очень люблю взаимоисключающие параграфы.
Особенно, при ответах на вопросы. Особенно, когда сначала спрашивают про создание магазина, потом говорят, что магазин не интересует.
Вот параграф #1
Вот параграф #2
Да вы сами сольётесь, чего напрягаться с баном-то
Смотрю в даль.
, только после.
.
Ага ШИШ ТЕБЕ!!!
И не отвечай на мои вопросы больше здесь. О себе думаешь больше, чем есть на самом деле.
Не царское это дело слушать людей что они любят, а что не любят.
Отвечать в этом посту буду до конца времен.
Времена закончились ¯\_(ツ)_/¯
Отличное чувство юмора.
Лучше отредактируйте пост. Нормальная же дискуссия))
Я готов.
Какой локальный сервер выбрать для drupal 8?
Есть ли какие нибудь хорошие платные курсы где учат созданию интернет магазинов на drupal8?
Я живу в городе Красноярск.
Оптимально будет установить дружелюбный Linux дистрибутив (ubuntu, mint) и на него docker4drupal
Но это опять таки нужно потратить время на знакомство с этими системами.
хе-хе, я строгаю на drupal 7, пишу в блокноте и заливаю по фтп
и с седьмым друпалом
Уже несколько лет откладываю на потом гитхабы, композеры, командные строки, вебпаки, ларавелы и проч. Постоянно много нестандартных проектов, которые нужно запускать (бэкенды для приложений, магазины, сиэрэмки, сервисы документооборота, сервисы по управлению ip камерами, перепрошивки контроллеров, дефолтные промостраницы... что тока не заказывают). Все это я ставлю на друпал - как бы не смешно это не звучало
А пускать в работу технологию, в которой я не разбираюсь - это непредсказуемость сроков результата. Так вот и откладывается.
Работаю один, поэтому некому мне по рукам давать ) Нестандартный функционал пишу в своих модулях. Лично для меня проще открыть один фаил user.module и поиском найти нужный кусок кода, если нужно что подсмотреть, а не гадать кто там от кого унаследован, кто кем переопределён и что-то там автолоудится и откуда. Я не говорю, что это плохо или отстой - это не привычно просто для меня. И мне сложно перешагнуть это всё в данный момент.
Ни разу в жизни не использовал готовых тем, всегда пишу с нуля уникальную под дизайн, который сам же и проектирую. А поскольку люблю кодить и верстать я и админки верстаю уникальные. HTML код седьмого друпала может и избыточен, но зато позволяет мне одними стилями сверстать любой дизайн (крайне редко приходится переопределять шаблоны)
Это всё инструмент, как писал gun_dose, я эффективен с блокнотом и фтп
Другое дело если начинать без моего багажа, то нужно брать актуальные версии и технологии.
Знаем таках товарищей, и немало. И очень крутых, которых даже на phpstorm посадить проблематично.
Лично я сложные сайты (документообороты и тп) делаю на 7ке, на простых отрабатываю навыки работы на 8ке
Складывается со временем такое впечатление что на 8-ке в итоге и будут в большей части простые сайты на которых отрабатывали навыки
пролетают конечно и сложные, но соотношение не в пользу последних.