предложенный подход для кастомизации темы «понатыкать кучу !important» в корне не верен, несет кучу проблем. Как вы сами уже и заметили.
Абсолютно согласен, но проблема в чем: я использую тему Salient и некоторые свойства, кастомизацию которых они сами не дали, мне приходится переписывать через !important, потому что внутри самой темы они написаны через !importnant…
И можно сказать: «Не используй noname темы» – но это одна из самых знаменитых тем WP вот пруфы: 100 000 покупок по 60$ и 5 звезд рейтинга.
Можно сказать: «Так поищи другую, нормальную тему, где нет в коде !important» – но так можно искать вечность.
Короче, лично мне надо делать тему с нуля.
Не вижу проблемы в «начать пилить самому». Для SSG при таком подходе нужен будет ровно такой же объем работ. Разве что вместо пхп будет другой язык
Именно об этом я и говорю: вы – PHP разработчик со стажем на WordPress, я – НЕ PHP разработчик со стажем на WordPress, и не хочу тратить время на его глубокое изучение, как и вспоминать PHP.
Поэтому для меня я вижу проблему начать пилить тему самому.
Ну, ровно то же самое можно сказать при первом знакомстве с WP — он устроен так, что можно легко и удобно добавить нужные плагины.
Через PHP, а я его не хочу использовать.
С SSG, уверяю, проблемы тоже есть.
Абсолютно согласен.
Есть плагины, которые умеют перегонять WP в статику.
Можно сгенерированное позже класть куда угодно.
Об этом я написал в статье и привел ссылку (даже с видео). Но и описал, что с этим тоже есть проблемы (например, не все WP плагины нормально работают в статике).
нет, разницы не вижу. Если WP + плагин дает ровно тот же функционал, то в чем разница?
Этот абзац посвящен удобству использования API.
Все ли плагины WP адаптируются под API? Нет.
Все ли плагины HCMS адаптируются под API? Да.
Вот и основная разница.
выше писал, что в статику WP перегоняется на раз-два. Даже банально, без плагинов — wget + развернутый локально сайт.
В статье и выше написал в чем будут проблемы с этим.
Не, технология отличная, но плюсов в переходе уже существующего проекта (так, чтоб они перевесили время на переход или чтоб время на переход вышло меньше, чем время на устранение проблем на текущей платформе) найти не смог.
Да, я отлично это понимаю и рад, что вы делаете здравый и правильный для себя выбор. Думаю, что если бы у меня был большой опыт с WP, я бы тоже без ооочень серьезной причины не стал бы переезжать.
Ой… Ну, вы прям замудрили… Можете написать проще что вы имеете ввиду? Что значит «молчат»? Что значит «не станет React»? Почему его «не станет»? И о каком «дирижабле» идет речь?
Именно поэтому когда пытаются манипулировать, то говорят о некой абстрактной пользе. А вот когда хотят реально вовлечь, говорят о конкретной выгоде.
У меня есть только личный опыт, я не могу обобщать на всех. Могу даже допустить, что есть такие работодатели, которые не используют этот прием для манипулирования сотрудниками.
Да почему же, знакомьте на здоровье...
Давайте так: глобально, я с вами согласен.
Вообще, каждый раз, когда я пишу статью о приемах созидательного менеджмента, приходят люди и рассказывают о своем негативном опыте в этом же ключе, потому что им попался менеджер-ублюдок, который использовал тот же самый инструмент, но со своими извращенной мотивацией. А таких гораздо больше, чем нормальных менеджеров.
Поэтому появляется ощущение, что автор (я) такой же, как они, и прием этот только для манипуляций.
Наверное, главный мой посыл: «Есть места, где умеют грамотно управлять людьми и где #{тема статьи} используется во благо, а не для манипуляции.» – стоит написать отдельный пост и давать на него ссылку во всех статьях «от чистой души и сердца», которые я пишу.
Любой инструмент в руках «негодяя» (как же сложно не материться)) будет использован во имя деструкции.
Поэтому, я надеюсь, что люди, у которых был негативный опыт, увидят, что есть альтернативы и что от одной и той же темы можно страдать на рабочем месте, а можно получать удовольствие.
Мне кажется, что вы рассматриваете слово «польза» как благотворное влияние на всех людей одновременно, но «польза» имеет также трактовку «выгода», поэтому: «Сигареты, алкоголь, наркотики» – самая распространенная выгода: «побег от проблем из-за неимения возможности их решить»; «реклама всяких «фуфломицинов»» – кому-то надо успоить свой невроз, он покупает фуфломицил и ему становится спокойнее, что и является для него выгодой; «уничтожение промышленных линий...» – выгода тем, кто купит металлолом и снимет торговую площадь и так далее.
Даже если по итогу это вредит людям, бизнес по-прежнему будет демонстрировать «выгоду» и продает он «выгоду».
Зачем, если этот работает и не требует практически никаких усилий?
Опять же, это выбор лично ваш, я не использую данный инструмент как понижение ставки, кто-то использует.
Но ваш текст подразумевает, что «все так делают», а значит вы говорите о том, что я своими действиями пытаюсь манипулировать людьми. Поэтому попрошу вас уточнить: вы говорите о том, что я написал эту статью, чтобы научить людей манипулировать другими? Или вы имеете ввиду, что существуют разные люди и разные ситуации и кто-то использует «причастность к фирме», как манипуляцию, а кто-то повышает вовлеченность и мотивацию человека во имя общего блага?
В случае, если это всегда манипуляция получается: «Нельзя знакомить бизнес и разработчиков» – а это поддерживает мои слова про очень плохую тенденцию сегрегации отдела разработки от остальной фирмы.
Объясняйте почему вот все переписать на RUST мы не можем ...
С этим согласен, этот диалог никак не противоречит тому, чтобы знакомить человека с ценностями фирмы и тоже должен присутствовать.
Разработчик быстро смекнет, что вы являетесь прослойкой, которая ничего не производит, а только забирает львиную долю прибыли
Ну, это какой-то «совковый» подход.
Если менеджеры правда «просто прослойка», то ок, таких студий куча. Но я в статье не беру «мусорный» сегмент в расчет, потому что в нормальной фирме, продажи, аккаунт, проджект и другие виды менеджмента – это важные детали качественного механизма.
Или вообще забирает базу клиентов и открывает свою студию.
Своя студия – это бизнес. Бизнес требует предпринимательского навыка. Разработчик – в первую очередь, «разработчик», а не «предприниматель».
Если ваши клиенты уходят к разработчику, который открывает свою студия, то 1 из 2-х:
1% вероятности – он оказывается талантливым предпринимателем для ведения своего дела.
99% вероятности – вся это ситуация происходит в диспозиции совковой студии, делающей низкомаржинальные сайты фрилансерами, для таких же совковых клиентов, которые готовы уйти от фирмы к конкретному разработчику.
Блин, ну просто это какой-то цирк) Нормальные проекты – это не работа 1-го разработчика.
Даже если она такое сделала, то это просто отвратительный клиент и слава богу что он ушел)
А вот когда условная «Студия Василия Пупкина» делает лендос / 1C-битрикс магазин за < 100к, ну да, там так и так 1 разработчик и сидит. Но такие фирмы – область хаоса, в которую я стараюсь не лезть (хотя там я там бывал, там весело)
… неподдерживаемая помойка, и нужно не новые фичи накладывать поверх, еще более загромождая код костылями, а переписать основу.
Да, тут я согласен, но вы говорите про «рефакторинг», а я фразой: «переписать все на RUST» – имею ввиду неадекватную мотивацию к перепиливанию всего. Рефакторинг – тонкая но правильная тема, перепиливание на RUST – в 95% случаев плохая тема.
Но начальнику, менеджеру-бизнесмену, от разработки далекому (а то и просто вчерашнему дяде с завода), это объяснять бесполезно, у него ж сроки горят!
Я от таких уходил и приходил туда, где все ок. Желаю всем того же.
Почему я все так уверено говорю? Потому что когда-то я создал свою студию Three Zeta Studio и ощутил все это на своей шкуре.
Да, несомненно, НО дело в том, что платят деньги только за «пользу». Начиная от пылесоса, которые ускоряет работу по дому (= польза), заканчивая астрологией / инфобизнесом, которая успокаивает / мотивирует человека (= польза, какая бы странная она не была).
Поэтому, если копнуть глубже деньги – это средство обмена, польза – это причина воспользоваться деньгами.
а пониманием что сейчас мы тратим на внедрение любой новой функции 40 часов ...
Заметьте, я специально написал: «переписать все на RUST» – и это не про грамотный рефакторинг, о котором написал iit ниже и с чем я согласен, а я писал про «неадекватный» рефакторинг, который делается во имя «написания топового кода».
Уточнение: Rust — прекрасный язык и в этой статье используется как аллюзия на «сложная и неподходящая под контекст технология».
А вот эти вот рассказы о том какую пользу приносит человечеству разработчик от того что решает проблемы вот этого вот бизнеса, они нужны ровно для одного — платить меньше разработчику, чтоб у владельца бизнеса оставалось больше денег.
Мне кажется, можно найти гораздо более грамотные способы снижать ставку разработчику) Чем и как будет снижать ставку нанимающая сторона – это ее личный вопрос и сюда можно притянуть любую причину. Я никогда не снижал ставку разработчика таким образом.
Боюсь, что опыт перехода с WordPress у меня только начнет появляться в ближайшие пару месяцев, после того как допишу курс.
Я попробую использовать Ghost.io для перехода с WordPress, потому что (1) он бесплатный, (2) разворачивается в 1 Docker контейнер, (3) любое событие в системе работает через hook, а значит можно встроиться в любой процесс, (4) куча инструкций на стыке Gatsby.js + Ghost.
Полноценное удобство деплоя SSG, возможно только в случае использования современных систем типа Netlify / Vercel, потому что они берут на себя всю работу по CI / CD.
Про preview-mode, да, придется применить свое решение: в случае с Ghost.io + Gatsby.js, можно запустить на сервере отдельный Gastby.js в режиме development, со своим доменом и прописать путь не до стандартного API, а до админского, который будет отдавать все draft («черновики»). Тогда редактор, при написании draft статьи сможет просматривать в режиме preview. Думаю, что существуют еще более простые пути решения вопроса, но это первое, что пришло в голову.
Сейчас я использую Markdown + Github + Vercel, что позволяет в отдельно репозитории делать ветку со статьей, править ее сколько хочу прямо в интерфейсе Github, каждая правка сохраняется как Pull Request и автоматически деплоится через Vercel с отдельным URL. Так что всей командой можем спокойно редактировать.
Про «человек, которые обычно ответственен за добавление новых статей в вордпрессе» – да, такая проблема имеется, потому что мало кто в рускоязычном сегменте использовал SSG + HCMS, поэтому придется дать людям время на привыкание.
Cвоими словами скажу так: у вас есть SSG, например, Gatsby.js. Он дает вам возможность писать статический и динамический контент на React. То есть, все что может быть статическим (страницы товаров, каталоги и т.д), будет выгружаться статически, а логику и отображение динамической части (корзина, поиск и т.д) вы спокойно пишете на React.
Соответственно, для реализации корзины вы можете:
В самом простом случае, вы реализуете логику (как показано здесь) через React Context / Redux + любое хранилище на фронте (localstorage, indexdb, etc.), а оплату можно делать через Stripe и подобные сервисы, где для формирования счета достаточно отправить метаданные о цене и товарах прямо с фронта.
Если нужно что-то сложнее, то подключаем Firebase / Hasura и имеем CRUD с фронта, с корзиной на backend.
Если нужно еще сложнее, то добавляем к Firebase / Hasura облачные лямбды (FaaS).
Если логика еще сложнее, то спокойно пишите свой серверный код и общаетесь с умным фронтом на React.
Абсолютно согласен, но проблема в чем: я использую тему Salient и некоторые свойства, кастомизацию которых они сами не дали, мне приходится переписывать через !important, потому что внутри самой темы они написаны через !importnant…
И можно сказать: «Не используй noname темы» – но это одна из самых знаменитых тем WP вот пруфы: 100 000 покупок по 60$ и 5 звезд рейтинга.
Можно сказать: «Так поищи другую, нормальную тему, где нет в коде !important» – но так можно искать вечность.
Короче, лично мне надо делать тему с нуля.
Именно об этом я и говорю: вы – PHP разработчик со стажем на WordPress, я – НЕ PHP разработчик со стажем на WordPress, и не хочу тратить время на его глубокое изучение, как и вспоминать PHP.
Поэтому для меня я вижу проблему начать пилить тему самому.
Через PHP, а я его не хочу использовать.
Абсолютно согласен.
Об этом я написал в статье и привел ссылку (даже с видео). Но и описал, что с этим тоже есть проблемы (например, не все WP плагины нормально работают в статике).
Этот абзац посвящен удобству использования API.
Все ли плагины WP адаптируются под API? Нет.
Все ли плагины HCMS адаптируются под API? Да.
Вот и основная разница.
В статье и выше написал в чем будут проблемы с этим.
Да, я отлично это понимаю и рад, что вы делаете здравый и правильный для себя выбор. Думаю, что если бы у меня был большой опыт с WP, я бы тоже без ооочень серьезной причины не стал бы переезжать.
Давайте так: глобально, я с вами согласен.
Вообще, каждый раз, когда я пишу статью о приемах созидательного менеджмента, приходят люди и рассказывают о своем негативном опыте в этом же ключе, потому что им попался менеджер-ублюдок, который использовал тот же самый инструмент, но со своими извращенной мотивацией. А таких гораздо больше, чем нормальных менеджеров.
Поэтому появляется ощущение, что автор (я) такой же, как они, и прием этот только для манипуляций.
Наверное, главный мой посыл: «Есть места, где умеют грамотно управлять людьми и где #{тема статьи} используется во благо, а не для манипуляции.» – стоит написать отдельный пост и давать на него ссылку во всех статьях «от чистой души и сердца», которые я пишу.
Любой инструмент в руках «негодяя» (как же сложно не материться)) будет использован во имя деструкции.
Поэтому, я надеюсь, что люди, у которых был негативный опыт, увидят, что есть альтернативы и что от одной и той же темы можно страдать на рабочем месте, а можно получать удовольствие.
Даже если по итогу это вредит людям, бизнес по-прежнему будет демонстрировать «выгоду» и продает он «выгоду».
Опять же, это выбор лично ваш, я не использую данный инструмент как понижение ставки, кто-то использует.
Но ваш текст подразумевает, что «все так делают», а значит вы говорите о том, что я своими действиями пытаюсь манипулировать людьми. Поэтому попрошу вас уточнить: вы говорите о том, что я написал эту статью, чтобы научить людей манипулировать другими? Или вы имеете ввиду, что существуют разные люди и разные ситуации и кто-то использует «причастность к фирме», как манипуляцию, а кто-то повышает вовлеченность и мотивацию человека во имя общего блага?
В случае, если это всегда манипуляция получается: «Нельзя знакомить бизнес и разработчиков» – а это поддерживает мои слова про очень плохую тенденцию сегрегации отдела разработки от остальной фирмы.
С этим согласен, этот диалог никак не противоречит тому, чтобы знакомить человека с ценностями фирмы и тоже должен присутствовать.
Ну, это какой-то «совковый» подход.
Если менеджеры правда «просто прослойка», то ок, таких студий куча. Но я в статье не беру «мусорный» сегмент в расчет, потому что в нормальной фирме, продажи, аккаунт, проджект и другие виды менеджмента – это важные детали качественного механизма.
Своя студия – это бизнес. Бизнес требует предпринимательского навыка. Разработчик – в первую очередь, «разработчик», а не «предприниматель».
Если ваши клиенты уходят к разработчику, который открывает свою студия, то 1 из 2-х:
1% вероятности – он оказывается талантливым предпринимателем для ведения своего дела.
99% вероятности – вся это ситуация происходит в диспозиции совковой студии, делающей низкомаржинальные сайты фрилансерами, для таких же совковых клиентов, которые готовы уйти от фирмы к конкретному разработчику.
Блин, ну просто это какой-то цирк) Нормальные проекты – это не работа 1-го разработчика.
Даже если она такое сделала, то это просто отвратительный клиент и слава богу что он ушел)
А вот когда условная «Студия Василия Пупкина» делает лендос / 1C-битрикс магазин за < 100к, ну да, там так и так 1 разработчик и сидит. Но такие фирмы – область хаоса, в которую я стараюсь не лезть (хотя там я там бывал, там весело)
Да, тут я согласен, но вы говорите про «рефакторинг», а я фразой: «переписать все на RUST» – имею ввиду неадекватную мотивацию к перепиливанию всего. Рефакторинг – тонкая но правильная тема, перепиливание на RUST – в 95% случаев плохая тема.
Я от таких уходил и приходил туда, где все ок. Желаю всем того же.
Почему я все так уверено говорю? Потому что когда-то я создал свою студию Three Zeta Studio и ощутил все это на своей шкуре.
Да, несомненно, НО дело в том, что платят деньги только за «пользу». Начиная от пылесоса, которые ускоряет работу по дому (= польза), заканчивая астрологией / инфобизнесом, которая успокаивает / мотивирует человека (= польза, какая бы странная она не была).
Поэтому, если копнуть глубже деньги – это средство обмена, польза – это причина воспользоваться деньгами.
Заметьте, я специально написал: «переписать все на RUST» – и это не про грамотный рефакторинг, о котором написал iit ниже и с чем я согласен, а я писал про «неадекватный» рефакторинг, который делается во имя «написания топового кода».
Уточнение: Rust — прекрасный язык и в этой статье используется как аллюзия на «сложная и неподходящая под контекст технология».
Мне кажется, можно найти гораздо более грамотные способы снижать ставку разработчику) Чем и как будет снижать ставку нанимающая сторона – это ее личный вопрос и сюда можно притянуть любую причину. Я никогда не снижал ставку разработчика таким образом.
Я попробую использовать Ghost.io для перехода с WordPress, потому что (1) он бесплатный, (2) разворачивается в 1 Docker контейнер, (3) любое событие в системе работает через hook, а значит можно встроиться в любой процесс, (4) куча инструкций на стыке Gatsby.js + Ghost.
Полноценное удобство деплоя SSG, возможно только в случае использования современных систем типа Netlify / Vercel, потому что они берут на себя всю работу по CI / CD.
Про preview-mode, да, придется применить свое решение: в случае с Ghost.io + Gatsby.js, можно запустить на сервере отдельный Gastby.js в режиме development, со своим доменом и прописать путь не до стандартного API, а до админского, который будет отдавать все draft («черновики»). Тогда редактор, при написании draft статьи сможет просматривать в режиме preview. Думаю, что существуют еще более простые пути решения вопроса, но это первое, что пришло в голову.
Сейчас я использую Markdown + Github + Vercel, что позволяет в отдельно репозитории делать ветку со статьей, править ее сколько хочу прямо в интерфейсе Github, каждая правка сохраняется как Pull Request и автоматически деплоится через Vercel с отдельным URL. Так что всей командой можем спокойно редактировать.
Про «человек, которые обычно ответственен за добавление новых статей в вордпрессе» – да, такая проблема имеется, потому что мало кто в рускоязычном сегменте использовал SSG + HCMS, поэтому придется дать людям время на привыкание.
Cвоими словами скажу так: у вас есть SSG, например, Gatsby.js. Он дает вам возможность писать статический и динамический контент на React. То есть, все что может быть статическим (страницы товаров, каталоги и т.д), будет выгружаться статически, а логику и отображение динамической части (корзина, поиск и т.д) вы спокойно пишете на React.
Соответственно, для реализации корзины вы можете:
В самом простом случае, вы реализуете логику (как показано здесь) через React Context / Redux + любое хранилище на фронте (localstorage, indexdb, etc.), а оплату можно делать через Stripe и подобные сервисы, где для формирования счета достаточно отправить метаданные о цене и товарах прямо с фронта.
Если нужно что-то сложнее, то подключаем Firebase / Hasura и имеем CRUD с фронта, с корзиной на backend.
Если нужно еще сложнее, то добавляем к Firebase / Hasura облачные лямбды (FaaS).
Если логика еще сложнее, то спокойно пишите свой серверный код и общаетесь с умным фронтом на React.
Я правильно понял и ответил на вопрос?