Имелось ввиду "у нас старый код, написанный под пхп4 в котором есть метод __construct (который что-то делает, но не конструктор ниразу, ибо в пхп4 это не было конструктором)" =)
Как раз учу хорошему - всегда объявляйте __construct и ставьте его первым в классе ;)
Зато полезно, пока проверял все это - нашел багу в пхп документации, которую туда месяц назад посадили ;)
Вообще-то это осознанно заложенное поведение.
__construct всегда приоритетнее.
Считается, что конструктор находится в начале класса.
Если сначала идет __construct, потом метод с именем класса - считаем, что это нормальный php5 класс, зачем тут strict?
Если наоборот, то рассматривается случай, что у нас PHP4, но есть метод с именем __construct. В этом случае поведение этого старого класса при выполнении на PHP5 будет иным, т.е. нарушается обратная совместимость. Из-за этого кидаем предупреждение.
Она была изначально utf8 или менял руками? Если руками - провеоь еще локаль конкретных полей таблицы. Если все utf8 и данные utf8 - set names должно перекодировать.
В вашем случае 3 варианта
1. error_reporting(A_ALL^E_STRICT);
2. Поставить старую версию ПХП
3. Править исходную библиотеку, которая написана криворуками
Если речь идет о https://github.com/d4fseeker/PsychoStats-extended/blob/master/upload/includes/PQ/PQ_PARENT.php, то там видно - query_rcon объявлена без параметров (хотя и вызывается в этом же коде с параметрами).
Вендор имеет отношение к товару, а не к ценам. Т.е. нет товара "молоко", есть товар "молоко ОАО ЕЖК".
Т.е. на таблицу цен идет связь только с итема, сети и города. А бренд уже завязан на итем.
А вот с SKU тут все сложно. SKU это что-то вроде артикула, только если артикул - это больше отношение к производителю, то SKU - это больше складской учет. А раз складской, то должен быть склад или какая-то логистика. И должна быть логика назначения SKU. И сначала стоит ее узнать. Т.е. вполне вероятно, что это будет просто поле в таблице итемов. А может, кто знает, у одного товара в разных городах будут разные SKU. Поскольку бизнес-задача не описана - и советовать нечего.
Насчет производительности - делайте сначала нормальную форму, а потом уже на реальных данных смотрите какие выборки, какие узкие места и решайте куда соломку подкладывать.
Для CSRF достаточно. Если под secert подразумевается секрет пользователя, а не приложения.
Хотя можно поступить в какой-то мере еще проще и создавать токен как hash от клиентской информации (ip, юзер-агент и т.п.) + какой-то фиксированный секрет приложения. И хранить в сессии ничего не нужно будет.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 378
