2

Noindex и nofollow

Для скрытия части материала от поисковых роботов не существует стандартизированных инструментов. Но существуют проприетарные элементы для разных поисковиков.

Тег <noindex> позволяет скрыть кусок страницы от Яндекс- и Rambler-ботов.

<noindex>скрываемый контент</noindex>

Весь текст заключенный в такие теги будет проиндексирован, но не будет учитываться при ранжировании (в том числе не будет передаваться рейтинг по ссылкам). Этот тег невалидный, но можно скрыть его от валидатора.

Для заграничных поисковиков нет возможности спрятать кусок страницы, но можно скрыть ссылку, указав ей атрибут rel="nofollow".

<a href="..." rel="nofollow">скрываемая ссылка</a>

Этот атрибут для ссылок понимают Google, Yahoo, Bing. Использование его не скрывает ссылки от индексации поисковиками, но говорит им, что не надо передавать по таким ссылкам рейтинг. В работе поисковиков с этим тегом есть небольшие отличия.

Обновление от 25.08.2010. В мае 2010 года поисковый робот Яндекс начал поддерживать новые возможности. Появилась возможность писать тег <noindex> в валидном виде — комментарием:

<!--noindex-->неиндексируемый текст<!--/noindex-->

Тогда же Яндекс начал поддерживать для ссылок атрибут rel="nofollow".

0

Позднее статическое связывание в PHP

В PHP 5.3 появилась такая интересная возможность, как позднее статическое связывание (late static binding). Дальше немного вольный перевод описания из официального мануала.

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

Эту возможность назвали «позднее статическое связывание». «Позднее связывание» говорит о том, что static:: будет разрешаться не относительно класса, где определен метод, но будет вычисляться во время выполнения. «Статическое связывание» означает, что оно может быть использовано в вызовах статических методов (но не ограничивается только ими).

Ограничения self::

Статические ссылки на текущий класс в виде self:: или __CLASS__ разрешаются относительно класса, к которому относится функция, то есть относительно класса, где ссылка была определена:

Пример № 1: использование self::

<?php
class A {
  public static function who() {
    echo __CLASS__;
  }
  public static function test() {
    self::who();
  }
}

class B extends A {
  public static function who() {
    echo __CLASS__;
  }
}

B::test();
?>

Пример выведет:

A

Использование позднего статического связывания

Позднее статическое связывание пытается решить это ограничение, вводя ключевое слово, ссылающееся на класс, первоначально вызванный в процессе выполнения. То есть, ключевое слово, которое позволит сослаться на B из test() в предыдущем примере. Было решено не вводить новое слово, а использовать уже зарезервированное static.

Пример № 2: простое использование static::

<?php
class A {
  public static function who() {
    echo __CLASS__;
  }
  public static function test() {
    static::who(); // здесь происходит позднее статическое связывание
  }
}

class B extends A {
  public static function who() {
    echo __CLASS__;
  }
}

B::test();
?>

Пример выведет:

B

Замечание: static:: не работает как $this для статических методов! $this-> следует правилам наследования, а static:: нет. Это различие уточняется ниже.

Пример № 3: использование static:: в нестатическом контексте

<?php
class TestChild extends TestParent {
  public function __construct() {
    static::who();
  }

  public function test() {
    $o = new TestParent();
  }

  public static function who() {
    echo __CLASS__."\n";
  }
}

class TestParent {
  public function __construct() {
    static::who();
  }

  public static function who() {
    echo __CLASS__."\n";
  }
}
$o = new TestChild;
$o->test();
?>

Пример выведет:

TestChild
TestParent

Замечание: Позднее статическое связывание останавливает процесс разрешения вызова. Статические вызовы с использованием ключевых слов parent:: или self:: передают информацию о вызове дальше.

Пример № 4: Передача и непередача вызовов

<?php
class A {
  public static function foo() {
    static::who();
  }

  public static function who() {
    echo __CLASS__."\n";
  }
}

class B extends A {
  public static function test() {
    A::foo();
    parent::foo();
    self::foo();
  }

  public static function who() {
    echo __CLASS__."\n";
  }
}
class C extends B {
  public static function who() {
    echo __CLASS__."\n";
  }
}

C::test();
?>

Пример выведет

A
C
C

Крайние случаи

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

Пример № 5 Позднее статическое связывание в магических методах

<?php
class A {
  protected static function who() {
    echo __CLASS__."\n";
  }

  public function __get($var) {
    return static::who();
  }
}

class B extends A {
  protected static function who() {
    echo __CLASS__."\n";
  }
}

$b = new B;
$b->foo;
?>

Пример выведет:

B

Пару статей по теме на хабре: Singleton и Late static binding и Позднее статическое связывание в PHP.

0

#crockfordfact

#crockfordfact —очень веселый хэш-тег про javascript — cборник мемов о содателе JSON и наикрутейшем javascript-гуру Дугласе Крокфорде по типу баек про Чака Норриса. Например:

Douglas Crockford doesn’t sleep, he setTimeouts @tomh

Douglas Crockford knows the name of every anonymous function in JavaScript. @tobeytailor

Сайт, посвященный «фактам» о Крокфорде.

0

Регистр в именах таблиц MySQL

Каждая таблица MySQL связана с файлом в системе. Потому при переносе проекта с Windows на рабочий *nix-хостинг нажно помнить, что под Windows имена таблиц не чувствительны к регистру, а на большинстве систем *nix чувствительны. Хорошим решением не наткнуться на эти грабли будет везде использовать строчные буквы при именовании таблиц. Тем более, что официальный мануал именно такой вариант и рекомендует. Тем не менее существует возможность влиять на то, как система работает с регистром с помощью параметра lower_case_table_names. Этот параметр может принимать три значения:

  • 0 — значение по-умолчанию на *nix-системах. Идентификаторы хранятся в том виде, в каком были указаны при создании. Имена регистрозависимы.
  • 1 — значение по умолчанию для Windows. Идентификаторы хранятся на диске в строчных буквах, имена регистронезависимы.
  • 2 — значение по умолчанию для MacOS. Идентификаторы хранятся в том виде, в каком были указаны при создании, но при поиске MySQL конвертирует их в строчные. Поиск имен регистронезависим. Это работает только на регистронезависимых системах! Таблицы InnoDB хранятся в строчных, как при lower_case_table_names=1.

Стоит добавить, что названия столбцов и индексов во всех системах регистронезависимы.

Подробнее читайте в мануале.

0

Переадресация на домен с www

Если сайт досупен по и по адресу с www, и по адресу без www, возникают проблемы с поисковиками. Они видят один и тот же сайт как два разных. Если ваш сайтовый движок не обрабатывает сам такие ситуации (в WordPress, например, задается адрес по-умолчанию), то можно исправить это с помощью апача. Пишем в .htaccess правило для редиректа:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_HOST} ^dec5e\.ru$ [NC]
  RewriteRule ^(.*)$ http://www.dec5e.ru/$1 [L,R=301]
</IfModule>

Если есть желание сделать основным домен без www, то правила будут выглядеть так:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_HOST} ^www\.dec5e\.ru$ [NC]
  RewriteRule ^(.*)$ http://dec5e.ru/$1 [L,R=301]
</IfModule>

dec5e.ru надо заменить соответственно на нужный домен.

Если секция уже есть в файле, то вставляем в нее перед другими правилами. При попытке открыть сайт без www будет выполнен 301-ый редирект (Moved Permanently — перемещен постоянно). Этот код скажет поисковикам, что сайт навсегда перехал на адрес с www. Параметр L означает, что все правила указанные после этого RewriteRule не сработают. Параметр NC в RewriteCond обозначает, что ведется регистронезависимый поиск правила. Для более полного описания этих и других параметров смотрите официальную документацию по mod_rewrite (или по-русски).

0

Как проверить поддерживает ли браузер SVG

Для проверки нативной поддержки можно использовать два метода. Первый из презентации (страница 27) Дмитрия Барановского, автора Raphaël:

if (window.SVGAngle) {...}

основан на проверке доступности интерфейса SVGAngle и позволяет определить наличие поддержки в принципе. Второй из обсуждения на Stack Overflow:

if (document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#BasicStructure", "1.1")) {...}

проверяет наличие поддержки определенной версии спецификации и даже определенных возможностей.

Оба метода работают в браузерах Firefox 2+ Win, Opera 9.0+ Win, Safari 3+ Win, Chrome 3+ Win, IE+ChromeFrame. Версии для других платформ у меня нет возможности  проверить, но, думаю, ситуация аналогичная. Хотя в Safari 3.0.4 для MacOS есть баг, из-за которого первый способ не работает. После выхода 4й версии в августе доля Safari 3 составляет меньше 1 процента. Но все же второй вариант проверки выглядит предпочтительным и более правильным.

Copyright © 2017 — dec5e | Site design by Trevor Fitzgerald