Ну то что ты самописного кода под друпал набодяжил неслабо, в этом вся разница и есть, поддерживать такое кроме тебя желающих не сильно найдется.
То что ты просто от анонимов собрал корзины и данные форм обратной связи - это тебя и спасло.
Что такое личный кабинет - это когда зареганный пользователь видит у себя свои заказы и может с ними работать. Как минимум.
Вот я чет совсем не уверен что коммерц вываливает свое rest api, по которому с ним можно работать с фронта.
Недолгое гугление показывает что если с корзиной, через доп модуль, еще что то есть, то чуток в сторону, уже пошла скачка.
А ведь с фронта и зарегаться надо и там и на апи, и чекаут и личный кабинет, и все под архитектуру коммерца...
Если вы не знали то в composer.lock записываются точные версии установленных пакетов. И когда выполняется composer install и оно видит что есть этот .lock файл, оно из него вот точно это и поставит. Т.е. эту папку vendor всегда можно удалить и поставить из .lock файла, главное вам чтобы эти файлы у вас были, в системе контроля версий той же.
Ну я ж об этом и говорю, сайт с поддержкой от студии, с услугами сисадмина - это совсем другое дело, в т.ч. по финансовым затратам.
Да и привязочка, в случае node.js на беке, к студии будет неслабая.
Но уж никак вариант когда заказчику отдали такой сайт и он уже с ним как то сам, как это в цмс-ках обычно.
Админку можно на yii2 сгенерировать, простые страницы круда.
Что увеличит трудоемкость - это друпал на бэке, когда фронт на js из этого друпала будет юзать десятую процента от архитектуры
Restful API - это довольно шаблонная вещь, на которую есть полно заготовок, а в php фреймворках и генераторов.
Вот и вопрос - зачем ради такой вещи ставить целого монстра как друпал. Только потому чтобы без php программиста? Это священная цель?
При этом пойдет что то уже дополнительное, нестандартное, друпал первым начнет палки в колеса ставить.
Так что я не вижу смысла чтобы из пушки по воробьям.
2) Да там в реалиях не одна нода то будет.
И нжинкс и БД и Redis т.п.
После пары разрабов, которые что то поруются под свои задачи, такие проекты мне напоминают каких то больных животных, где даже на уровне ОС нельзя гарантировать что все окей/безопасно настроено.
Это если еще сайт не начнут специально кумарить/ломать.
Тут вопрос - API над какими сущностями это будет?
В друпале же все вокруг нод крутится, а у них там кучи служебных полей, переводы и ревизии и куча всего остального, и вот это все из админки автоматом в API пойдет.
ivnish wrote: Заказчики обычно вообще не понимают, что делает разработчик, им главное чтобы задача была решена
Ну вот в друпале, если даже не считать заказчиков-посредников, и студии, заказчики такие что кто то им накапал против своих "кастомных" модулей. И эти кто то - друпалеры, вебмастера.
Вопрос тут - что вам надо.
1) Если вам нужна навороченная админка, по возможностям.
То у друпала традиционно очень все сложно организовано на уровне БД.
Поэтому если придется для такого API делать, явно тут какие то должны быть уже друпальные решения.
2) Но если всех этих наворотов не надо, то простую админку , как и API, можно довольно не трудно собрать на ларе/yii
p.s. А куда вы "отлучались на 5 лет"? Вообще из программирования или из веба?
1) А что разработка на js такая дорогая по сравнению с разработкой на drupal? В друпале наоборот можно зачастую пробродить впустую, время протратить, пытаясь функционал собрать, а оно не получится.
2) Я больше не про хостинг, а про поддержку, требование наличия сисадмина, если там будет VPS. Это же сразу уже усложняет все владельцу, это не админка где то на хостинге
digital_sword wrote: Например фронтенд на react или vue, бэкенд тоже на js, strapi например.
Реально - имеется ввиду не теоретическая возможность, а то что кто-то это делал, это имеет смысл, это по ряду причин лучше чем opencart или подобные cms.
Не понимаю как можно сравнивать такие вещи.
У опенкарта куча функционала, с тестами, с поддержкой сообщества, хостится где угодно.
Я обычно в резюме кидаю сразу список на кучу своего кода.
На примеры работ, доступ к админку демо сайта.
Девочки такое видят, не понимают, и передают уже технарю.
По длинному списку абревиатур, такое бывает, но даже если почитать HR-ов, то они эти списки часто понимают, как желательно знать, а не сразу обязательно.
Может оно выглядит как набор абривиатур когда человек - вебмастер, а просматривает вакансии для backend программистов?
Друпал он же много на себя времени требует, но во всем остальном роста никакого не дает.
А для фронтэнд разработчика, какими абривиатурами вас смогли бы удивить, вы же смотрю с Vue начали 2 года уже как знакомиться, а он как раз в тренде немалом сейчас. Или не вышло разобраться?
А вообще, это не справедливо, я бы даже сказал это дискриминация какая-то: друпал все больше становится CMF (ориентируется на разработчика, а не только на "сборщика" (CMS)).
Заметил что в commerce цену хранят в копейках.
Т.е. в админке вводишь 11$, хранится в БД число 1100.
Не подскажите где по коду эту логику искать, в доках не нашел, если честно сложно возвращаться к таким системам как друпал после фреймворков и ООП.
А не знаете, вот есть заказ и есть таблица строк этого заказа commerce_line_item
Не понимаю где у строки ссылка на id самого товара(product_id из commerce_product)
Или они тут намеренно через поле line_item_label хранят SKU и им ссылаются на товар? Удобно ли это если SKU изменится...
Вот таблица
Интернет-магазин на js фреймворке. Реально?
Ну то что ты самописного кода под друпал набодяжил неслабо, в этом вся разница и есть, поддерживать такое кроме тебя желающих не сильно найдется.
То что ты просто от анонимов собрал корзины и данные форм обратной связи - это тебя и спасло.
Что такое личный кабинет - это когда зареганный пользователь видит у себя свои заказы и может с ними работать. Как минимум.
Интернет-магазин на js фреймворке. Реально?
Вот я чет совсем не уверен что коммерц вываливает свое rest api, по которому с ним можно работать с фронта.
Недолгое гугление показывает что если с корзиной, через доп модуль, еще что то есть, то чуток в сторону, уже пошла скачка.
А ведь с фронта и зарегаться надо и там и на апи, и чекаут и личный кабинет, и все под архитектуру коммерца...
Интернет-магазин на js фреймворке. Реально?
Что за магазин то туда собрался ставить? Коммерц?
Как обезопасить себя от неудачного composer update? Бекапа файлов и БД достоточно?
Если вы не знали то в composer.lock записываются точные версии установленных пакетов. И когда выполняется composer install и оно видит что есть этот .lock файл, оно из него вот точно это и поставит. Т.е. эту папку vendor всегда можно удалить и поставить из .lock файла, главное вам чтобы эти файлы у вас были, в системе контроля версий той же.
Интернет-магазин на js фреймворке. Реально?
Ну я ж об этом и говорю, сайт с поддержкой от студии, с услугами сисадмина - это совсем другое дело, в т.ч. по финансовым затратам.
Да и привязочка, в случае node.js на беке, к студии будет неслабая.
Но уж никак вариант когда заказчику отдали такой сайт и он уже с ним как то сам, как это в цмс-ках обычно.
Интернет-магазин на js фреймворке. Реально?
Админку можно на yii2 сгенерировать, простые страницы круда.
Что увеличит трудоемкость - это друпал на бэке, когда фронт на js из этого друпала будет юзать десятую процента от архитектуры
Интернет-магазин на js фреймворке. Реально?
Restful API - это довольно шаблонная вещь, на которую есть полно заготовок, а в php фреймворках и генераторов.
Вот и вопрос - зачем ради такой вещи ставить целого монстра как друпал. Только потому чтобы без php программиста? Это священная цель?
При этом пойдет что то уже дополнительное, нестандартное, друпал первым начнет палки в колеса ставить.
Так что я не вижу смысла чтобы из пушки по воробьям.
Интернет-магазин на js фреймворке. Реально?
2) Да там в реалиях не одна нода то будет.
И нжинкс и БД и Redis т.п.
После пары разрабов, которые что то поруются под свои задачи, такие проекты мне напоминают каких то больных животных, где даже на уровне ОС нельзя гарантировать что все окей/безопасно настроено.
Это если еще сайт не начнут специально кумарить/ломать.
🎉 Запуск Drupal 9 — новейшая версия CMS, которая уже приносит пользу ведущим организациям по всему миру
Да модулей же на лрупал сайте обычно вагон и маленькая тележка, сотня, две, все их инструкции надо шерстить?
Интернет-магазин на js фреймворке. Реально?
Тут вопрос - API над какими сущностями это будет?
В друпале же все вокруг нод крутится, а у них там кучи служебных полей, переводы и ревизии и куча всего остального, и вот это все из админки автоматом в API пойдет.
Как дела вообще сейчас? На чем разрабатывают?
Рынок
Всегда в друпале тут такое было
Ну вот в друпале, если даже не считать заказчиков-посредников, и студии, заказчики такие что кто то им накапал против своих "кастомных" модулей. И эти кто то - друпалеры, вебмастера.
Интернет-магазин на js фреймворке. Реально?
Вопрос тут - что вам надо.
1) Если вам нужна навороченная админка, по возможностям.
То у друпала традиционно очень все сложно организовано на уровне БД.
Поэтому если придется для такого API делать, явно тут какие то должны быть уже друпальные решения.
2) Но если всех этих наворотов не надо, то простую админку , как и API, можно довольно не трудно собрать на ларе/yii
p.s. А куда вы "отлучались на 5 лет"? Вообще из программирования или из веба?
Интернет-магазин на js фреймворке. Реально?
1) А что разработка на js такая дорогая по сравнению с разработкой на drupal? В друпале наоборот можно зачастую пробродить впустую, время протратить, пытаясь функционал собрать, а оно не получится.
2) Я больше не про хостинг, а про поддержку, требование наличия сисадмина, если там будет VPS. Это же сразу уже усложняет все владельцу, это не админка где то на хостинге
Как дела вообще сейчас? На чем разрабатывают?
Как дела вообще сейчас? На чем разрабатывают?
Не разобрались значит?
2 года - это было то время, если всякие хабры почитать они про изучение Vue говорят - такой легкий, что "за пару дней".
Интернет-магазин на js фреймворке. Реально?
Не понимаю как можно сравнивать такие вещи.
У опенкарта куча функционала, с тестами, с поддержкой сообщества, хостится где угодно.
Как дела вообще сейчас? На чем разрабатывают?
Я обычно в резюме кидаю сразу список на кучу своего кода.
На примеры работ, доступ к админку демо сайта.
Девочки такое видят, не понимают, и передают уже технарю.
По длинному списку абревиатур, такое бывает, но даже если почитать HR-ов, то они эти списки часто понимают, как желательно знать, а не сразу обязательно.
Как дела вообще сейчас? На чем разрабатывают?
А что с Vue не срослось?
Я его как раз сейчас в основе изучил, начинаю практиковаться.
То что он к друпалу никак не контачит или другие причины?
Как дела вообще сейчас? На чем разрабатывают?
Может оно выглядит как набор абривиатур когда человек - вебмастер, а просматривает вакансии для backend программистов?
Друпал он же много на себя времени требует, но во всем остальном роста никакого не дает.
А для фронтэнд разработчика, какими абривиатурами вас смогли бы удивить, вы же смотрю с Vue начали 2 года уже как знакомиться, а он как раз в тренде немалом сейчас. Или не вышло разобраться?
В каком направлении развивается рынок Drupal
Как хранятся вариации на уровне БД в Commerce 1.x
Заметил что в commerce цену хранят в копейках.
Т.е. в админке вводишь 11$, хранится в БД число 1100.
Не подскажите где по коду эту логику искать, в доках не нашел, если честно сложно возвращаться к таким системам как друпал после фреймворков и ООП.
Как хранятся вариации на уровне БД в Commerce 1.x
Вот для этого оказывается и есть field_data_commerce_product , т.к. line item видимо сущность с полями.
Как хранятся вариации на уровне БД в Commerce 1.x
А не знаете, вот есть заказ и есть таблица строк этого заказа commerce_line_item
Не понимаю где у строки ссылка на id самого товара(product_id из commerce_product)
Или они тут намеренно через поле line_item_label хранят SKU и им ссылаются на товар? Удобно ли это если SKU изменится...
Вот таблица
Как хранятся вариации на уровне БД в Commerce 1.x
А инсталятора для commerce 2.x kickstart получается еще нет ?
Как хранятся вариации на уровне БД в Commerce 1.x
А мультимагазин - это уже фишка commerce2.x, в первом этого нет?
И что там со вторым на текущий момент, готовности к использованию, не подскажите?