Как стать автором
Обновить

Комментарии 35

Хотя бы шаблоны основных элементов стоило бы сделать. Уже представляю, как будет матерится «кто-то другой» когда контактный номер телефона надо будет поменять 8 раз. А еще хуже — когда по этому образцу наклепают еще полсотни страниц по той же логике.
`sed` в баше, Ctrl + H в IDE. Тысячи их способов это сделать ))

А мож там хостинг вааще тупой? Без языков — только plain HTML.
А мож там хостинг вааще тупой? Без языков — только plain HTML.
В древности была такая тема как SSI (Server Side Includes). Вполне удобно для шаблонизации простейшего статического сайта. На некоторых хостингах даже разрешали IF в SSI.
Тоже иногда вспоминаю про SSI когда делается что-то простое и статическое. Просто и без лишних заморочек )
«Зачем вообще заморачиваться Sass? Старый добрый CSS прекрасно со всем справится.»
Потому что css не старый добрый, а просто старый? Добрый как раз Sass? В принципе на этой славной ноте просит можно заканчивать читать)
В данном конкретном случае, действительно, «правильнее» отдать заказчику статику. Но при разработке HTML/CSS, лично мне, было бы удобнее и быстрее воспользоваться своими наработанными инструментами, например, Middleman и т.п.
Короткий пересказ: чуваки, я на голом html сверстал сайт!
CMS для 8-страничного сайта не нужна, а вот SASS или LESS очень даже упрощают жизнь.
Совсем бошки потеряли со своими SASS и LESS. Для большого проекта да, для лендинга или статики на 10 страниц оно никому ненадо. И автор просто незнает ничего о CMS. Я бы делал на WP т.к. потом проще будет все менять и можно дать определенный доступ манагеру, который будет сам потом менять номера телефонов и добавлять новости. Потому как в противном случае им каждый раз придется нанимать за бабки вот таких вот вебдевелоперов которые из сайта сверстанном во FP делают сайт сверстанный во FP и говорят что они оптимизаторы и улучшатели.
Я тут недавно сделал сайт на WordPress, изрядно повозившись. Все ждал подвоха. Наконец-то нашел, когда решил перенести его на другой домен — это ДИЧАЙШИЙ геморрой на этом вашем wordpress-е. Куча статей, плагинов и прочих примеров в интернете и все это не работает до конца.
Более того, если вы, на время теста, запускали wordpress на другом порту и с другим URI ( например. domain.net:9000/newsite), то он все это ЖЕСТКО прописывает в базе (во всей этой каше wp_options сотоварищи) и нужно очень сильно постараться, чтобы сделать это рабочим на другом домене. Понимаете, вот прямо так и пишет для КАЖДОЙ картинки полный URL в базу: domain.net:9000/newsite/blabla.jpg. После этого вы не сможете даже перевести сайт на обязательный www.domain.net редиректом. Не говоря уже о другом URI. Такого отвратительного решения я не встречал еще ни разу в своей жизни, кажется, даже MS умнее решения делала.

В принципе, ничего другого от любителей PHP я не ожидал, там всегда так — сначала кажется очень легко и быстро, а потом (когда уже поздно дергаться) приходит пушистый зверек на букву П и остаётся только страдать.
В процессе смотрел код, API, вставлял разные заглушки (в поисках проблемы неизвестного характера), тоже оценил всю «красоту» решения.
Очень жаль, что достойные продукты не получают большого community (а с ним и множество контента типа тем и плагинов) в силу того, что порог вхождения в них прилично выше.

Ожидаю поток минусов от любителей, но правды не скрыть — ни в коем случае не пользуйтесь WordPress!
Вы описываете проблему никак в ней не разобравшись. С этим проблем вообще нет. Есть документация, как работать с прессом на локале и как выкатывать релиз. Есть большая ветка в багтрекере почему реализованы абсолютные урлы. Пока будете искать идеальную cms тут вордпресс уже REST API внедрил в ядро на начальном этапе. Так что ждем совершенно новые темы и плагины. Я тоже бесился с этих урлов но особо как то не мешают.Да и не вы первый, все это решаемо.
Очень жаль, что достойные продукты не получают большого community

Может потому что критерий достойности как раз большое комьюнити и определяет? Именно та золотая середина? А не то что нам хочется видеть в идеале как оно правильно?
Перепись ядра пресса на mvc в планах, но пока оно нафиг не нужно. Там огого еще идей нужно выкатить и как то… живут же. По факту… пресс божественнен. Нигде нет такого количества современных тем и простоты щелконастраиваний.
Типичное «вы просто не умеете это готовить» :) То есть сначала сами себе создали проблему, потом героически её решили. А кто не разобрался — сам виноват.
Ну то есть оно-то понятно, что всё легко, когда знаешь, умеешь и уже пробежался по всем граблям. Но нужно ли было их (грабли) изначально разбрасывать?
Мне вот тоже не нравится монстроидально-костыльная экосистема Вордпресса, построенная вокруг всего лишь блогового движка. Ну и оставался бы он блогом, и было бы чудесно. Но получилось как в анекдоте — «а теперь со всей этой фигней мы попробуем взлететь».

Вообще, сейчас инструменты и технологии плодятся с немыслимой скоростью. Но действительно отличных и тщательно продуманных среди них — единицы.
Судя по тому как развивается пресс проблемы как таковой нет, есть особенность. Ну что поделать если человек на wp проецирует опыт других cms?
Все докуметашке все разжевано, как работать.
codex.wordpress.org/Running_a_Development_Copy_of_WordPress
И есть еще куча способов. Я, например, делаю копию темы на сервере и запускаю ее в браузере через параметр в урле. В итоге на живом контенте есть версия сайта для разработки.
Проблема возникла уже после. После чего я с ней как раз и разобрался, с помощью зубила и такой-то матери, как в том анекдоте. Потому что штатного средства НЕТ. Особенно, если использовать темы, которые идут как static page (например, вот эти все: www.codexcoder.com/woo-cat/wordpress-themes)

Это первый продукт, по которому, оказывается, нужно читать документацию для запуска на чем-то отличном от продакшена. Вот что я в жизни не крутил — ничего подобного не встречал.
Я таки да, следовал документации по инсталляции и настройке и прочему, что-то отсюда: codex.wordpress.org/Installing_WordPress
Никакого упоминания об этом, я не увидел. Покажите, интересно (если это действительно правда, то это должно быть написано большими красными буквами в самом начале инструкции).

Очень интересно, почему же все-таки ссылки абсолютные на всё? Вот не могу представить пока ни одной причины. Подскажите тикет, почитаю, какой там очередной способ выстрелить себе в ногу изобрели.

Ну так это вопрос курицы и яйца — когда-то у него не было большого комьюнити. Мне не идеал хочется видеть, просто красивую, грамотно спроектированную систему, не более того. Здесь же внешний лоск themes затмил мне сознание просто :)

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

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

P.S. Если вы считаете, что ПРОСТЕЙШАЯ операция по смене домена сайта в любой другой системе, должна быть описана вот такими простынями (и это далеко не все, еще существует масса других дополнительных tips& trick и еще бОльшее количество plugin-ов):
codex.wordpress.org/Moving_WordPress
codex.wordpress.org/Changing_The_Site_URL
, то у нас с вами разное представление о достойности системы :-)
Я, вобщем то, вас прекрасно понимаю. Я бесился аналогично. Но по сути это все опять же особенности WP.
make.wordpress.org/core/handbook/contribute/design-decisions/#absolute-versus-relative-urls
Может быть Сергей, один из разработчиков ядра, flash_usb что и напишет, хотя обычно в дискуссии он не вступает, у него в комментах уже есть ответ.
Ну да, описание забавное. Самое смешное, что я, как, скажем, так, разработчик, понимаю, что никакой технической причины для этого не существует и всегда можно сделать и удобно и гибко. Но тут, видимо, какие-то свои мотивы :-)
Огромное количество компаний делают бабки на темах для пресса и разработки сайтов на прессе. Баг трекер пресса дымится и очень активен. Постоянно закрываются какие то моменты, ведутся споры, каждый релиз приносит действительно очень интересные возможности. Как я уже говорил они плавно внедряют REST API. Исходя из этого можно сказать что огромное количество людей подзабили на проблему абсолютных урлов в силу неведомой неактуальности на данный момент. В этом есть какая то магия на самом деле. Вроде уродство а всем уже как то давно пофиг.
Мне очень не нравятся некоторые моменты в прессе, но по всем моим желаниям в багтеркере кем то заведен тикет, и там стоит либо maybelater или futurerelease с конкретным обсуждением. Будущее у пресса большое. При всех его минусах есть какой то плагин, который решает проблему. И вся это экосистема нашла некоторую стабильность и активно развивается.
А чем он отличается от Drupal, Joomla и еще десятка подобных систем, почему именно у него большое будущее? Как по мне — обычная система на PHP, они все одинаковые. Просто в этой еще и в базе жестко все URL-ы прописаны.
Мне больше по душе такие штуки как plone.org или zotonic.com
Если уж и брать для развития что-то интересно. Хотя, понятное дело, на WP это быстрее и проще. Но только сначала :)
Ну я вам сейчас объясню чем кэнон хуже никона))))
Если все упрощать, то оно действительно все равно. Абсолютные урлы к картинкам прописаны в базе.да. Опять же это решается плагином простецким. Если какая проблема при переносе на домен, то поиск и замена в дампе.Либо через конфиги ну там куча способов. Девелоперскую версию можно разворачивать спокойно, весь мир так работает. Еще плагинов на выбор для наката релизов от разных компаний на любой вкус.
кстати, как бы вы в wp организовали манагеру смену телефона? :-) В wp пользовательских переменных, которые можно забивать в админке нет, разве что использовать виджеты.
там давно есть кастомизация как раз для таких случаев
codex.wordpress.org/Theme_Customization_API
После этого в настройках темы меняете все что нужно без гемора
«Дальше мне сразу захотелось применить какой-нибудь новомодный инструмент. Генератор статических сайтов, CMS, Sass, решётки, ещё какие-то модные штучки…»

Решётки?

image

«My next instinct was to apply our great modern web toolset to the site. Let’s add a static site generator or a CMS! Let’s add Sass and a grid system! Let’s do more fashionable things!»

А, решётки :)
image

Помните те времена, когда веб был очень простым? Он всё ещё способен на это, и наша задача – сделать его таким.

Прямо прослезился.
Для полного дао осталось выбросить phpstorm и достать из кладовки notepad.exe.
Скорее наоборот Dreamweaver. Именно в нем была возможность задавать фрагмент HTML как часть шаблона.
При редактировании шаблона он автоматически обновлялся во всех html файлах.
Зачем вообще заморачиваться Sass? Старый добрый CSS прекрасно со всем справится.
Зачем вообще заморачиваться с C++? Старый добрый ассемблер прекрасно со всем справится.

Помните те времена, когда веб был очень простым?

Раньше веб был простой, потому что эти самые 8 страничек могли висеть годами, не требуя изменений. Сейчас веб гораздо более динамичный (и я не про сотни тонн анимаций).
Ну куда нам со свиным веб-рылом да в нативный калашный ряд, конечно.
Сделал сайт на blocs статичный. Не скажу что не было мысли использовать хотя бы modx, тяжело каждый раз выгружать практически заново весь сайт, особенно после мелких правок в тексте. Пока держусь, не ставлю cms, все телодвижения делаю с помощью gulpjs, не знаю сколько это продлится.
Не могу не поддержать автора!
Использовать фреймворки/библиотеки/плагины(ФБП) и т.п. надо с умом и к месту, а не потому что он модный, стильный и весь такой размаркетингованный.
При должном подходе ФБП упрощают/ускоряют разработку, как следствие уменьшают вероятность возникновения ошибок в самом приложении и код становиться понятнее
Но они также на порядок увеличивают порог вхождения, вероятность появления трудноисправимых ошибок в самих ФБП, увеличивают время первой загрузки страницы и др.
А при неправильном подходе, так вообще могут быть только на вред

Т.е. если ты полностью разрабатываешь архитектуру, знаком или хотя бы поигрался с фреймворками, взвесил все + и -, оценил возможные другие варианты и т.п. имеет смысл использовать ФБП.
А ради обычного лендинга тянуть ангуляр в перемешку с другими ФБП…

P.S. На счёт CMS, может не CMS, но какую-нибудь простенькую админку можно припилить для того же удобства
чем навороченнее сайт, чем больше там всяких ФБП, тем больше трудоемкость при разработке и сопровождении. А значит больше заработок разработчика.

о0 з/п разрабочтика вообще хаотическая величина, прямо ни от чего не зависящая.
Но в идеале она больше зависит от качества выполненной работы, чем от хитрости используемых инструментов.
В большинстве случаев заказчик — далек от ИТ.
Он не может оценить качество, во всяком случае — не сразу. Зато айтишник может ему навешать на уши невероятное количество трудностей которые нужно преодолеть для решения задачи.
К примеру, ща модно применять клиентские фреймворки, которые появляются как грибы. Очевидно, что этот путь гораздо более трудоемок по сравнению с классической разработкой. Но заказчика можно ткнуть носом в гугл и показать что это типа тренд.

Смотря какой заказчик и разработчик. Это относиться к человеческому фактору.
Я же предполагаю ответственный подход к своей работе и рассматриваю только технический аспект вопроса.
При котором модно не значит рационально (см. первый комент)
Не, ну шаблонизацией, конечно, грех не воспользоваться. Всё таки при изменениях в хедере сайта или в футере придётся лопатить все 8 страниц. Тут CSS уже не поможет. Но тут поможет любой автономный шаблонизатор. Хотя бы тот же QuadBraces (50 килобайт кода в одном файле). И в целом вопрос поставлен хороший. Всегда удивляло, когда лендинги те же делают на CMS-ках. Особенно на «битриксе». Это вообще сказка. Обычно отговариваются, дескать, развитие и всё такое. Какое нафиг развитие? Вы сначала трезво оцените, проживёт ли ваш проект вообще больше года-двух. Это раз. А во-вторых, развитие часто подразумевает основательную переделку. Тут хоть на какой CMS делай, один хрен придётся основательно потрудиться. Главное в разработке — проработка архитектуры. Если архитектура проработана грамотно, то и переделка пройдёт без проблем. Сразу продумывать где на что опираться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории