Центос отличный вариант для сервера. Еще ни разу не подводил.
С centos 7 делаю у себя проще. Редактирую непосредственно /etc/sysconfig/iptables-config , куда и вношу нужные изменения.
Вообще сталкиваюсь с тем, что у разных хостеров разный centos7 . У одних iptables, а у других firewalld . Так же у одних сендмайл по умолчанию, а у других постфикс.
Т.е. поставленный образ цента отличается от эталонного с сайта.
Документирование необходимо как правило только при описании api и других торчащих наружу мест.
Если в цену вложена и документация, то спору нет. А так просто документировать очевидное - какой смысл ? Ну или оплачивать отдельно работу аналитика, который в паре с кодером и будет заниматься документацией.
Нет, не так. Может быть масса причин почему там не видим экранирования. Раз уж я и обрвтил внимание на отсутствие экранирование, то сейчас могу точно так же предположить почему оно там нафиг не нужно.
Ведь переменная в параметр попадает через запрос в функцию , а не через $_GET. И может там функция наследует уже предварительную обработку входных данных и производится экранирование в нужном виде именно там.
Т.е. как сказали выше, надо смотреть код. А пока сиди и гадай на кофейной гуще :)
Исправить конкретную ошибку - да, будет легче. А проанализировать код на предмет ошибок - может запросто оказаться дороже, чем само написание кода.
А чего не так то ?
Если product_id не передали - значит кто то играется с параметрами и правильнее грохнуть скрипт. Воткнуть экзепшен всегда успеется, да и может он там нафиг не нужен.
Ну и со status также, если кто то передал "3" - то тупо перекинем в 0, т.е. скорее всего в выключенное состояние.
Красивым код бывает только на стадии планирования или при жирном клиенте оплачивающим рефакторинг.
Если придираться, то к sql коду, который собран на прямую из GET параметров и может быть не безопасным.
$query = "UPDATE #__vm_clicks set `hits`=`hits`+1 WHERE id={$id}";$db->setQuery($query);$db->query();
Код похож на обертку над PDO из за "$db->setQuery($query)" , и наверняка тут можно вторым элементом передать массив значений для запроса, который правильно и будет экранирован уже на уровне драйвера базы.
В конце UPDATE и вставить. Только добавить LIMIT 1, что бы только одна запись обновлена.
Т.е. в общей сложности "order by price desc limit 1" .
Правда не уверен, что на всех версиях mysql это сработает. Вообще так лучше не делать, а выбрать сначала запись а потом ее уже и обновить.
http://fancybox.net/howto - взять вот этот скрипт. Подключается в пару строк, очень легок в использовании.
А зачем его пересчитывать постоянно ? Храните сумму баланса отдельно. Смысл в том, что эта сумма меняется только на основе данных транзакций, а не в результате плюс/минус от суммы в балансе.
Да и при бухгалтерской отчетности никого сумма баланса не интересует, так как будут нужны числа приход/расход . А разница между этими числами - и есть так называемый баланс.
Без шансов, по крайней мере если парсят намеренно. Т.е. по IP заблокировать разве что. А по рефу только ну очень тупых ботов, которые фактически в природе не встречаются.
Под nginx как вариант https://github.com/mariusv/nginx-badbot-blocker
Но php5 юзерагента ни разу не встречал.
Обычно старые записи уходят в архив, а вместо их просто добавляется единственная с суммой ушедшего в архив.
Так действительно правильнее, когда баланс равен сумме транзакций.
