подозреваю, что надо вместо
pname = jQuery('[name=pname]').val();
выбирать так:
pname = rParent.find('[name=pname]').val();
ну чисто по аналогии с id, который. как вы говорите, выбирается корректно.
уберите вот это
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php echo $this->language; ?>" lang="<?php echo $this->language; ?>" >
а вместо
lang="ru"
пропишите ниже во всех строках
lang="<?php echo $this->language; ?>"
ну или просто оставьте как было, если у вас других языков не планируется.
все бы так вопросы задавали :-D
В целом видится две больших подзадачи.
1. Математическая модель клёва. Т.е. грубо говоря, формула зависимости клёва от погодных условий и от чего он ещё зависит. С этим очень вряд ли здесь помогут.
2. Прикручивание этой формулы к сайту. Вот по этому вопросу можно уже и здесь интересоваться, но когда будут конкретные вопросы, опять же.
Поисковики видят то, что вы видите в средствах разработчика во вкладке network в правой части в табе response.
Гугл умеет исполнять какой-то javascript, т.е. теоретически он может прочитать то, что в эти скобки подставил ангуляр.
Но для ангуляра есть приблуды для серверного рендеринга - думаю они существуют не просто так, так что я бы с точки зрения seo не стал рисковать и таким образом выводить мета-теги, да и вообще какой-либо контент.
Другое дело, что эти двойные скобки - они и в серверных шаблонизаторах используются, но тут судя по тем же значениям в ng-if это всё-таки ангуляровские конструкции.
Да одно и то же это. В английском языке и еще синонимы есть для этого понятия - http://stackoverflow.com/questions/16751269/oop-terminology-class-attribute-property-field-data-member
Я вот лично обычно свойством это называю.
Snoopy не так работает - там вы сами устанавливаете куки для каждого запроса (свойство $cookies). Получить куки с сервера можно через заголовки ответа.
Посмотрите начало файла - там есть краткое описание свойств.
Можно.
https://sourceforge.net/projects/snoopy/ - вот класс для работы с http через сокеты. Там была и поддержка кук, насколько я помню.
Конкретно как у почтовиков сделано - не знаю, но вообще эти headless браузеры палятся по наличию определённых методов у объекта window в js.
Столкнулся с этим при попытке парсинга кранчбейса. Пришлось прогонять траффик через fiddler и модифицировать js чтобы прикинуться нормальным браузером.
Но мне там не нужен был парсинг в промышленных масштабах, а просто автоматизация.
В общем случае - смотрите через тот же fiddler запросы к серверу при регистрации из нормального браузера и через phantomjs
Ну вот вам же ответили, что порежут канал. Соотвественно по факту максимальный траффик ограничен пропускной способностью помноженной на время.
Ну и опять же, может в датацентром договорились на разных условиях, может рассчитывают, что средний клиент не будет превышать какого-то определенного объема. Т.е. у вас, допустим, много траффика тратится, а у кого-то мало - в итоге в сумме у вас некое среднее значение, которое хостера устраивает.
