Wordpress, Самописный сайт
Как смотрится такой сайт:
Wordpress как сайт визитка, ну и что-нибудь по мелочи там.
А основное делать на самописном сайте.
Можно так сделать, что пользователь и не заметит, где он находится, не заметит что перешел с Wordpress на самописный сайт или наоборот.
Я забыл обрисовать ситуацию.
Существует сайт на Wordpress. Это нормально для простеньких задач. Так и пошло вначале. Но увлеклись и стали пихать туда те задачи, которые в принципе можно выполнить, но требуют очень много времени и всё неустойчиво. Кроме того, появились пользователи, небольшая посещаемость. Я вижу выход один – надо постепенно переводить некоторые задачи на самописный сайт, пока не останется лишь одна страница на Wordpressе, где можно зарегистрироваться и ввойти. Нет проблем сделать страницы самописного сайта, похожими на страницу на Wordpressе. Можно было бы и всё начать с нуля, но не хочется так резко, кроме того хотелось бы, чтобы и Wordpress в деле был, ведь легко простенькую задачу сделать, мне очень нравится использовать шорткоды.
ПС
Что-то я так долго пишу и кажется и вопроса уже нет, похоже больше на мысли вслух. Но в любом случае подыму проблему, нельзя связываться с движками или по крайней мере вначале нужно делать самописный сайт, потом уж можно кое-что загрузить и на Wordpress. Иначе может затянуть зараза по времени.
зачем изобретать велосипед, есть куча движков и шаблонов, самописный сайт это дело долгое, вылавливать ошибки, безопасность и т
Не скажу про безопасность, я не в теме.
А вот про ошибки даже и сравнивать нельзя, на самописном это делается легко по сравнению с движками, это и логично.
Движки и шаблоны только за то нельзя любить, что их надо изучать, то есть на них надо тратить время, не на программирование, а на то, что же там дяди сделами, и можно ли к этому приноровиться. Иногда приходится свое делать, заталкивать программу на HTML. Например, я долгое время не смог приноровиться к постраничной навигации Wordpress, ну не устраивает, пришлось сделать полностью свою, да и другие вещи.
А можно что-то подобное сделать на самописной странице?
Если на HTML, то наверное нельзя. Придётся делать на PHP.
Получается как в старом анекдоте про Вовочку и его папу
"... можно то оно можно...
... но на х... оно там нужно? "
А по теме скажу.
в принципе с помощью PHP и MySQL можно сделать любое подсоединение к системе и базе данных.
В итоге можно сделать что угодно.
Но как это уже выше упомянули, в WP есть уже куча всяких расширений и дополнений,
которые нужно просто подключить и настроить.
Поверьте мне на слово, это будет в любом случае проще, быстрее и надёжнее
чем самописные заборы.
Иногда бывают конечно "нестандартные" запросы клиентов и они хотят чего-то непонятного,
то в этом случае делают самописные модули, но это обычно танец с бубном,
тем-более, если всё это должно ещё и надёжно и стабильно работать.
А вот про ошибки даже и сравнивать нельзя, на самописном это делается легко по сравнению с движками, это и логично.
и
Не скажу про безопасность, я не в теме.
Читаем эти две цитаты из Вашего поста и многое становится ясным.
Вы работаете по старинке. Код пишется по мере необходимости и поступления поставленных задачь.
В современных же CMS или других программах идёт раздельное программирование оптики и логики.
По началу это немного непривычно, но если вклиниться в тему,
то получается всё логично и удобно.
ну не устраивает, пришлось сделать полностью свою, да и другие вещи.
Я недавно разговаривал с одной коллегой, хорошей программисткой,
Ей нужно было просто поменять порядок пунктов в навигации и дописать парочку строк в CSS.
вместо того, что-бы сделать это через системные возможности,
она пыталась переделать
шаблон в Joomla. (с Joomla она плохо знакома).
В итоге потеряла как минимум пол дня.
Системными средствами это заняло бы минут 10.
Нужно только знать где и как это делается.
НП
Адаптивный дизайн
Какойт тип HTML-макета выбрать?
Без сомнения выбираю: Отзывчивые макет (responsive)
% + media-queries
Макет базируется на использовании медиа запросов css (css media queries) — так контент адаптируется под разные экраны.
Т.е. несколько контрольных точек задают фиксированное положение и размеры контента на разных экранах.
Это понятно. Но меня интересует вариант расположения контрольных точек для адаптивной верстки макета:
Я использую:
max-width: 580px; min-width: 580px; min-width: 800px; min-width: 1100px; min-width: 1600px
Как-то сложилось так, не знаю хорошо ли это или плохо.
Кто подскажет?
Иногда бывают конечно "нестандартные" запросы клиентов и они хотят чего-то непонятного, то в этом случае делают самописные модули, но это обычно танец с бубном, тем-более, если всё это должно ещё и надёжно и стабильно работать.
Хороший термин: "самописные модули", буду в дальнейшем использовать.
Сайт, про который я веду речь, должен представлять собой сайт-визитку на Wordpress и десяток самописных модулей.
Пока эти самописные модули, выполненные на HTML, торчат в сайте Wordpress. Как бы они сами по себе. Даже файлы .css; .js и то свои.
Почему я это делал, так как я не находил решения, как выполнить средствами Wordpress. Можно конечно было делать плагины под задачи, но это не выход.
Вполне допускаю, что я не понимаю движки или не хочу понять, какое-то невосприятие их, ну не мое это. Решил лишь попробовать на скорую руку, ну и затянуло до сих пор.
max-width: 580px; min-width: 580px; min-width: 800px; min-width: 1100px; min-width: 1600px
Сложно сказать хорошо это или плохо не зная ничего о структуре и качестве кода.
Но если это всё написано для одного и того же элемента, то это скорей всего много лишнего.
Я обычно (и вообще так рекомендуется), сначала сделать версию для мобильника,
а потом добавлять точки для более широких мониторов.
В результате нет необходимости или она очень мала создавать max и min границы.
В итоге, до определённых границ элементы ведут себя плавно,
а потом переходят в другое состояние, где они снова до определённой границы находятся в плавном перемещении.
В зависимости от дизайна сайта, эти точки могут быть различными и их количество тоже не постоянно.
их надо изучать, то есть на них надо тратить время, не на программирование
------
Угу... Правда на программирование тоже надо тратить время...
Еще надо тратить время на поддержку.
Далеко не факт, что поддержка чего-то самописного будет проще.
Только что убил две недели на два изменения в самописных репортах - все не сложно, но сначала попросили поменять, потом вернуть, затем - иметь оба варианта... при этом система отображения и система обсчета - одинаковые - разница в одном скл-запросе...
Я обычно (и вообще так рекомендуется), сначала сделать версию для мобильника, а потом добавлять точки для более широких мониторов.
Да, так рекомендуется. И я следовал этому. Но как луше это осуществить, до сих пор не знаю.
Я делал это примитивно: три колонки. Одна основная, вторая тоже основная, но она разместится под первой при переходе на мобильник, ну а третья предназначеная для широких мониторов с не основной информацией при переходе на мобильник исчезает. Это легко делать, но не очень это мне нравится. В идеале я представляю одну лишь колонку на весь любой ширины кран, заполненную под завязку информацией, которую можно увидеть на широком экране. Потом по мере перехода на разные мониторы и мобильники дивы информаций как кубики перестраиваются, а некоторые не основные просто исчезают. Но здесь много работы.
Интересно кто как убирает неосновную информацию, ну не грузить же всю на мобильник.
Но здесь много работы.
Если изначально хорошо продумать дизайн и структуру, то всё очень просто.
Работы не больше, а значительно меньше чем если делать отдельно и мобильную и десктопную версию (как это раньше делалось).
Интересно кто как убирает неосновную информацию, ну не грузить же всю на мобильник.
Именно для этих целей и создаётся сначала мобильная версия,
где грузится всё необхоодимое.
А потом, по мере расширения экрана можно доподключать отключённые (незагружаемые на мобильной версии) элементы.
Интересно кто как убирает неосновную информацию
Есть много вариантов, всё зависит от поставленной задачи и реакции на это "выключение" со стороны поисковиков.
Я пользуюсь обычно
"
position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
"
Потом, когда нужно включить, то позицию поменять на relative и задать размеры.
Вот здесь немного описано:
http://qaru.site/questions/651510/how-to-hide-any-element-...
А можно же убрать див с неосновной информацией, сделав его маленьким ( можно даже и по нулям размеры) и сделать невидимым.
Или отправить див за пределы экрана в левый верхний угол – 4999px – 4999px
Сам до этого дошел. Как-то пришло на ум, а не отправить ли див за пределы экрана.
Нормально получилось. Я думал, что это не грамотно, а потом как-то встретил этот совет в одной книге.
НП
Визуальный редактор
TinyMCE и CKEditor. Что выбрать? Или другой визуальный редактор нужен? Мне лично это не нужно или любой сойдет.
Что выбрать для простых пользователей форума, какой редактор будет им удобней. Я не знаю, дойдет ли у меня дело до форума, но уже интересуюсь.
Не будет форума, так для других целей пригодится для пользователей.
Кстати, у нас на сайте какой редактор используется, где есть подобные?
Нормально получилось. Я думал, что это не грамотно, а потом как-то встретил этот совет в одной книге.
Сделать можно всё что угодно и оно будет работать.
Проблема может возникнуть позже, когда поисковики именно из-за подобных фокусов начнут банить.
Раньше, ещё лет 10 назад, можно было впихнуть полностью словарь или тысячи нужных слов в такой див и спрятать его.
Сейчас за подобные элементы можно потерять любые позиции в поисковиках.
В той статье, которую я привёл выше, немного описано какой эффект от каких способов скрытия будет.
Способ, который я привёл в примере, он (на данный момент) нормально воспринимается поисковиками.
И на счёт книг.
Все книги по веб дизайну и SEO, которые старше четырёх лет, можно не задумываясь выкинуть.
То же самое касается и статей в сети.
Тут даже нужно обращать внимание на актуальность с точностью до месяца.
Есть конечно элементы, которые не поменяли своих свойств,
но есть и такое, что может больше навредить,
но тут уже нужно быть в теме постоянно чтобы это определить.
Визуальный редактор TinyMCE и CKEditor. Что выбрать?
Выбираю визуальный редактор TinyMCE, так как он установлен на Wordpress.
Пусть тогда и для самописных модулей будет этот редактор.
Присматриваюсь к нему, кажется понятный, но ещё не пробовал.
Но сразу возник вопрос как задать размеры TinyMCE для отзывчивого макета?
Есть ли стандартное решение?, а то я полезу функцию сочинять )))
Так я и не смог применить CSS-правила внутри редактора TinyMCE
В настройках TinyMCE (т.е. в настроечном массиве tinyMCE.init) добавлял опцию:
...
content_css: "/css/tinymce.css",
...
Но в нем нельзя задать ширину, высоту, отступы от краев итд. Нельзя использовать медиазапросы.
А то что можно задать, мне не нужно.
Должно быть решение как применить CSS-правила внутри редактора TinyMCE, но вот пока не нахожу. Искал в интернете инфу – не нашёл.