Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
А если высоконагруженный проект с сложным функционалом, то что, тоже вордпресс?
Нет, конечно же. Дописывать существующую CMS будь-то WP, Joomla или иже с ними под уникальный функционал не имеет никакого смысла. В данной статье речь идет о создании сайта со стандартным набором функций.
А кто на что горазд — у моего провайдера, например, сайт и панель управления вертятся на какой-то доисторической джумле версии эдак 1.3. Центр СПб, если что.
Многие веб конторы пытаются втюхать сайты на своих cms, мотивируя это повышением уникальности для seo. Но как seoшник, могу сказать, что использование стандартных cms систем абсолютно дружелюбно для seo, нужно только само понимание работы поисковых систем. А вот от использования самопальных cms систем я бы предостерег. Самое опасное, что может случится, это потеря контактов с первоначальными разработчиками. Что-то допиливать на чужой cms мало, кто согласится
Всё зависит от проработаности самой cms и архитектуры, работал с одной самописной и был доволен, хорошая документированость кода, и довольно логически выстроеная архитектура. В wordpress очень много не квалифицированых разроботчиков, и много проблем как безопасности так и функционала. К примеру тот же модуль перевода не может технически перевести всё, нельзя отделить h1 от title, а где description прописать, keywords. Настройка заголовков тоже оставляет желать лучшего. Да элементарно просто сделать url `/ru/test.html` и `/en/test.html` средствами cms не возможно. Да элементарно перевод кнопки `over` в `далее` невозможен. От этого много кастылей и плохой код. Я к чему всё это, иногда самописная cms лучше чем хвалёный wordpress, bitrix и joomla, как для сео так и программиста.
Не буду спорить с Вами на счет чистоты кода или функциональности. Расскажу Вам ситуацию из жизни: обратился клиент за раскруткой сайта. Проведя анализ заметили, что на сайт валят спамные ссылки (покер, казино, туры и др.) на файлы с полным доступом (777), которые наш заказчик не создавал. Мы нашли папку в которой лежали эти xml файлы. Из файлов в свою очередь шли ссылки на другие ресурсы с такой же тематикой. Закольцевали вобщем. Сменили пароли, удалили файлы. Но через время они появляются снова. Сайт был на самописной cms, разработчик потерялся или морозится. Сторонние разрабы или не хотят браться или выставляют норм чек, причем с плавающей цифрой, поскольку не понятно где искать и сколько будет потрачено времени на решение проблемы. До сих пор вопрос так и не двигается с места. А позиции у ресурса падают.
Ну wordpress тоже не редко взламмывают, а установка git + найти и выкосить бэкдор, это от 1-ого до 2-х часов(анализ логов+анализ кода роутера) это не так много времени, ну да бывают ситуации и поверьте ни кто не застрохован. Так же вам попадёться разраб на wordpress который встроит тот же бэкдор в него. Делаем выводы элементарный git+свой репазиторий и вы сможете видеть все изменения и diff файлов, Что упрощает поиск таких бэкдоров.
Простите. Но если Вы не разобрались в чём-то, то не нужно писать, что это невозможно или не работает. Описанные Вами проблемы с url, переводом и заголовками — это всё делается из админки — даже не нужно лезть код.
Проблем безопасности у самого WordPress или нет, или их молниеносно закрывают обновлением.
Проблем безопасности у самого WordPress или нет, или их молниеносно закрывают обновлением.
Проблема безопасности в том, в чем его достоинство — обратная совместимость вынуждает тянуть за собой технические решения устаревшие на множество поколений кода назад. Это ограничивает в возможностях делать реальные меры защиты, поэтому всё в заплатках и не более. Нельзя взять и сделать обязательную защиту от XSRF в виде обязательного токена — поломается часть плагинов, часть тем. Заметная часть. Нельзя сделать песочницу в шаблонах — все шаблоны умрут. Нельзя поменять роутинг так, чтобы дыры в отключенных темах и плагинах не работали — потеря совместимости. Шаг вправо, шаг влево — потеря совместимости, а значит потеря лидирующих позиций. А без монопольного положения ВП неконкурентоспособен.
А так то да, прямых багов безопасности у него нет. После стольких то версий. Только косвенные — архитектура по типу ведро с дырками.
А так то да, прямых багов безопасности у него нет. После стольких то версий. Только косвенные — архитектура по типу ведро с дырками.
У меня более 100 сайтов на WP. + клиентские на поддержке. Никто ничего не ломал и не заливал. Ни разу. Ломанным ничем не пользуюсь. Всё обновляется очень быстро. Естественно, всегда выставляются определённые настройки доступа и т.п.
Значит Ваши сайты не интересны определенным людям или они о них даже не знают. В основном ломают интернет-магазины или системы с которых можно, что-то «поиметь» или для чего-то использовать.
Вот что ключевое в Вашем посте. Если хотите проверить, закажите аудит безопасности.
Никто ничего не ломал и не заливал.
Вот что ключевое в Вашем посте. Если хотите проверить, закажите аудит безопасности.
А Вы уверены, что если заказать аудит безопасности любого, созданного Вами сайта (или Mendel-ем) или же объявить награду за нахождение уязвимостей, то их не найдут? Я сомневаюсь в этом.
Уже все давно объявлено и в штате имеются сотрудники для аудита кода. При заключении договора, всегда оговаривается этот пункт.
И мы не используем WP в коммерческой разработке, что и остальным советую. Если требуется free-CMS для бюджетных организаций (госучреждения), то предпочитаю MODx — но стараемся не брать таких клиентов. Для всего остального есть фреймворк.
Мы говорили о Ваших проектах на WP и что их никто не ломал — значит Вы не можете быть уверены в их безопасности. Многие меня поддержат, что это дырявое ведро. Не зря Drupal переписал кода на Symfony2.
Заключение одного хорошего человека в 2015 году: «WordPress — довольно крупный и сложный продукт, со своими плюсами и минусами. К сожалению, в дефолтной конфигурации его безопасность находится под большим вопросом, так как даже обычный скрипткидис при наличии прямых рук и интернетов сможет пробить защиту.»
И мы не используем WP в коммерческой разработке, что и остальным советую. Если требуется free-CMS для бюджетных организаций (госучреждения), то предпочитаю MODx — но стараемся не брать таких клиентов. Для всего остального есть фреймворк.
Мы говорили о Ваших проектах на WP и что их никто не ломал — значит Вы не можете быть уверены в их безопасности. Многие меня поддержат, что это дырявое ведро. Не зря Drupal переписал кода на Symfony2.
Заключение одного хорошего человека в 2015 году: «WordPress — довольно крупный и сложный продукт, со своими плюсами и минусами. К сожалению, в дефолтной конфигурации его безопасность находится под большим вопросом, так как даже обычный скрипткидис при наличии прямых рук и интернетов сможет пробить защиту.»
Да какая разница на чём написано zend это или symfony и yii, в конце концов код люди пишут а не framework они то и допускают ошибки, просто где то их больше где то их меньше. Т.Е. От решения перепишем на symfony программист не перестанет допускать ошибок.
Не соглашусь с Вами полностью. На то он и фреймворк, что в нем уже есть готовые и проверенные компоненты. А при написании на нативе, то этих самых ошибок будет гораздо больше + во фреймворке, есть хорошая система логирования и все можно проследить. Обычно все ошибки в безопасности можно выявить на этапе разработки и альфа-тестировании.
Поверте если человек писал `select * from t1 where id=$_GET['id']` то пересев на фреймворк он так же будет писать `->setLimit($_GET['limit'])` т.е. тут нужны больше знания а не инструмент.
Сразу видно, что Вы не работали во фремворках. И как раз не понимаете смысл инструментов и как они работают и не обладаете знаниями в их использовании.
И Ваш запрос: `select * from t1 where id=$_GET['id']` — работать не будет ;) Сможете сказать почему?
И Ваш запрос: `select * from t1 where id=$_GET['id']` — работать не будет ;) Сможете сказать почему?
Ну а зачем же методы для фильтрации и синетизации переменых? не один фреймворк автоматом не фильтрует пользовательские переменные get и post, почему то много людей видел с такими же убеждениями. К примеру из недавнего http://dev.divogames.ru/search/?query=t%22
p.s. запрос к примеру приведён.
p.s. запрос к примеру приведён.
Зато доктрина фильтрует при построении запроса.
Пока вы не укажите в `queryBuilder` что в запросе параметр integer или строка или timestamp или datetime. Ни чего вам ни кто не отфильтрует(точнее там сенитизация применяеться) в принципе в автоматическом режиме… Да и возможности писать прямые запросы есть, и вообще много факторов. Имено по этому только знания программиста и опыт приводят качеству и безопасности а не инструмент…
Для этого и есть ORM. Я говорю о том, что на фреймворке допуск ошибок меньше, чем при нативной разработке. И выявить их можно на первых этапах. А Вы мне говорите о знаниях — человек начиная изучать фреймворк будет постепенно постигать и ORM, и остальные знания — даже в технике безопасности использования того или иного запроса.
Вы правы что ошибок допускаеться меньше. Но всё же не один фреймворк не обезопасит на 100%. Но вы сильно полагаетесь на framework забывая о знаниях а по безопасности процентов 80 php программистов либо незнают либо забивают.
Я просто работаю с этим каждый день, мы устраиваем тренинги и семинары для сотрудников по разным вопросам и безопасность не исключение. И в штате есть отдельные специалисты для аудита кода — как говорится доверяй, но проверяй. При заключении договора, мы всегда обговариваем пункт про безопасность написанных компонентов. Так как в основном работаем с коммерческими структурами — им это важно в любой области деятельности.
>если человек писал `select * from t1 where id=$_GET['id']` то пересев на фреймворк он так же будет писать `->setLimit($_GET['limit'])`
вот только во втором варианте sql injection нету
вот только во втором варианте sql injection нету
Если CMS выполнена на каком-нибудь популярном фреймворке со всеми рекомендациями, которые дает официальная документация этого фреймворка, то почему нет?
Разумеется, использование такого подхода должно быть целесообразным, а также клиент должен понимать примерную стоимость 1 часа работы разработчика на этом фреймворке, чтобы планировать бюджет на поддержку сайта.
Разумеется, использование такого подхода должно быть целесообразным, а также клиент должен понимать примерную стоимость 1 часа работы разработчика на этом фреймворке, чтобы планировать бюджет на поддержку сайта.
А чего вы рекомендуете именно themeforest? TemplateMonster были первыми. Themeforest вообще их афилиейт. Тем более TemplateMonster свои шаблоны продают, а themeforest — помойка для индусов.
ThemeForest действительно был афилиатом TemplateMonster. Но сейчас ситуация изменилась. Предложение на ThemeForest намного выше и посещаемость сайта соответственно, о чем свидетельствует показатели Alexa у ThemeForest — 325, у TemplateMonster — 2157 (а чем меньше, тем выше траф, причем многократно при этом порядке цифр). Относительно «помойки для индусов» не соглашусь, как я писал в своей статье о сложности размещения шаблона на Themeforest и их очень высоких требованиях к качеству. Среди разработчиков бытует мнение, что те, кто не «пролезли» на Themeforest, размещаются там, куда их принимают. А цены на Wordpress шаблоны на Themeforest ниже, потому что их выставляет сам маркетплэйс. С недавних пор на все категории товаров, кроме WordPress theme автор может самостоятельно устанавливать цену, а вот с категорией WordPress не решились так сделать.
Просто на themeforest у автора реферальная ссылка есть :)
Втюхать клиенту свою cms — больше шансов зацепить клиента на дальнейшее обслуживание… :) /старо как мир/
Каким образом можно обезопасить и сайт на Wordpress, и разработчика?
Вот года 1.5-2 назад запустили простенький сайт на Wordpress, наполнили его информацией и забыли про него. Иногда приходили сообщения о том, что Wordpress сам обновился. Потом сообщения перестали приходить, а потом хостер стал жаловаться на спам с этого сайта. Проверил — и правда, вирусы. На соседних сайтах вирусов не было и быть не может, в хостере тоже уверен. Каким образом избежать такого?
В результате сайт клиента простаивает, а разработчик получает проблем в самый неожиданный момент.
Как я понимаю, популярность системы несет с собой не только большое компьюнити, но и тщательный анализ кода со стороны взломщиков? А значит и множество информации об уязвимых точках приложения? И в таком случае надо что-то предпринимать для дополнительной защиты сайта, либо использовать другие решения.
Спасет ли регулярное обновление ядра? Или нужно что-то еще, если настройкой сервера занимается хостер?
Вот года 1.5-2 назад запустили простенький сайт на Wordpress, наполнили его информацией и забыли про него. Иногда приходили сообщения о том, что Wordpress сам обновился. Потом сообщения перестали приходить, а потом хостер стал жаловаться на спам с этого сайта. Проверил — и правда, вирусы. На соседних сайтах вирусов не было и быть не может, в хостере тоже уверен. Каким образом избежать такого?
В результате сайт клиента простаивает, а разработчик получает проблем в самый неожиданный момент.
Как я понимаю, популярность системы несет с собой не только большое компьюнити, но и тщательный анализ кода со стороны взломщиков? А значит и множество информации об уязвимых точках приложения? И в таком случае надо что-то предпринимать для дополнительной защиты сайта, либо использовать другие решения.
Спасет ли регулярное обновление ядра? Или нужно что-то еще, если настройкой сервера занимается хостер?
Мне недавно сломали мой маленький личный блог на вордпрессе — забыл обновить вовремя.
Вирусы вычистил, и проблему решил кардинально — запретом записи везде кроме контента. Да, плагины, темы, ядро уже так просто не обновить, но зато сильно меньше вероятность быть сломанным.
Вирусы вычистил, и проблему решил кардинально — запретом записи везде кроме контента. Да, плагины, темы, ядро уже так просто не обновить, но зато сильно меньше вероятность быть сломанным.
Вы правы. Если WP может по клику обновиться сам и обновить плагины — это уже дыра в безопасности!
Обязательно возможность executeться оставлять только корневому index.php. — Правда, могут глючить некоторые плагины из админки.
Если правильно настроить, то в периодических обновлениях исчезает необходимость (кроме случаев того или иного апгрейда сайта).
Обязательно возможность executeться оставлять только корневому index.php. — Правда, могут глючить некоторые плагины из админки.
Если правильно настроить, то в периодических обновлениях исчезает необходимость (кроме случаев того или иного апгрейда сайта).
Регулярное обновление ядра не спасет, так как есть зазор по времени между выявлением уязвимости и её ликвидацией. Все это время уязвимость может эксплуатироваться. А так как вычислить что сайт именно на WP не представляет никакой сложности, то сайт будет уязвим для автоматизированного взлома.
Кроме того сама архитектура WP никак не защищает сайт от уязвимостей в используемых плагинах и темах оформления(!).
Для какого то решения этой проблемы существуют автоматизированные плагины которые регулярно по крону сканируют сайт на предмет изменений в файлах (например популярный плагин Wordfence) и сообщают об изменениях письмом на почту, а также в какой то степени позволяют автоматически лечить (например загрузив исходный файл взамен зараженного из репозитория плагина/темы/ядра, если таковые имеются).
Ну и в какой то мере они закрывают другие векторы атак (блокируют по ip автовзломщиков, пытающихся подобрать пароль, меняют адрес для авторизации админа и т.д.).
Понятное дело что письма с отчетами должен кто то читать, а ликвидация последствий взлома никак не влияет на вероятность его повторения (уязвимость то не закрыта).
Ну и такой скан нагружает сайт (используются ресурсы хостинга).
Так что вопрос остается открытым.
Кроме того сама архитектура WP никак не защищает сайт от уязвимостей в используемых плагинах и темах оформления(!).
Для какого то решения этой проблемы существуют автоматизированные плагины которые регулярно по крону сканируют сайт на предмет изменений в файлах (например популярный плагин Wordfence) и сообщают об изменениях письмом на почту, а также в какой то степени позволяют автоматически лечить (например загрузив исходный файл взамен зараженного из репозитория плагина/темы/ядра, если таковые имеются).
Ну и в какой то мере они закрывают другие векторы атак (блокируют по ip автовзломщиков, пытающихся подобрать пароль, меняют адрес для авторизации админа и т.д.).
Понятное дело что письма с отчетами должен кто то читать, а ликвидация последствий взлома никак не влияет на вероятность его повторения (уязвимость то не закрыта).
Ну и такой скан нагружает сайт (используются ресурсы хостинга).
Так что вопрос остается открытым.
У меня аналогичная история. Взломали простенький узкоспециализированный сайт. Кому это понадобилось просто ума не приложу!
У меня опыт знакомства в WordPress закончился на этапе ознакомления с требованиями. Опечалила его прибитость гвоздями к MySQL и отсутствие внятной поддержки других БД, включая как минимум хотя бы PostgreSQL. Я понимаю, что можно долго рассуждать на тему «достаточности» MySQL для мелких сайтов и «как-бы сложности» PostgreSQL для не_администраторов баз данных, которые привыкли использовать MySQL. Но как показала практика, эксплуатация MySQL со временем приносит больше головной боли, чем однократное прочтение Quick Install для PostgreSQL.
Не холивара ради, но считаю это главным недостатком данного CMS.
Не холивара ради, но считаю это главным недостатком данного CMS.
Главный недостаток cms прибитость гвоздями всего и вся…
> Но как показала практика, эксплуатация MySQL со временем приносит больше головной боли, чем однократное прочтение Quick Install для
> PostgreSQL
Вообще, это какой-то сильно частный случай. Я думаю, не сильно ошибусь, если допущу, что 95% владельцев сайтов с MySQL никогда в жизни не столкнутся с проблемами из-за недостатков СУБД, а у остальных 5% практически во всех случаях она решится восстановлением из бекапа.
> PostgreSQL
Вообще, это какой-то сильно частный случай. Я думаю, не сильно ошибусь, если допущу, что 95% владельцев сайтов с MySQL никогда в жизни не столкнутся с проблемами из-за недостатков СУБД, а у остальных 5% практически во всех случаях она решится восстановлением из бекапа.
Вы меня конечно извините заранее. Но мое понимание коммерческой разработки с WP совсем не вяжется.
1. Это как всегда безопасность. WP — каким хорошим он бы не был в Ваших глазах, в моих — это дыра.
2. Привязка к MySQL.
3. Мало дыр в самом движке, так ещё дыры в шаблонах (мое мнение — php-шаблоны себя изжили, twig,smarty — в помощь).
Хуже WP, наверное, только Joomla и самопись велосипеда школьника. Как для Вашего личного блога — пожалуйста, используйте. Для корпоративного сайта компании — нет, нет и ещё раз нет. Каким бы сладким дизайн не был — один прокол в безопасности, один косяк в шаблоне или коде, расширении — не стираемое пятно на Вашей репутации, пускай Вы только его собирали и ничего не писали.
Если и брал бы CMS-free для разработки какого-то мелкого-среднего проекта — то, наверное, бы взял MODx. А для всего остального — фреймворк (Symfony, Yii, Silex).
Где-то уже видел компании использующие WP в коммерческой разработке — уже, вроде, загнулись.
Но когда у разработчика кривые руки — тут ничего не спасет, разве что статика на HTML.
1. Это как всегда безопасность. WP — каким хорошим он бы не был в Ваших глазах, в моих — это дыра.
2. Привязка к MySQL.
3. Мало дыр в самом движке, так ещё дыры в шаблонах (мое мнение — php-шаблоны себя изжили, twig,smarty — в помощь).
Хуже WP, наверное, только Joomla и самопись велосипеда школьника. Как для Вашего личного блога — пожалуйста, используйте. Для корпоративного сайта компании — нет, нет и ещё раз нет. Каким бы сладким дизайн не был — один прокол в безопасности, один косяк в шаблоне или коде, расширении — не стираемое пятно на Вашей репутации, пускай Вы только его собирали и ничего не писали.
Если и брал бы CMS-free для разработки какого-то мелкого-среднего проекта — то, наверное, бы взял MODx. А для всего остального — фреймворк (Symfony, Yii, Silex).
Где-то уже видел компании использующие WP в коммерческой разработке — уже, вроде, загнулись.
Но когда у разработчика кривые руки — тут ничего не спасет, разве что статика на HTML.
Как показывает опыт — допустить прокол в безопастности сильно проще, когда система самописная. При использовании готового решения главное следить за обновлениями и не ставить всякие «левые» плагины и темы. Т.е. в этом случае не надо быть большим гуру в безопасности.
А если говорить про репутационные риски — то при самописной системе и «свалить» вину не на кого. В отличии от.
А если говорить про репутационные риски — то при самописной системе и «свалить» вину не на кого. В отличии от.
Улыбнуло про свалить вину. На моей памяти при коммерческой разработке вина всегда лежит на исполнители — если имеется косяк в компонентах, которых он использовал, то вина лежит на нем, т.к. он не проверил их.
Приведу пример-ситуация, возможно выжатый их пальца:
«Я директор психологического центра (очень модно сейчас), заказываю корпоративный сайт у конторы: главный критерий в сайте это возможность принимать оплату за мои авторские тренинги и допускать к „вебинар-комнате“ (организована через youtube, допустим) и материалам тренинга, только оплативших и принимать от них домашние задание(их авторский труд). Казалось бы банальный проект, можно решить с помощью WP. Только в случае просчета в безопасности и утечки авторского труда(коммерческой информации и переписки) — я могу потерять круглую сумму, как и мои клиенты, и Вы, как исполнитель, не сможете свалить всю вину на разработчиков компонентов и авторов WP(любой другой компонент) — так как это опенсорс и они не несут ответственности, что в случае нарушения работы CMS и его компонентов, я не потеряю информацию(мой авторский труд) или клиентов. К тому же Вы как исполнитель, несете ответственность и даете гарантии за работу этих самых компонентов. И при наличии договора и грамотной проверки утечки данных — Вы понесете ответственность и не какое сваливание вины на других, тут не пройдет. А это уже репутационные риски»
Вот такая штука бизнес. Я как заказчик, должен рассчитывать на компетентность исполнителя. И когда я консультирую людей и при фразе: «Мне тут предложили сделать корпоративный сайт на WordPress или Joomla — за недорого», меня аж в пот бросает. Благо, если это просто сайт визитка — тут кстати, даже CMS не надо.
Подведу итог своего мнения про «blogCMS»: «WordPress — довольно крупный и сложный продукт, со своими плюсами и минусами. К сожалению, в дефолтной конфигурации его безопасность находится под большим вопросом, так как даже обычный скрипткидис при наличии прямых рук и интернетов сможет пробить защиту. WordPress, Joomla и другие подобные CMS — создавались для людей не сильно понимающих в программировании, чтобы они могли спокойно развернуть свой блог, новостной сайт, „портал“ и скажем разместить пару модулей из коробки. И не надо CMS для блога и новостного сайта полноценно использовать в коммерческой разработке — не для этого они сделаны были».
Приведу пример-ситуация, возможно выжатый их пальца:
«Я директор психологического центра (очень модно сейчас), заказываю корпоративный сайт у конторы: главный критерий в сайте это возможность принимать оплату за мои авторские тренинги и допускать к „вебинар-комнате“ (организована через youtube, допустим) и материалам тренинга, только оплативших и принимать от них домашние задание(их авторский труд). Казалось бы банальный проект, можно решить с помощью WP. Только в случае просчета в безопасности и утечки авторского труда(коммерческой информации и переписки) — я могу потерять круглую сумму, как и мои клиенты, и Вы, как исполнитель, не сможете свалить всю вину на разработчиков компонентов и авторов WP(любой другой компонент) — так как это опенсорс и они не несут ответственности, что в случае нарушения работы CMS и его компонентов, я не потеряю информацию(мой авторский труд) или клиентов. К тому же Вы как исполнитель, несете ответственность и даете гарантии за работу этих самых компонентов. И при наличии договора и грамотной проверки утечки данных — Вы понесете ответственность и не какое сваливание вины на других, тут не пройдет. А это уже репутационные риски»
Вот такая штука бизнес. Я как заказчик, должен рассчитывать на компетентность исполнителя. И когда я консультирую людей и при фразе: «Мне тут предложили сделать корпоративный сайт на WordPress или Joomla — за недорого», меня аж в пот бросает. Благо, если это просто сайт визитка — тут кстати, даже CMS не надо.
Подведу итог своего мнения про «blogCMS»: «WordPress — довольно крупный и сложный продукт, со своими плюсами и минусами. К сожалению, в дефолтной конфигурации его безопасность находится под большим вопросом, так как даже обычный скрипткидис при наличии прямых рук и интернетов сможет пробить защиту. WordPress, Joomla и другие подобные CMS — создавались для людей не сильно понимающих в программировании, чтобы они могли спокойно развернуть свой блог, новостной сайт, „портал“ и скажем разместить пару модулей из коробки. И не надо CMS для блога и новостного сайта полноценно использовать в коммерческой разработке — не для этого они сделаны были».
Вот именно, что пример взятый из пальца. На практике к вам обращается такой вот инфобизнесмен — вы ему просчитываете ему построение такой системы с нуля (нельзя же верить стороним компонентам). После озвучиваете сроки и цену — и видите его спину. Это если человек воспитанный. Иначе еще и многое о себе узнаете.
Потому что в «Бизнес Молодости» их учат, что «тяп-дяп и в продакшен» это самый правильный путь. И это касается не только сайтов, но и самой тренинговой программы или инфо материалов, которые они продают.
Различного рода утечки их тоже мало беспокоят — эти люди готовы обмениваться конфедициальными данными вКонтактике в чате на 10-20 человек. Все же свои — че тут…
А если разработчик берет на себя такие ответственности за утечку — это полное свидетельство отсутствия у него ума и опыта. Потому что какую-бы сверхнадежную защиту вы не сделали — всегда найдется клиент, который поменяет пароль на «qazwsxedc» — потому что ему так проще. Или же хостер некорректно настроит права и до вашего сайта доберется какой-нибудь бэкдор с соседнего аккаунта.
И как по мне — проще поддерживать сайт на Wordpress или другой известной и популярной CMS. Так как большинство вопросов уже имеют ответы. А вот как попадется CMS венгерского разработчика, которого год назад сбила машина — то тут только дебагер. Потому что в проекте три практически одинаковых класса отвечающих за отправку почты. Одни настройки почты лежат в конфиг файле, а еще одна копия настроек в базе данных. И они разные. А почта с сайта не уходит. И попробуй тут разберись.
Потому что в «Бизнес Молодости» их учат, что «тяп-дяп и в продакшен» это самый правильный путь. И это касается не только сайтов, но и самой тренинговой программы или инфо материалов, которые они продают.
Различного рода утечки их тоже мало беспокоят — эти люди готовы обмениваться конфедициальными данными вКонтактике в чате на 10-20 человек. Все же свои — че тут…
А если разработчик берет на себя такие ответственности за утечку — это полное свидетельство отсутствия у него ума и опыта. Потому что какую-бы сверхнадежную защиту вы не сделали — всегда найдется клиент, который поменяет пароль на «qazwsxedc» — потому что ему так проще. Или же хостер некорректно настроит права и до вашего сайта доберется какой-нибудь бэкдор с соседнего аккаунта.
И как по мне — проще поддерживать сайт на Wordpress или другой известной и популярной CMS. Так как большинство вопросов уже имеют ответы. А вот как попадется CMS венгерского разработчика, которого год назад сбила машина — то тут только дебагер. Потому что в проекте три практически одинаковых класса отвечающих за отправку почты. Одни настройки почты лежат в конфиг файле, а еще одна копия настроек в базе данных. И они разные. А почта с сайта не уходит. И попробуй тут разберись.
С нонеймЦМС тут как повезет.
Сейчас работаем с одной такой. Всё ужасно, но понятно и разбираемо.
Проект был заброшен 5 лет назад, говнокод на уровне ВП, только нонейм, а значит дыряв и крив как первые версии ВП, только еще не дописанные. Но читабельно. Первые правки клиенту сделали с попутным небольшим рефакторингом. Дальше продали клиенту «смену дизайна», заменив на фронтэнде всё что осталось от старой ЦМС на свой код. От старого проекта осталась только админка. Подперли костылями вход, чуть подчистили — работает как новенькая.
На следующем этапе вместе с SEO сделаем очередную бесплатную миграцию и будет у них всё по феншую.
Но я это к чему — код там жуткий, но читабельный, структура древняя но понятная. Можно работать.
А бывает такое, что даже переписать о живому невозможно, не то что поддерживать с плавной миграцией — только писать рядом новое и миграцию базы. С базами тоже конфетки бывают. Я когда лезу в нонейм в первую очередь лезу на базу посмотреть. Если база имеет разумную структуру, то прекрасно, жить можно.
Сейчас работаем с одной такой. Всё ужасно, но понятно и разбираемо.
Проект был заброшен 5 лет назад, говнокод на уровне ВП, только нонейм, а значит дыряв и крив как первые версии ВП, только еще не дописанные. Но читабельно. Первые правки клиенту сделали с попутным небольшим рефакторингом. Дальше продали клиенту «смену дизайна», заменив на фронтэнде всё что осталось от старой ЦМС на свой код. От старого проекта осталась только админка. Подперли костылями вход, чуть подчистили — работает как новенькая.
На следующем этапе вместе с SEO сделаем очередную бесплатную миграцию и будет у них всё по феншую.
Но я это к чему — код там жуткий, но читабельный, структура древняя но понятная. Можно работать.
А бывает такое, что даже переписать о живому невозможно, не то что поддерживать с плавной миграцией — только писать рядом новое и миграцию базы. С базами тоже конфетки бывают. Я когда лезу в нонейм в первую очередь лезу на базу посмотреть. Если база имеет разумную структуру, то прекрасно, жить можно.
Вот именно, что пример взятый из пальца. На практике к вам обращается такой вот инфобизнесмен — вы ему просчитываете ему построение такой системы с нуля (нельзя же верить стороним компонентам). После озвучиваете сроки и цену — и видите его спину. Это если человек воспитанный. Иначе еще и многое о себе узнаете.
Я говорил гипотетически, т.к. не сталкиваюсь с такими проблемами, потому что все заранее продумываю. Если человеку не нравится цена моего времени, я его держать не стану — я себя уважаю, я придерживаюсь принципа: «Не держись за клиентов, пусть они держаться за тебя». Если бы я «лажево» работал: я думаю очереди из клиентов у меня не было бы и они бы не приходили бы снова и снова.
Я привык работать с умными людьми, которые ценят свое время и деньги. Если человеку не нравиться что-то, я отправляю его искать других, но предупреждаю о последствиях экономии — через некоторое время он возвращается и цена больше в разы, т.к. исправлять что-то сложнее, чем создать новое. «Скупой платит дважды»
Ещё один из принципов взаимодействия с будущими клиентами, который мне очень нравиться: «Быстро, качественно, недорого — выберите два».
А если разработчик берет на себя такие ответственности за утечку — это полное свидетельство отсутствия у него ума и опыта. Потому что какую-бы сверхнадежную защиту вы не сделали — всегда найдется клиент, который поменяет пароль на «qazwsxedc» — потому что ему так проще. Или же хостер некорректно настроит права и до вашего сайта доберется какой-нибудь бэкдор с соседнего аккаунта.
Опять улыбаюсь ;) Вы старше меня и должны понимать о чем я говорил: «Если пользователь ...» — ответственность пользователя. «Если хостер ...» — ответственность хостера, Хостинг(в Вашем понимании) как таковой, наверное, изжил себя — предпочитаю VDS, CloudFlare, Nginx+php-fpm, Nginx+Apache — в зависимости от проекта и требований. Я говорил об ответственности исполнителя за код или подбор компонентов. Любое грамотное расследование происшествия — выявит причину. Так вот, чтобы это все провести нужно иметь грамотную систему логов. И люди забывают не только о них, но и о ведении бэкапов. Больше улыбаюсь с людей, которые делают это руками — предпочитаю автоматический бэкап в два разных места хранения, потому что человек может заболеть или забывать, машина такого не допустит. Ещё людям рекомендую проверять hash-суммы файлов проекта сделанные перед продакшеном и по факту бэкапов — разумеется только не вручную, с оповещением об изменениях.
И как по мне — проще поддерживать сайт на Wordpress или другой известной и популярной CMS. Так как большинство вопросов уже имеют ответы. А вот как попадется CMS венгерского разработчика, которого год назад сбила машина — то тут только дебагер. Потому что в проекте три практически одинаковых класса отвечающих за отправку почты. Одни настройки почты лежат в конфиг файле, а еще одна копия настроек в базе данных. И они разные. А почта с сайта не уходит. И попробуй тут разберись.
Проще на значит лучше и не значит правильней и безопастней. К любой CMS можно прикрутить UI-адаптированную панель. Если вы обслуживаете школьный сайт на WP — без проблем — там только формочки, странички и новости нужны, Ваше право. Но интернет-магазин на WP — это бред. Многие согласятся, что WP — это ведро дырками, в плане безопасности. Любую проблему надо решать с логов. И добро пожаловать в мой мир — человек взявший «венгерскую CMS», не подумал о последствиях — вот и результат. И мы кстати в данном контексте говорим о разработке и качестве, и безопасности, а не легкости обслуживание.
Левые плагины? XSRF есть в двух третях из ПОПУЛЯРНЫХ плагинов в каталоге плагинов. В топе и т.п.
Читать сотни килобайт кода? Дак а нафик оно надо мне вообще если я всё должен вычитывать?
Безопасность вордпресса это безопасность неуловимого Джо. Самые жирные атаки можно более-менее закрыть, бекдоры позатыкать и т.п., но в целом статус системы остается «уязвима, но на взлом нужны усилия».
Не поймите меня привратно. ВП имеет право на жизнь. У него есть своя ниша. И у меня тоже есть проекты на ВП на поддержке. Правда они поместятся на пальцах левой руки, но есть. Я просто не могу пропустить этого ребяческого «просто не ставьте непроверенное» — оно всё дырявое как ведро. Всё. И просто не ставить опасное это не ставить ВП вообще. :)
Читать сотни килобайт кода? Дак а нафик оно надо мне вообще если я всё должен вычитывать?
Безопасность вордпресса это безопасность неуловимого Джо. Самые жирные атаки можно более-менее закрыть, бекдоры позатыкать и т.п., но в целом статус системы остается «уязвима, но на взлом нужны усилия».
Не поймите меня привратно. ВП имеет право на жизнь. У него есть своя ниша. И у меня тоже есть проекты на ВП на поддержке. Правда они поместятся на пальцах левой руки, но есть. Я просто не могу пропустить этого ребяческого «просто не ставьте непроверенное» — оно всё дырявое как ведро. Всё. И просто не ставить опасное это не ставить ВП вообще. :)
Залить свою тему можно только с платным аккаунтом?
И кстати на хабре нельзя множественный выбор сделать? Так как вопрос «Какие CMS системы используете вы?» всё же предпологает множественный выбор.
В выборе на чем разрабатывать проект основную роль, на мой взгляд, является поставленная перед вами задача.
Если вам требуется создать сайт-визитку, интернет-магазин или блог — тогда лучше использовать какое-нибудь готовое решение.
А если требуется именно функционал (учет заявок, печать квитанций, отчеты и т.д.) — лучше конечно же фреймворк.
Если вам требуется создать сайт-визитку, интернет-магазин или блог — тогда лучше использовать какое-нибудь готовое решение.
А если требуется именно функционал (учет заявок, печать квитанций, отчеты и т.д.) — лучше конечно же фреймворк.
нет, серьезно?
>Хабр
>Восторженно-пустая статья о вордпрессе уровня «создаем первый сайт за 24часа!11»
>Все довольны.
при том что недавно чувака, аргументированно написавшем о битриксе, слили по самое не балуйся.
>Хабр
>Восторженно-пустая статья о вордпрессе уровня «создаем первый сайт за 24часа!11»
>Все довольны.
при том что недавно чувака, аргументированно написавшем о битриксе, слили по самое не балуйся.
Сейчас меня тоже заминусуют, по поддерживаю. В статье про битрикс с ужасом смотрел на примеры кода и радовался что не приходилось заниматься битриксом. С вордпрессом сталкивался редко, но ощущения от увиденного кода тоже не лучшие. Это блогплатформа, и именно в такой роли я о ней узнал много лет назад.
Действительно! Зачем забивать гвозди молотком, если есть пассатижи? *оглушительный фейспалм* Вордпресс — это блогодвижок!!!111адынадын Я уже бессменно лет семь ржу с людей, которые делают интернет-магазины на WordPress. Поддерживать такие проекты — это лютый звездец! Единственный движок, который я могу назвать ОТНОСИТЕЛЬНО универсальным — это MODX. Остальное — под конкретные категории проектов.
Горите в аду, чертовы сеошники. В заголовок вынесен вопрос: " Зачем разрабатывать сайт с нуля, если есть WordPress?". Будьте добры в тексте на него отвечать. То же самое касается раздела «Почему именно WordPress?».
Wordpress хорош для быстрого старта небольшого проекта. Когда не накручиваешь серьезный функционал, а ограничиваешься стандартным набором функций и плагинов. Если сооружать что-то серьезное, то зачастую это проблемы с ресурсами.
Безусловно, проекта типа магазинов МОЖНО делать на WP, но надо знать все тонкости и всерьез заниматься оптимизацией. Подстроить под себя сайт на WP не проблема — сообщество разработчиков действительно огромно.
Безусловно, проекта типа магазинов МОЖНО делать на WP, но надо знать все тонкости и всерьез заниматься оптимизацией. Подстроить под себя сайт на WP не проблема — сообщество разработчиков действительно огромно.
2016 год, а кто-то ещё всерьёз рассуждает о велосипедах для бложика.
Кто нибудь может оспорить утверждение, что для блога CMS лучше WP нет?
Для блога лучше вообще без ЦМС обходиться а жить в каких-то сервисах.
Проще в обслуживании, а домен свой прикрутить тоже можно.
Проще в обслуживании, а домен свой прикрутить тоже можно.
Смотря для кого. Я по сей день веду бложик, сделанный на MODX Revolution. Устраивает всё. Честно. По части блогов здесь уже вопрос вкуса. Вот если бы WP использовали только для блогов. А его же используют для всего, чего угодно. В результате это оборачивается дичайшим звездецом и колхозностью всея Рунета.
MODX Revo — универсальная CMS. Используют smatry для шаблонов в отличии от WP, можно прикрутить любой html-шаблон.
Что, простите, использует MODX Revo? Smarty? =))))
эм… а что мешает в «любой хтмл шаблон» вставить не смарти а вордпрессовые теги? Религия?
Мое мнение: php-шаблоны изжили себя, я предпочел бы twig, вместо smarty. Да и натягивание шаблона в modx проще и быстрее, чем в WP — особых знаний не требует.
И наверное modx — это больше CMF, чем CMS.
И наверное modx — это больше CMF, чем CMS.
Вот гоняют друзья блог на Wordpress, и вот буквально недавно его взломали и сломали. Вообще перестал взлетать. В файлах какой-то обфусцированный шлак. Я удалял всё, что туда попало в определённую дату (когда этот взлом произвели) и поверх распаковал обновление из архива. Захожу в админку, а там куча левых учёток наделали с правами админа. Приходится это всё чистить, удалять лишние плагины, которых никогда я не ставил, обновлять до более свежей версии и сбрасывать пароли всем остальным. Свой сайт я предпочёл сделать самому, и с лентой новостей, и с простой админкой для заполнения и правки новостей. Но вот для форума применил phpBB, и вики на MediaWiki, чтобы документацию писать. Параллельно экспериментирую с DokuWiki для подобных дел, чтобы сравнить с MediaWiki в плане надёжности и удобства.
Я против Wordpress из-за безопасности, очень много дыр, особенно в старых версиях. Взломать могут вообще в любой момент, и даже "мяу" сказать не успеешь.
В любом случае использовать CMS нужно разумно, и под конкретные задачи, а не просто клепать сайты-визитки на их основе. Инче можно просто перегрузить сервер, либо оставить песочницу для взломщиков, желающих втихаря повесить какой-нибудь вирус (или криптомайнер).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дешево и сердито или Зачем разрабатывать сайт с нуля, если есть WordPress?