$work_time = [
'work_start_time'=>'09:30',
'work_end_time'=>'18:20',
'dinner_start_time'=>'13:30',
'dinner_end_time'=>'14:00',
];
$answer = 'Closed';
$date = str_replace(':','',$work_time);
$now = date('Hi');
if( $date['work_start_time'] <= $now && $now <= $date['work_end_time'] ) $answer = 'Now we open';
if( $date['dinner_start_time'] <= $now && $now <= $date['dinner_end_time'] ) $answer = 'Now we on break';
echo $answer;Есть код который надо запустить, перед тем как отдать страницу. Сервер Апач...В хтаксесе прописываете переадресацию всех запросов на индекс.пхп (т.н. единая точка входа, нужен модуль апача mod_rewrite), далее в индексе обрабатываете $_SERVER["REQUEST_URI"], достаете путь до хтмл файла и делаете readfile или include... Profit.
Возможно можно в htaccess правило прописать или например через index.php отдавать страницы, но они уже созданы...
echo('Это имя пользователя уже занято.');Здесь стопудоф будет лажа, так как хеадер так не отправляется. Почему - учим матчасть. Собсно в логах это будет отражено.
header('Location: register.php'); // Возврат на форму регистрации
Опять не подходит потому что куки могут украсть.Откуда вы такие специалисты по безопасности беретесь?..
Вопрос остаётся - как реализовать нормальный и безопасный способ для такой функции, чтобы больше не приходилось использовать другие варианты после каждой очередной жалобы на взлом?Взлом через уведенную куку входит в топ 5 малореальных сценариев взлома, если у вас есть хоть какая-то защита от XSS.
Хранить IP последнего входа в аккаунт? Идея неплохая, но если каким-то магическим образом БД взломают, то все айпи попадут нехорошим людям.Оу, вас это больше всего расстраивает? Учитывая что 80% траффика сейчас идет через мобильные сети, айпи будет разниться при каждой сессии авторизации. И в данном случае вероятность такого взлома вы почему-то оцениваете практически как "магию", в то время как доступ к кукам пользователя у вас на уровне "ну, это точно случится, и скорее всего раньше, чем позже, любой может там гулять как у себя дома"...
Всем привет. Хочу сделать пошаговую регистрацию на сайте. Как бы это сделать правильнее?Нет рецепта для общего случая. Всегда есть нюансы, если вы делаете что-то чуть в сторону от классики.
1. После каждого шага сохранять в БД? Много запросов бессмысленныхОго, много это сколько? И почему бессмысленных? Вы же осмысленные данные туда пишете?
У кого, какое мнение? Где какие подводные камни/нюансы?Мнение: С таким описанием нихрена не посоветуешь. По конкретным шагам можно что-то обсуждать.
$q = "INSERT INTO post(author, date_p, text_p) VALUES ('$author', '$datep', '$text_content')";
// ";" в одиночных запросах не ставится, а текстовые значения обрамляются кавычками
var_dump($q); //смотрим глазками, проверяем в консоли
$q = "INSERT INTO post(author, date_p, text_p) VALUES (?, ?, ?)";
//никогда не лезем в бд без подготовленных выражений!
$st = $pdo->prepare($q);
$sth->execute([$author, $datep, $text_content]);Мне нужно что-бы функция вернула корни уравнения в виде массива.Она возвращает
Однако я получаю пустоту.Однако не получаете
Почему?Скорее всего вы подразумевали не "получение" а "вывод". Но никакого вывода на экран вы не используете.
Не работает return PHP. Ничего не выводит на экран, что делать?Формально ответ - по тому что "получение"/"возвращение" и "вывод" абсолютно разные вещи.
Мне нужно аргументировать ответ, но я не знаю как ответить правильно.Очень просто: Так как проверка отнимает процессорное время, то экономия все равно будет липовой, вместо памяти потратится ресурс процессора. Сколь ни будь значительной экономии это не даст ни в том, ни в другом случае, точнее экономия будет в случае отсутствия проверки и существования переменной, что будет происходить скорее всего чаще чем несуществование переменной, ну или по крайней мере в каком-то числе случаев, в то время как проверка будет осуществляться всегда.
SELECT m.*, u.login, i.img
FROM messages m
LEFT JOIN users u
ON m.to_user_id = u.id
LEFT JOIN image i
ON m.to_user_id = i.obj_id
WHERE m.date > :lastdate # надо выбирать все что позже уже полученных сообщений
AND image.obj_type = 'user'
AND m.from_user_id = :fid # айди "от юзера"
AND m.to_user_id = :tid #айди "к юзеру"
ORDER BY m.date # по возрастанию все старше последнего полученного<input type="file" name="fileFF[]" multiple="multiple" multiple id="fileFF" class="w100" name="files[]" />что скажите?Во первых "скажете". Во вторых не понятна суть вопроса, вы описали 2 разных механизма, один использует slug, другой id, к чему относится ваше описание механизмов определения уникальности - не понятно. Где вопрос?
Разбиваю строку на массив, из первого параметра получаю имя контроллера и создаю соответствующий экземпляр. Если нет второго параметра, вызываю действие по умолчанию: на сайте это отобразить каталог, или страницу со сатьями (uri соответственно mysite.com/catalog или mysite.com/articles). Если же есть второй параметр (это название конкретного растения или id статьи), вызываю другое действие и передаю параметр (получается mysite.com/catalog/aloe)то что вы реализовали к роутингу имеет такое себе отношение. Роутинг обычно опирается на правила, а увас тупо захардкорен контроллер. Что будете делать если сложность будет чуть выше, и например, добавится язык перед контроллером?
При запросе вида mysite.com/catalog/aloe/test, т.е. когда через слеш появляется третий параметр, та же страница с уведомлением для пользователя отображается без стилейЛогично, стили у вас лежат всегда в одной папке, а вы их каждый раз подключаете из разных "путей" в урл, от которых зачем-то высчитываете сколько папок "выше отмотать". Путь должен быть абсолютным.
Вот логика проверки, буквально, если в массиве получилось больше двух элементов, отобрази страницу ошибкиВообще логика должна быть такой, что если больше 2 параметров, то все что дальше помещается в какой-то массив, например $parameters, который можно получить из роутинга, и дальше в зависимости от значений что-то делать. Правильнее все же было бы сделать сопоставление пути с контроллером, экшеном и параметрами, как во взрослых роутерах, но для начала и так сойдет.