И снова ряд небольших вебмастерских заметок, может кому и пригодится.
Тег
, отсутствие атрибута href
Иногда в теге
href ну вообще не нужен, например когда мы вешаем на ссылку onClick(). Как обычно в этих случаях поступают? Пишут , ну или
. Зачем? Атрибут href совсем не обязательный, и его можно попросту опустить.
td {position: relative;}
? Лучше не надо.
Drupal защита от спама
Раньше всем и всегда советовал исключительно модуль Hashcash, основанный на одноименном проекте. Ни разу не подводил, и защита фактически 100-процентная. Однако сей модуль стал вступать в конфликт с последними обновлениями ядра Друпала, не происходила автоподстановка полей формы из печенек. Стал искать альтернативы. Нашел. Honepot. Хороший модуль. Только что изредка спам пропускает. Очень редко, но пропускает. Но проблема в том, что если сделать поправку на то, что сайтов у нас не один, а много, и все они добавлены в спам базы, это "редко" превращается в ежедневно. И радости моей не было предела, когда я узнал, что ранее вроде как заброшенный hashcash обновился, всего-то через неделю-другую, как я от него отказался. Баг пофиксили. И вот, на защите от спама на всех моих Друпал сайтах вновь трудится hashcash. Прошел ли хоть один спамный комментарий с этого времени? Нет, ни одного. Так что советую.
Drupal Views - оборачиваем поля в div
Довольно часто надо обернуть ряд полей в один div. Способов много, так-то. Это и темизация вывода Views через шаблоны (что как-то совсем уж зло звучит), или же соответствующая настройка самих вьюшек. В последнем случае вариантов опять же масса. Можно, например, отказаться от автоматической обертки всех полей в div'ы с простановкой стандартных классов, т. е. выводить содержимое полей "как есть", а там уже в вывод первого поля добавить в начале
. Или же у всех полей кроме последнего поставить галочку напротив Exclude from display, а в самом последнем поле в REWRITE RESULTS с помощью REPLACEMENT PATTERNS просто указать, содержимое каких полей и как выводить, соответственно заключив все это в
.
Но, я пока пользуюсь чуток другим способом, может и не лучшим, но как минимум мне удобным. Добавляем два дополнительных поля - один над всеми существующими, и один под. Тип полей - Global: Custom text. В первое вводим что-то по типу
. Естественно, снимаем галочку напротив Create a label. А дальше, если у нас стоит формат вывода вьюшечки Show: Fields, кликаем на Settings напротив и помечаем новосозданные поля как Inline fields, чтобы для них не создавалось никаких врапперов. Все - теперь все наши поля обернуты в нужный нам див, что и требовалось.
chmod -R a+rwX directory
Частенько надо сменить права на все содержимое определенного каталога, на подпапки и файлы. Сменить на, скажем, 777. Или rwxrwxrwx для папок. Но не для файлов! Зачем файлам выставлять права на исполнение? Нужно только на чтение/запись, rw-rw-rw-. А при команде chmod -R a+rwx directory файлы получат и права на исполнение в том числе. Чтобы это обойти (отдельные права назначать папкам, и отдельные - файлам) можно городить о-очень длинные команды. Или воспользоваться приятной фичей - написать 'X' прописной (т. е. большой). Тогда новые права на исполнение установятся только для папок, а для файлов останутся неизменным (но не перезапишутся на '-', если что).
PHP mail(), пятый опциональный аргумент
Не доходит почта, отправляемая через mail()
? Или постоянно попадает в спам? Возможно, причина в неустановленном Return-Path.
По умолчанию, если не сказано иного, Return-Path представляет из себя мыло вида user@fqdn. Где user - это юзер, от которого крутится веб сервер, а FQDN это fully qualified domain name. И многим спам фильтрам это не особо нравится. Поэтому желательно указывать Return-Path вручную. Сделать это можно через php.ini, если не ошибаюсь. Или же с помощью пятого опционального аргумента функции mail()
.
В последнем случае подаем в качестве аргумента следующую строку: '-fme@domain.com'. Сначала идет -f, а потом уже адрес нашей почты. Это мы так передаем sendmail'y опцию -f.
Домен может быть любой, главное существующий и не в спам/блок листах. В имени юзера лучше избегать root@, www-data@ и прочего. Я обычно указываю в этом параметре существующее мыло, которое отсылаю и в хедере, и которое же прописано в хуизе домена. А так, даже если указать мыло на каком-нибудь gmail, то тоже работает.
Это актуально как минимум для спам защиты почтовых серверов Петерхоста. Если им слать почту без этого параметра, или указать в этом параметре несуществующий домен, или же этот домен висит на ip, занесенный в spam/black листы, то почта попросту не доходит.
Не буду утверждать, но таки заметил, что и процент попадания почты в спам гугла намного меньше, если сей параметр указан. Так что теперь взял за привычку - всегда и везде mail'y давать на вход этот аргумент. Хуже не будет. А лучше - вполне себе.
Ну и в разрезе Drupal'a. В шестерке этот агрумент не передавался, многих это не устраивало, откуда и контрибный модуль Return-Path. А в семерке это уже из коробки есть.
Почта на VPS → gmail
Задача: есть домен, без поднятия и настройки своего почтового сервера, получать почту на этот домен на gmail. Не проблема! Надо просто поправить MX записи домена.
Напрямую слать на gmail нельзя. Раньше можно было. Точнее и сейчас можно, но платно. Так что будем использовать yandex почту в качестве прокладки. Делается это через сервис Яндекс почта для домена. В принципе, у них все достаточно подробно расписано в хелпе, как и что, поэтому я только вкратце.
1. Удаляем все MX записи домена и добавляем новую - mx.yandex.ru
2. Идем на сервис почта для доменов, и подключаем наш домен. Яндекс попросит верифицировать домен, способов предложит несколько, я обычно выбираю через заливку ихнего .html файла.
3. После верификации добавляем к этому домену нужный нам почтовый ящик.
4. Затем заходим в веб интерфейс нашей только что созданной почты, и создаем правило на пересылку всей почты на наш gmail ящик (но то, что яндекс посчитает за спам, заставить пересылаться нельзя).
Все! Осталось только потестить. Шлем почту на наш кастомный адрес me@mydomain.com и получаем ее на наш gmail аккаунт. Красота да и только.
me+something@gmail.com
У вас есть почта на gmail.com вида me@gmail.com? Значит у вас есть бесконечное количество почтовых ящиков, вида me+something@gmail.com, каждый из которых является алиасом me@gmail.com. Нигде ничего настраивать не надо, просто если отослать почту на me+dsfsdf@gmail.com, то она придет на me@gmail.com.
Чем это может быть полезно? Предположим, есть какой-то сервис. В котором нам надо зарегистрировать несколько аккаунтов. Регистрация каждого аккаунта предполагает подтверждение по мылу. На одно мыло несколько аккаунтов не зарегистрировать, это понятно. Регистрировать кучу адресов тоже не вариант, слишком трудозатратно. Да и печально будет, когда по прошествии времени в памяти сотрутся пароли доступа к ним, а надо будет вдруг восстановить пароль через эту самую почту. И вот тут gmail приходит на выручку - при регистрации нескольких аккаунтов просто указываем адреса почты вида me+account1@gmail.com, me+account2@gmail.com и т. д. Для сервиса - это разные почтовые ящики. Для гугла - алиасы одного и того же. Дико удобно.
Объединение графики в один файл
То, что кучи JS/CSS файлов надо программно объединять в один, всем известная прописная истина. А вот с графикой я что-то такой повальной солидарности почему-то не наблюдаю. Как пример, файлик графики stackoverflow. Надо полагать, актуально для высоконагруженных проектов, где экономия на спичках имеет смысл, и для сайтов с большим количеством графических элементов, чтобы по отдельности не приходилось подгружать десятки png.
Комментарии
В первом случае без href приходится добавлять
a:hover {cursor: pointer;}
Для почты - еще можно добавить к домену TXT SPF запись, чтобы не было ложного срабатывания защиты от спама (хотя я тоже не заморачивался)
Объединение графики актуально для иконок или десятков элементов дизайна, в стандартном случае (лого, пара градиентов, пара иконок) - нафиг не нужно.
В первом случае без href приходится добавлять a:hover {cursor: pointer;}
Это да :) Я даже обычно на такие ссылки свой класс вешаю, а не пользуюсь классами родительских элементов.
Для почты - еще можно добавить к домену TXT SPF запись
Oh, stop it! :3
Как обычно - пошел читать статью в вики, по ссылкам открыл еще over9000 статей, посмотрел на весь этот объем, и в печальке все позакрывал, отложив до лучших времен. Эх, лучшие времена, когда же вы наконец-то наступите?)
Объединение графики актуально для иконок или десятков элементов дизайна, в стандартном случае (лого, пара градиентов, пара иконок) - нафиг не нужно.
Согласен, поэтому я и не пользуюсь этими так называемыми "атласами", у меня обычно из графики только лого :) Но раньше, когда еще десятки и сотни разных шаблонов смотрел/использовал (WP, Joomla, Drupal), куча тем с десятками граф. элементов - и никто не объединял графику в один файл.