Алеандр

Алеандр
Рейтинг
207
Регистрация
08.12.2010
141c18
br.almighty #:

Если бы вы знали про Git, то у вас такой ситуации просто не было бы, так же как и этой истории.

Это еще вопрос к заказчику, зачем он дал задачу исполнителям, которые выполняют отложенные задачи с последующим накатыванием из репы и одновременно исполнителям, которые меняют содержание сайта "тут и сейчас". В принципе, поинтересоваться тоже можно было, когда я делаю правки по месту - всегда уточняю, все ли ушли с сервера и не будет ли параллельной работы. Пару раз на заре своей деятельности столкнулся с одновременным переписыванием файлов разными работниками и хорошо уяснил, что такое не редкость.
Сильно зависит от тематики сайта, качества пользователей, количества просмотров или действий по рекламе. Доход может быть как и 20р, так и 200р на 1000 посетителей, например. Какой-то одной конкретной цифры в срезе разношерстных сайтов не будет.

Крайне сомнительно, что для этого есть решения. Исключительно полагаться на отзывы и пробную работу с исполнителями. При желании налепить дырок - никаких проблем, плагины этот вопрос никак не решат, поскольку это все тот же код php. Чтобы не было возможности вредить - должны быть узкие функциональные возможности, чему установка CMS с полным доступом никак не способствует.

Хотя, тоже постою послушаю, вдруг есть дельные предложения.

Желаете пополнить ряды ботоводов, нагуливающих ПФ и профиля? ))
livetv #:

Можно заменить:

Это уже вопрос удобства и понимания в будущем. Я, иной раз, так сокращаю, что потом читать код, вытянутый в одну строку становится утомительно. Так то и переменная redirect не требуется в данной задаче.

if (stristr($_SERVER['REQUEST_URI'],'_')) { header("Location: https://site.ru".(str_replace('_','-',$_SERVER['REQUEST_URI'])),true,301); die(); }

А там уже и preg_match вместо stristr, кому удобнее, и str_replace на preg_replace можно заменить. Результат все равно будет тот же, это уже для маньяков сравнения скорости работы команд.

webinfo #:
Дык и не городили особенно
И вместо скрипта на 3 строчки без применения htaccess - 6 страниц размытых обсуждений и споров о том, как это сделать ))

Фига себе тут нагородили с простейшей задачей ))
Недавно делал у себя точно такую же, только еще и с редиректом на другой домен, поскольку переезд:

$redirect = str_replace('_','-',$_SERVER['REQUEST_URI']);
header("HTTP/1.1 301 Moved Permanently");
header("Location: https://site.ru".$redirect);
exit;

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

if (stristr($_SERVER['REQUEST_URI'],'_')) {
$redirect = str_replace('_','-',$_SERVER['REQUEST_URI']);
header("HTTP/1.1 301 Moved Permanently");
header("Location: https://site.ru".$redirect);
exit;
}

И городить при этом непонятные правила в конфигурациях тоже не придется.

Смешались в кучу люди, кони.. Какое отношение кэш имеет к сессии или куки? Это разные механизмы для разных задач. Хотите отдавать кэш - отдавайте. Нужно вести сессию пользователя - используйте куки. "Или" тут никак не подходит.
sagamorr #:

Если в браузере не сохраняются куки или юзер при заходе на сайт не соглашается с обработкой куки? Прочитайте подробнее про фингерпринт. В метрике не собираются mac адреса и другие параметры железа, а все остальные параметры у тысяч устройств могут быть одинаковыми. Или может вы что то больше знаете про фингерпринт?

Поделитесь какими возможностями JS можно отличить бота от юзера?

Если не сохраняются, то это проблемы пользователя. Не соглашаются? )) Вы серьезно считаете, что соглашение или не соглашение на большинстве сайтов как-то влияет на постановку куки? Там большая часть не спрашивает, она уведомляет, что "куки используются - нажмите Ок, чтобы закрыть сообщение" )) Мак адрес в данном контексте не имеет никакого отношения к собираемым данным для фингерпринт.

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

Владислав #:
Сначала разрешающие правила пишутся, потом запрещающие. Чем ниже в списке правило, тем выше приоритет. 
Сами себе противоречите, если бы это было так, то правило Disallow в примере было бы более важным, чем правило Allow. Но это не так, поскольку правила используются по мере их прочтения сверху вниз. Именно потому, если было встречено Allow, то оно будет исключено из нижеследующего Disallow. И на счет того, что сначала разрешающие - тоже не верно. Можно и наоборот, в зависимости от необходимого набора правил для сайта. Я, например, часто использую обратную конструкцию:
Disallow: /*?
Allow: /

PS: Некротопик, однако, появился

Всего: 1467