После выхода WP5 с его «Гуттенбергом», я решил немного освежить старую информацию о том, как сейчас обстоят дела со свойством contenteditable. Кто не в курсе, то это такое свойство любого html-тэга, которое заставляет браузер включить режим редактирования.

Года три назад эта тема была достаточно популярна, но в целом заглохла из-за того, что браузеры по разному генерируют html-код и расчищать их «завалы» оказалось проблематично. Поэтому остались только те проекты, которые «переспециализировались» в визуальные редакторы.

Как оказалось, сейчас ситуация немного улучшилась. Не идеально, конечно, но в целом прогресс оказался значительным. И я решил реализовать в шаблоне MF возможность редактирования записи прямо на странице записи.

Читать ➝

Главная сложность с подвалом, как оказалось — это многообразие блоков и их настроек. По задумке подвалов может быть много (десятки). Изначально я планировал их сделать в виде компонентов, что в итоге приводит к некоторой путанице в админке. Кроме того, каждый такой компонент должен иметь свои настройки: даже элементарное — название сайта и какие-то ссылки. Тут ещё нюанс в том, что блоки подвала как правило, имеют одну html-разметку в виде flex-колонок: меняется только содержимое внутренних ячеек. Я тогда подумал остановится на универсальном решении, что-то вроде footer-cols1 из Default-шаблона. Но такой компонент настраивается через опции, и если их немного, то проблем нет, но что делать, если я захочу предложить 10 блоков? Настраивать все поля опций — ещё то занятие...

Сама по себе проблема очень старая и относится не только к MaxSite CMS, но и другим «движкам». Нужен какой-то оптимальный вариант, который с одной стороны скроет сложную html/php/css-верстку от обычного пользователя, но при этом оставит ему всё многообразие настроек.

Читать ➝

При всех своих плюсах, Open Server Panel имеет один существенный недостаток — невозможность обновления. Это обусловлено в первую очередь тем, что сама программа Open Server Panel (далее по тексту OSP), является неким менеджером конфигураций для различных модулей. Когда нужно запустить PHP 5.5, то OS вначале скопирует нужную конфигурацию, а после запустит PHP. Если нужна PHP 7.1, то вначале подготовится конфигурация, после опять запуск.

Таким образом здесь довольно сложно придумать обновление в привычном понимании, поскольку обновляться должны именно модули, а сама OSP, по идее, должна только менять файлы конфигурации. В любом случае этот вопрос немного выходит за рамки этой статьи.

Для нас, вебмастеров, главная сложность в том, что возникает проблема тестирования сайтов под разные новые версии модулей. В первую очередь, речь идёт об PHP. Можно, конечно, вручную попробовать настроить OSP под новую версию PHP, но есть более простой способ.

Читать ➝

Я продолжаю принимать предзаказы на будущий шаблон «MF». Сейчас его можно получить по хорошей скидке, после релиза цена будет выше. Сам шаблон включает в себя годовое обновление (в отличие от других шаблонов).

Сейчас хочу немного рассказать о ходе работ по шаблону, чтобы было понятно что будет в итоге. Только учитывайте, что это рабочий вариант, в итоговом что-то может поменяться. Сам по себе шаблон достаточно сложный, но при этом универсальный, поскольку будет содержать несколько компонентов шапки и подвала, лендинговые блоки, шаблоны вывода и т.п. То есть он подходит как для обычного блога, так и для какого-то тематичного сайта.

Теперь кратко о том, что уже сделано. (Дальше много картинок.)

Читать ➝

Интересное видео опубликовал Вадим Макеев «Прототип изоляции стилей для Shower на веб-компонентах», где затрагивается вопрос изоляции css-стилей при верстке. Само видео посвящено одной из попыток реализации, но сама по себе тема (изоляции) мне кажется интересна, поскольку с ней сталкиваются практически каждый верстальщик.

В чём суть проблемы? CSS-стили имеют глобальную обрасть видимости. Не важно где объявлен стиль, он будет применён сразу ко всей html-странице. Пока html-код небольшой, особых проблем не возникает, поскольку элементарно решается за счёт именования css-классов. Но, как только html становится побольше, то именование классов должно быть более осмысленным, иначе разобраться в коде будет проблематично.

Читать ➝

Расскажу про свой способ управления делами. Шёл я к нему много лет методом проб и ошибок. Главная сложность, с которой я постоянно сталкивался — это слишком сложное управление todo-программами. В какой-то момент я понял, что почти все существующие программы требуют слишком много времени на их же обслуживание. Например иерархия задач, указание приоритета, важности, даты и т.п. Это всё, безусловно, замечательно, особенно для тех, кто «хронически» не умеет организовывать своё время, но лично для меня такие вещи бесполезны.

Со временем у меня сформировался очень простой список правил, которые позволяют организовать свои дела. И при этом без какой-либо привязки к конкретной программе. :-)

Читать ➝