Можешь погуглить PSR-ы для PHP. Следование им хотя бы процентов на 60 уже решит кучу проблем. Можешь просто использовать IDE с авторасстановкой кода типа того же phpStorm. Тогда вообще не будешь париться об отступах, пробелах, табах, переносах и тд. Ну и простые правила для себя выучить, типа логического разделения строк, или что после if/for/while/чего угодно, работаюзего с блоками, обязательно должна быть секция {}, даже если в ней всего одна строка. Потому что вот это: PHP: if ($done){ return $result; } гораздо читабельнее и приятнее, чем PHP: if ($done) return $result; И, главное, расширябельнее. --- Добавлено --- Так, и слона-то мы и не заметили.. Я к тому, что с кодом все не так и здорово. Скажи, а почему ты вообще не используешь функции? Сейчас код, по факту - макаронная простынь. Это плохо. Это трудно сопровождать, трудно расширять, трудно изменять. Почему бы не вынести основные логические узлы в функции, которые бы вызывались, в зависимости от входящих параметров? Тогда в коде были бы чистота и порядок. Задачка, конечно, простенькая, но даже для нее нужна какая-никакая архитектура приложения.
Благодарю за ответ. 1) Форму сам делал, не знаю как доказать на деле, могу лишь слово дать 2) Не очень понял, можете дать вектор направления куда идти по поводу этой ошибки 3) А если бы не было перенаправления, то переменные надо уничтожать, я правильно понял? Остальное все понятно, но еще вопрос password_hash надежнее чем crypt поэтому его желательно использовать? --- Добавлено --- Спасибо, почитаю, на счет функций, что-то даже не думал об этом, но все же попробую переделать)
Да мне кажется, ошибочную форму пусть себе повторно отправляет, шут с ней, всё равно дубль в базу не запишется. В Yii2 это стандартная практика, вообще.
Это не ошибка, это специфика протокола. Дело в том, что когда ты открываешь страницу, ты делаешь к ней запрос. В истории браузера запись сохраняется в виде этого запроса. Если до этого ты делал POST/GET, то они включены в тело запроса, и когда ты нажимаешь "назад", получается так, что этот запрос ты посылаешь повторно. В случае с GET, если он применяется правильно, на это совершенно плевать, он для таких вещей и существует. В случае с POST все сложнее. Это запрос для передачи серверу каких-то данных на сохранение, по-хорошему. Если один раз ты его сделал, то второй раз, собственно, его делать, скорее всего, не желательно. Но это запрос к серверу, и он сохранен в истории. Во времена, когда пещерные люди охотились на мамонтов, браузерам, особенно IE, было плевать на это. Это было веселое время, когда ты что-то написал на какой-нибудь форум, потом нажал обновить страницу, и твое сообщение добавилось снова. Потом нажал снова, и оно опять добавилось. Ну а что, ты шлешь POST-запросы, сервер их обрабатывает, а если разраб не парился, то случалась такая фигня. Уже тогда было даже подобие мемчиков про это. Сейчас в браузерах предусмотрена защита от этого, и они спрашивают, уверен ли ты, что хочешь снова послать запрос? И это вроде ок, но на деле напрягает и раздражает. То есть технически оно верно, а в плане восприятия - какая-то странная неинтуитивная херня. По этому веб-разработчики взяли себе как правило хорошего тона всегда делать перенаправление после обработки POST-запроса, чтобы в истории сохранялся "чистый" запрос к серверу, без формы. Итого: отработал POST, перенаправься на страницу, с которой отработал. Если нужна какая-то реакция на этот POST, то перенаправься с GET-ом или кукой, из которой сервер поймет, что нужно отобразить. Вот простой код, он должен внести ясность: PHP: session_start(); $_SESSION['lol'] = 123; session_destroy(); var_dump($_SESSION); Если ты его выполнишь, окажется, что $_SESSION['lol'] существует после выполнения session_destroy(); Дело в том, что session_destroy(); убивает файл сессии, но не массив $_SESSION. Если ты из этого кода удалишь вторую и третью строку, окажется, что сессия пуста. То есть, при следующем вызове, покуда хранилище было удалено, сессия создастся снова, и значению $_SESSION['lol'] будет неоткуда взяться. Но, если мой скрипт продолжает работать после session_destroy(), и мне не нужно, чтобы там было значение ['lol'], я должен удалить его руками, через unset. В твоем же случае, работа после уничтожения сессии не будет выполнена. У тебя там выброс заголовка для перенаправляшек, после которого exit(). Выполняться больше нечему. А, так как ты сделал session_destroy(), то переменным, что там были раньше, на старте взяться неоткуда. По этому и грохать их руками не было смысла. Оно не надежнее. Оно иначе. И удобнее. Кстати, вот еще ошибка: PHP: $hash = crypt($_POST['password'], 'fd589a87ffed3947460b');//хеш пароля Ты используешь одну соль на все пароли. Это очень очень плохо, это неправильно. Почитай про это отдельно. И, к слову, password_hash решает эту проблему за тебя, потому что сам генерирует соль, сам правильно все пишет в строку, тебе осталось только ее сохранить. А потом использовать для проверки. Очень удобно. Алгоритмы же, что тут, что в crypt используются одни и те же. Это всего лишь инструментарий для работы с ними. --- Добавлено --- Ды если бы она отправлялась.. Она ж, вон, плашку выдает. Это я знаю, что надо просто тыкнуть в адресную строку и enter жмакнуть, и все заработает. А рядовой пользователь подумает, что у тебя сайт сломался.
Спасибо, почитаю, на счет функций, что-то даже в голву не приходило Понял спасибо, учту все советы и буду исправляться)
Ну я ради этого от удобства, которое дают модели форм в Yii2 не откажусь от показа ошибочной формы прямо в post-запросе. Заодно и данные, которые были введены верно не теряются. А так - пихать из в сессию или get-параметры - морока лишняя. Вообще, нефиг f5 жать, если тебе сайт ошибку выдал нормальным русским языком.
Не, иногда просто "назад" жмакаешь, и тоже попадаешь на страницу с POST-запросом. YII, мб это не так важно. Но, по возможности, лучше это все же делать. К тому, же, не верится мне, что в UI нельзя после обработки POST-запроса самому выбросить редирект.
Можно конечно, но тогда надо данные формы сохранять в сессию, чтоб показать юзеру, что для меня слишком. Вот типичная обработка формы yii (это каркас приложения от разработчиков фреймворка): https://github.com/yiisoft/yii2-app-advanced/blob/master/frontend/controllers/SiteController.php#L83 Редирект (вызов $this->goBack(), в данном случае это логин, предполагается, что страница, переадресовавшая на логин установит себя определённым образом в сессии) только если достигли успеха, а если ошибки - просто показать ошибки и данные (этот механизм сразу в модели заложен).
Их можно понять. Они выбирали между своими формами и использованием сессий/гетов для выброса ошибки при переалресации. При том, что встроенная пыховая сессия может быть не задействована на проекте, а геты могут вообще не использоваться в силу хитрых редиректов и ЧПУ. Когда делаешь что-то универсальное, всегда откатываешься до определенного уровня абстракции и берешь на себя ответственность за то, что делаешь, потому что на этом уровне абстракции ты отнимаешь свободу воли у пользователя и начинаешь решать за него. Разрабы YII решили за пользователя вот так так. И ты с этим живешь. Но в другой ситуации, лучше так не делать все же. Гугл так не делает, фейсбук так не делает, валв так не делает, яндекс так не делает, да даже мэлору, прстигспди, и то так не делает. Они все юзают редиректы и геты/куки. Разрабы фреймворков порой доходят до крайностей в желании контролировать ВСЕ, покрыть каждый аспект чего бы то ни было, оставляя разработчику минимум воли вне пределов фреймворка, чтобы сделать свою экосистему максимально закрытой. И, наверное, молятся на JQuery, как на икону, потому что это единственный случай, когда этот замысел удалось воплотить на 100%. И такая работа с формами в YII - одна из таких крайностей, как по мне. Когда же у тебя развязаны руки, лучше, все же, делать редирект.
Мне всегда было интересно какими фреймворками пользуются мэтры этого форума. Знаю только, что mkramer сидит на yii.
Добрый вечер, по поводу задачи, не получается стандартными функциями корректно проверить возраст делаю так: PHP: $date_of_b = mktime(0, 0, 0, $_POST['month'], $_POST['day'], $_POST['year']); $age = floor((time() - $date_of_b) / (365 * 24 * 60 * 60)); if ($age < 5) { $err[] = 'Вы слишком молоды'; } elseif ($age > 150) { $err[] = 'Вы слишком стары'; } Так вот функция выводит 47 лет (если я выбираю год рождения 1867), а если смотреть задачу, то человеку может быть 150 лет, то есть он родился в 1867 году, посоветуйте пожалуйста как поступить. В голову приходит только написать условие если родился раньше 1867 года, выводить "Too old"
@HeuPoH, не теми функциями пользуетесь. Во-первых, ваши выкладки явно не учитывают, что не во всех годах 365 дней. Во-вторых, возможно ошиблись ещё где-то в математике. Но в принципе, на php не нужно изобретать работу с датами - всё уже сделано. --- Добавлено --- Да, и кстати, как вы себе представляете метку Unix для 1867 года, если время UNIX стартовало, дай Бог памяти, 1 января 1970 года?
Я ниразу не мэтр, но И в итоге получаются программисты, которые знают лишь этот фреймворк и не в курсе того, что за фреймворком есть целый язык. У меня так бомбило от людей, которые объясняли что у меня в контроллерах много кода, но на вопрос о том, для чего нужен strstr молчали в ответ. Некоторые вообще не в курсе что существует php.net. Вот где корень зла.
Не, ну конечно, надо сначала учить язык, а потом фреймворк. Тем, кто не твёрдо знает php, но лезет писать на Yii2, на форуме последнего всегда указывают, куда им надо идти Но фреймворк очень многое даёт. Если не использовать чужой фреймворк, надо написать свой и таскать его из проекта в проект. Но лично про себя я не уверен, что сумею написать лучше. А вообще, нормальному программисту на освоение нового фреймворка много времени не потребуется. Вот мне недавно пришёл проект, который кто-то начал писать на CodeIgniter, ну что делать, заказ интересный, деньги меня устраивают, поплевался на эту поделку и взялся за работу. Если завтра потребуется доработать Zend Framework 2 или 3 (который я по своей воле у себя в проекте не буду использовать, поскольку считаю, что я не разрабатываю проекты таких масштабов, для которых он нужен) или Symphony - ну почитаем доку, и начнём делать. В принципе, лично я всё, что делаю на фреймворке, могу сделать и без. P.S. Хотя названия и назначение всех функций, которые есть в php я наизусть не заучивал, конечно. --- Добавлено --- Ну они по-своему правы, вообще в классах не должно быть много кода, не только в контроллерах, если всё правильно делать. Иногда правда лень
Да, я читал про начало отсчета, поэтому решил спросить как в этом случае быть, щас увидел функцию date_deff с ней буду работать. Спасибо
Вроде все исправил, оцените пожалуйста еще раз: 1. index.php - https://gist.github.com/49c2f7e0a222aba8b3df2dc3cbeae379.git 2. reg.php - https://gist.github.com/fa99a70b3c49bfcc7b7f9e943ee60178.git 3. funtion.php - https://gist.github.com/b0e4acbb9cb705638afedc19b0e2dfc4.git http://teachphp.h1n.ru - вот сайт entry_form.php PHP: <?php echo '<form method = "POST" action = " ">'.PHP_EOL; echo 'Введите логин: </br> <input type = "text" name = "login" placeholder = "Логин" required></br>'.PHP_EOL; echo 'Введите пароль: </br> <input type = "password" name = "password" placeholder = "Пароль" required></br>'.PHP_EOL; echo '<input type = "submit" name = "entry" value = "Войти"></form>'.PHP_EOL; echo '<form action="reg.php"><button type = "submit">Зарегистрироваться</button></form>'.PHP_EOL; ?> reg_form.php PHP: <?php echo '<form method = "POST" action = " ">'.PHP_EOL; echo 'Введите логин: </br> <input type = "text" name = "login" placeholder = "Логин" required></br>'.PHP_EOL; echo 'Введите пароль: </br> <input type = "password" name = "password" placeholder = "Пароль" required></br>'.PHP_EOL; echo 'Введите дату рождения:</br>'.PHP_EOL; echo 'День   Месяц   Год</br>'.PHP_EOL; echo '<select name = "day">'; for ($i = 1; $i <= 31; $i++) { echo '<option>'.$i.'</option>'.PHP_EOL;//Создаем максимальный список дней } echo '</select>'.PHP_EOL; echo '<select name = "month">'; for ($i = 1; $i <= 12; $i++) { echo '<option>'.$i.'</option>'.PHP_EOL;//Создаем список всех месяцев } echo '</select>'.PHP_EOL; echo '<select name = "year">'; for ($i = 1800; $i <= 2015; $i++) { echo '<option>'.$i.'</option>'.PHP_EOL;//Создаем список годов } echo '</select></br>'.PHP_EOL; echo '<input type = "submit" name = "reg" value = "Зарегистрироваться"></form>'.PHP_EOL; ?>
Не надо так делать. Вы как будто не на PHP пишите. Не включайте режим php, если нужно только html вывести. В данном случае можно было вообще на html страницу оставить. Вообще, если большой кусок html идёт, надо выключать режим php, писать человеческий html, потом, когда надо, включать. И использовать сокращённую операцию <?= $someVariable; ?>, благо она аж с версии 5.4 разрешена без доп. настроек
Приветствую, это аналог \r\n, но это в пхп. Я конечно, понимаю, что вы наталкиваете меня на мою ошибку, но я пока не очень понял.
Уважаемый Сурикат повествует о том, что браузер игнорирует переводы строки (вернее, трактует любую последовательность пробельных символов как один пробел), когда разбирает html.
Именно. \r\n в HTML не несет никакой полезной нагрузки. Только добавляет лишние байты в пересылаемый трафик. Явный перенос строки указывается как <br>, либо <hr>, если нужна отрисовка разделителя, неявный же перенос всегда выставляется перед объектами с блочной моделью отображения. На "чистом HTML" только так. Еще можно делать переносы без BR-ов с помозью CSS, оперируя отступами содержимого и размерами контейнеров. Ну и еще у нас есть flex, но это отдельный феншуй. Символ конца строки же не даст вам ничего. --- Добавлено --- И да, это не аналог. Это константа, содержащая корректный разделитель в зависимости от платформы, на которой работает пых. Так уж исторически вышло, что между линуксом, виндой и маком есть некоторая путаница в этих вот \r\n, \n и \r.