Александр Токарев: Эгея
5 заметок с тегом

Эгея

Эгея и PHP

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

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

Но я, однако, не программер, и в PHP я не разбираюсь. Подскажите, плиз, кто разбирается, как сделать так, чтобы при наборе в адресной строке

https://mysite.ru/section1/

сервер выдавал пользователю страницу с витриной тематических материалов (допустим, section1.php), которая лежит у меня на сервере в виде файла и которую я могу редактировать?

P. S. Почему не сделать тематические страницы в виде .html? Потому что во-первых, хочу добавить туда штатный эгейский php-контент из шаблонов (верхний-нижний колонтитул и пр.), а во-вторых, чтобы расширение страниц в адресной строке не отображалось — ни html, ни php.

2019   Эгея

Эгея и HTML #2

Пару недель назад я писал о досадной проблеме при вставке HTML-кода в Эгею. Суть её в том, что эгейский редактор принудительно добавляет в ваш HTML дополнительные абзацные теги <p> и </p>. Если вёрстка простая, это может быть незаметно, но если она чуть посложнее, да ещё и адаптивная, то в результате этих непрошенных правок она может прийти в полную негодность.

Поскольку варианты, предложенные в комментах, задачу не решили (тем не менее, большое спасибо авторам за них!), а поддержки нет, сегодня я специально инвестировал пару часов времени в эксперименты с эгейским редактором, пытаясь с помощью брутфорсного перебора вычислить, в каких конкретно случаях он вставляет свои [censored] абзацные теги, а в каких нет.

Так вот, похоже, мне удалось найти правильный ответ. Эгейскому редактору зачем-то нужно, чтобы каждый ваш тег <img> (т. е. картинка, которую вы вставляете не через drag-n-drop, а в виде ссылки на файл), непременно был завёрнут в теги <p> и </p>. Другие теги, а также символы перевода строки и пробелы его не волнуют. Поэтому если вы вставляете в эгейский редактор

<img href="picture.jpg">

и нажимаете кнопку «Сохранить», то на выходе, в коде страницы, вы получите вот это:

<p>…<img href="picture.jpg">…</p>

Примечательно, что эти добавочные <p> и </p> иногда могут оказаться довольно далеко от вашей картинки. Почему — не знаю, но думаю, что это зависит от синтаксиса вставляемого HTML-кода.

А теперь, Фёдор, о главном. Чтобы обойти эту [censored] редактуру, нужно подсунуть эгейскому редактору то, что он просит. То есть, заранее обернуть каждый ваш <img> в теги <p> и </p>.

В чём же тогда разница, спросите вы? Чем это решение отличается от расклада по умолчанию, при котором эгейский редактор самостоятельно делает то же самое? Отвечаю: разница в том, что когда вы сами оборачиваете ваши <img> в теги <p> и </p>, вы можете поместить их в достаточно произвольном месте, например, вынести их за пределы <div>-контейнера — туда, где лишние абзацные отступы не навредят адаптивной вёрстке:

<p>…<div><img href="picture.jpg"></div>…</p>

К такому коду у эгейского редактора уже не возникает никаких претензий, соответственно, ваш код будет оставлен в неприкосновенности.

Итого

1) Эгейскому редактору требуется, чтобы каждый ваш <img> был завёрнут в теги <p> и </p>.

2) При этом не обязательно, чтобы теги <p> и </p> находились вплотную к <img> : они могут быть размещены достаточно далеко.

3) Чтобы скомпенсировать избыток высоты, вызванный добавлением лишнего элемента <p>, можно снабдить его стилем с отрицательным нижним полем, равным высоте одной строки:

<p style="margin-bottom: -1em;">…</p>


UPD 20.12.2019: Как выяснилось в ходе дальнейшего тестирования, редактор оборачивает в абзацные теги не только <img>, но и некоторые другие теги (см. комментарии).

UPD 02.01.2019: Написал Бирману. Посмотрим, насколько изложенная проблема представляется значимой и достойной решения самому разработчику.

2019   Эгея

Эгея и HTML

Граждане эгейцы, очень нужна помощь зала. Требуется вставить в произвольное место эгеевской заметки HTML-код. Когда я вставляю его через эгеевский редактор, он оборачивает теги <img> и <a> в абзацные теги <p> и </p>. Это, естественно, добавляет в вёрстку ненужные переводы строки, в результате чего она разваливается. (С вставляемым HTML-кодом всё ок, я проверял его в валидаторе и если его залить в обход эгейского редактора с линком на используемые CSS, он прекрасно работает на всех браузерах.)

В хелпе Эгеи есть упоминание про дополнительные пользовательские блоки на PHP. Однако, насколько я понимаю, такой блок можно добавлять лишь в заранее определённые автором движка места (напр., начало заметки или конец) и, главное, этот блок будет добавлен во все заметки сразу. Мне же требуется добавить HTML лишь в некоторые заметки, причём так, чтобы эгеевский редактор этот HTML никоим образом не модифицировал. Если вы знаете, как это сделать, пишите, буду очень признателен.


UPD: Пример, поясняющий суть проблемы:

Вот фрагмент кода, который я вставляю в текст заметки в окне эгейского редактора:

<div><a href="all/o-vyraschivanii-2"><img src="files/growing-poster-02.jpg"><div><p>#2: Инициация</p><p>Поиски самоназвания, тайна инициации и дальнейшие приключения тайского перца</p></div></a></div>

После нажатия кнопки «Сохранить изменения» я просматриваю код страницы в браузере и вижу это:

<div><P><a href="all/o-vyraschivanii-2"><img src="files/growing-poster-02.jpg"></P>
<div><p>#2: Инициация</p>
<p>Поиски самоназвания, тайна инициации и дальнейшие приключения тайского перца</p>
</div><P></a></P>
</div>

Заглавными буквами P обозначены ненужные <p>-элементы, принудительно вставленные в код эгейским редактором. Добавление этих P и составляет суть проблемы: из-за них адаптивная вёрстка разъезжается и не работает как задумано.

2019   Эгея

Эгея и WebP

В комментах к недавнему посту про сжатие картинок в JPG зашёл разговор о формате-конкуренте — WebP производства Google. Поскольку для меня это формат новый, неизведанный, да к тому же вот коллега-эгеец сетует, что на Эгее WebP не поддерживается и не известно, будет ли, я решил побольше разузнать о всей этой ситуации.

Почитал сеть, поэкспериментировал с Эгеей, делюсь результатами изысканий и размышлений.

WebP жмёт мощнее, чем JPEG

В моём тестировании одна и та же картинка в JPEG весила 700 килобайт, а в WebP — 600 килобайт. Экономия в 15-20%, может, и не космическая, но когда картинок на странице несколько — очень даже заметная: и по скорости загрузки, и по стоимости трафика (второе актуально, если вы — СМИ или медиапортал, к вам ходят сотни тысяч посетителей и вы платите за объём отдаваемого трафика).

WebP не особенно парится о качестве и прочих нюансах

Вот что говорит Корнел Лесиньски, один из разработчиков MozJPEG, отвечая на вопрос, не планируется ли добавить поддержку WebP в программу-компрессор ImageOptim:

«Таких планов нет... Сам этот формат не особенно интересен: менее точное цветовое соответствие, чем у JPEG; не особенно заметная выгода в сжатии по сравнению с оптимизированным JPEG в приемлемом диапазоне качества; нет поддержки прогрессивного (progressive) отображения». (Отсюда.)

Тем не менее, все основные браузеры уже поддерживают формат WebP. Интересно, почему?

WebP не поддерживается Safari

В это одновременно трудно и (зная политику Apple в отношении просьб пользователей) просто поверить. Самое забавное: WebP является абсолютно бесплатным программным продуктом с открытым кодом. То есть, за добавление его поддержки в браузер Safari фирме Apple не пришлось бы заплатить ни цента. Почему же Apple этого не делает? Возможно, вопрос не в том, сколько Apple должна заплатить Google за добавление поддержки WebP в свой браузер, а в том, сколько ребята из Google должны занести в Apple, чтобы эта поддержка там, наконец, появилась.

Что ж, подождём: рынок расставит всё по своим местам. А пока упрямцы из Apple держат бессмысленную оборону, коммерческие сайтостроители не теряют времени и уже сейчас делают две версии картинок: одну, основную, в формате WebP (её видят пользователи всех браузеров, в которых этот формат поддерживается), а другую, резервную, в формате JPG (её видят гордые пользователи Safari). Подумайте: если бы эта возня была невыгодна с финансовой точки зрения, разве они этим занимались бы?

Почему WebP победит

Я склонен думать, что WebP имеет все шансы вытеснить JPG в качестве стандартного формата сохранения фотоизображений для веба. По двум причинам:

• Во-первых, этот формат уже вовсю используется. И отнюдь не одиночками-энтузиастами, а очень крупными и очень зубастыми коммерческими игроками, не привыкшими кидать деньги на ветер. Среди них — социальные сети, медиахолдинги, инфопорталы, интернет-СМИ. Почему они переходят на WebP? Может, потому что картинки в нём красивее выглядят? Неа. Потому что картинки в нём меньше весят. Точка.

• Во-вторых — и тут я попрошу дизайнеров, фотографов и цифровых художников присесть — публику вообще не интересует техническое качество ваших картинок. (Моих, кстати, тоже.) Публику интересует одно: скорость доступа к информационно-развлекательному ресурсу. Чем больше вес картинок на странице, тем ниже скорость доступа. Как говорится, подумайте над этим.

Как только я понял, что мои восхитительно прекрасные хайрезы нафиг никому не нужны, кроме меня самого, моя жизнь как вебмастера значительно упростилась. Тяжеловесные хайрезы я перенёс туда, где им очень рады: в домашний фотоархив, а на веб я выкладываю JPGи настолько малого веса, насколько это возможно без критического (подчёркиваю: критического, а не с трудом уловимого) ухудшения качества.

Как добавить поддержку WebP в Adobe Photoshop?

Элементарно, легально и бесплатно: соответствующий плагин под названием WebPShop, написанный самим Google, давным-давно проживает тут. Для неанглоязычных пользователей перевожу инструкцию и выкладываю файлы с Гитхаба:

Установка WebPShop для Windows:

• Скачайте архив с плагином (вот для Windows x64 а вот для Windows x86) и распакуйте его.
• Скопируйте файл WebPShop.8bi в папку с плагинами Photoshop (обычно это C:\Program Files\Adobe\Adobe Photoshop\Plug-ins).
• Перезапустите Photoshop. В пунктах меню «Открыть» и «Сохранить» теперь должны отображаться файлы в формате WebP.

Установка WebPShop для macOS:

• Скачайте архив с плагином для macOS и распакуйте его.
• Скопируйте файл WebPShop.plugin в папку с плагинами Photoshop (обычно это Applications/Adobe Photoshop/Plug-ins).
• Перезапустите Photoshop. В пунктах меню «Открыть» и «Сохранить» теперь должны отображаться файлы в формате WebP.

Внимание пользователей macOS Catalina! Если после установки плагина выскочит окошко с системными ругательствами (“WebPShop.plugin” cannot be opened because the developer cannot be verified), запустите Терминал и выполните команду:

sudo xattr -r -d com.apple.quarantine /Applications/Adobe\ Photoshop\ 2020/Plug-ins/WebPShop.plugin

Вышеприведённая команда предназначена для Adobe Photoshop 2020. Если вы используете другую версию Фотошопа или папка с плагинами лежит в другом месте, скорректируйте путь.

Сохранение в WebP в Photoshop производится через меню «Save» (Сохранить). Экспорт «Save for Web (Legacy)» не поддерживается.

WebP и Эгея

По состоянию на ноябрь 2019, движок Эгеи не поддерживает работу с WebP. Это означает, что картинки в этом формате нельзя загрузить в окно редактора. Но это не означает, что картинки в формате WebP вообще нельзя использовать в блоге, работающем на Эгее. Ещё как можно! Вот, смотрите:

Если вы пользуетесь любым браузером, кроме Safari, вы увидите файл в формате WebP. (Если не верите, скачайте файл и проверьте его на детекторе лжи). Пользователи Safari увидят на этом месте точно такую же картинку, но в формате MozJPEG.

Как это сделано? С помощью всего-навсего трёх тегов:

<picture>
    <source srcset="/pictures/test@2x.webp" type="image/webp">
    <img src="/pictures/test@2x.jpg" style="width:100%">
</picture>

Суть фокуса: вы заранее сохраняете одну и ту же картинку в двух форматах (WebP и JPG) и помещаете их в одной и той же папке. Если браузер поддерживает WebP, будет загружена картинка в формате WebP. Если не поддерживает, будет показан JPG.

Здорово? Конечно! Однако неудобство заключается в том, что во-первых, вам придётся использовать FTP-менеджер для копирования WebP-файлов на ваш сервер (поскольку через эгеевский редактор этого сделать нельзя), а во-вторых, ширину картинки для корректного адаптивного масштабирования придётся ограничить шириной текста, т. е. около 740 пикселов, иначе картинка при масштабировании не будет умещаться в экран.

А что насчёт анимированного WebP?

В самом деле, ведь WebP поддерживает ещё и анимацию! Давайте-ка глянем, что он собой представляет в этом качестве и стоит ли использовать его вместо анимированных GIF, как на этом настаивает Google. (Если ролики с WebP-анимацией в вашем браузере вообще не видны, установите последнюю версию браузера.)

Вот 3-секундный тестовый видеофрагмент из тизера «IMAX® Titans Of The Ice Age» (контейнер mp4, кодек H.264, 10 кадров в секунду, размер файла 276 килобайт):

А вот результаты его кодирования с помощью плагина WebPShop:


Качество 50 (размер файла 812 килобайт)



Качество 70 (размер файла 1,1 мегабайт)



Качество 90 (размер файла 2,4 мегабайт)


Нетрудно заметить, что кодирование видео с качеством ниже 90 даёт заметные артефакты-клеточки на фоне однородной цветовой заливки (неба); при этом размер файла возрастает в геометрической прогрессии аж до 2,4 мегабайт, при том что исходный .mp4 имеет размер всего 276 кб!

Так что не очень понимаю, что имел в виду Google, рекомендуя WebP для замены анимированных GIF. Возможно, мультяшно-векторная анимация ему удаётся лучше, но для кодирования анимированных фотоизображений я бы вряд ли рекомендовал WebP. С этим гораздо лучше справляется его друг и соратник WebM.

Итого

Нужно ли добавить поддержку WebP в Эгею? Если спросите меня, я отвечу: «Разумеется, ведь это позволит сайтам на Эгее работать быстрее!» Большинство браузеров этот формат давно поддерживают. Так что главное — захотеть, правда?

2019   софт   Эгея

Эгея и красные банеры /core.php, line 2

Уважаемые пользователи движка Эгея!

Если у вас при установке новой версии Эгеи либо при её переносе начали появляться вот такие красные банеры с текстом /core.php, line 2 Error 2:

— то проверьте вашу версию PHP. Похоже, текущий релиз Эгеи (2.7, v3254) не очень дружит с PHP 7.2. В моём случае такие банеры стали появляться при обновлении Эгеи и одновременном переезде на новый хостинг. Банеры появлялись при выходе из настроек, а также на странице «теги». Как только я заменил PHP на 7.1, красные банеры перестали появляться.

Я писал об этих и других багах разработчику, г-ну Бирману, но, к большому сожалению, он за две недели ничего не ответил. Почему? Не могу знать. Возможно, он не сталкивается с подобной проблемой лично, а потому не заинтересован тратить своё время на её устранение. (Такое понимание сложилось у меня на основании прежней переписки с г-ном Бирманом.) А может, в целом охладел к Эгее и её дальнейшему совершенствованию. Однако буду рад, если ошибаюсь.

Так или иначе, друзья, как нам и было заявлено, поддержки нет. Но вы держитесь там.

2018   софт   Эгея