У меня есть форма с около 30 входов, которые должны быть проверены. Это довольно бесплатная установка sh Laravel, и я выполняю проверку в контроллере. Это простой проект, и все основано на Laravel документах, так что вам не о чем рассказать, когда речь заходит о самом коде.
Проблема связана с количеством ошибочных полей или количеством правил, но я не могу разобраться с этим.
Если я отправляю форму без заполнения какого-либо из полей ввода, проверка завершается неудачно, и я перенаправляюсь обратно на форму, НО без ошибок проверки ИЛИ старый входные данные. То же самое, если я заполняю один вход и затем отправляю, меня перенаправляют обратно без ошибок или старого значения заполненного ввода.
Однако
- Если я заполняю 7 полей ввода и представь, все работает. После перенаправления эти 7 полей имеют старые значения, а остальные имеют сообщения об ошибках.
- Если я закомментирую 7 правил из массива правил проверки, он, очевидно, будет работать так же, как указано выше.
- Если Я использую
Validator::make, вручную перенаправляю назад и использую ->withErrors($validator), ошибки отображаются в форме. Точно так же, если я использую ->withInput() на перенаправлении, форма будет иметь все старые данные. Однако, используя оба этих метода вместе, вы не будете возвращать ошибки или старые данные обратно в форму.
Когда эта проблема возникает, на панели отладки отображается array:2 [ "old" => [] "new" => [] ] для _flash, а сеанс, похоже, не имеет errors или _old_input определены вообще.
Это на 100% непротиворечиво, поэтому это определенно сумма, которая вызывает это, независимо от того, какие правила или поля я заполняю или комментирую.
Это происходит одинаково как с $request->validate($myRules);, так и с $v = Validator::make($request->all(), $myRules);
Я не нашел много от Google относительно такого рода поведения. На всякий случай я изменил драйвер сеанса на file, но это не помогло.
В настоящее время я работаю на XAMP. (memory_limit=512M)
Редактировать :
Моя окончательная проверка логи c включает некоторые "if-ситуации", такие как:
$v->sometimes('description', 'required|max:500', function ($input){
return $input->publish == 1;
});
И теперь, когда я использовал эти ситуации, я заметил, что они на самом деле уменьшают схематичный «предел» моей проблемы. Поэтому, добавив это единственное условие иногда и удалив правило description из массива основных правил, мне нужно всего лишь заполнить 6 полей, чтобы все работало.
В конце форма обязательно установит необходимые атрибуты на входы, так что эта проблема не произойдет в реальном сценарии, но это все еще меня раздражает, так как должно быть что-то, вызывающее это, и позже это может вызвать что-то еще.
Edit2 :
Я создал новую форму с 22 входами и назвал их логами c: f1, f2, f3 и так далее, и она отлично работает!
Но обновил несколько из них с более длинными именами, такими как: f1, f2long, f3, f4evenlonger и т. д. c, и проблема неожиданно вернулась. Затем я снова удалил несколько символов и нашел место, где оно иногда работает, а иногда нет.
Если в именах полей ввода всего 57 символов всего , все работает на 100% , Если я добавляю несколько символов и это число достигает 63, оно становится нестабильным, а иногда работает, а иногда нет. Если есть всего 70 или более символов, это никогда не сработает.
Так что явно что-то ограничивает это, но что?
Edit3 :
Да, это предел размера сеанса. Черт, это заняло много времени.
Я определил "файл" как сеанс драйвер, но он не создает никаких файлов в том месте, где он должен, поэтому он все еще использует "cook ie". Я дал пользователям Win10 права на запись файлов в папку хранилища (и вложенные папки), но она все равно ничего там не генерирует.