The maxlength attribute specifies the maximum number of characters allowed in the <input> element. Ничего не мешает применять его к другим типам инпута, просто срабатывать будет не всегда ожидаемо.
Ну, сделаю я эту конкретную кнопку button'ом, дальнейшая обработка ее нажатия возможна. если она попадает в $_POST. Проверю...В пост кнопка не попадает, никак.
Если $_POST['delete_utility'] установлено,Угу, главный вопрос - ГДЕ установлено. data: {'id': data_uid} передает в запрос переменную с именем id и значением data_uid, а на стороне сервера вы ищете переменную с именем delete_utility... И (сюрприз!) не находите ее... Магия...
Делаю это с помощью isset.
Для первых двух это срабатывает, а для третьего нет, поскольку я в JS отменяю обработку click'а по умолчанию preventDefailt'ом.А? Никак вообще не связано. Тем более что в данном случае превентится не клик, а субмит формы. Если вас смущает первентДефаулт - сделайте кнопки не типом субмит, я же писал.
Делал внутри issetА какой смысл в этом действии? Просто логически подумайте - если нет ОПРЕДЕЛЕННОГО ПОЛЯ в пост массиве то ваш иф не сработает, и вы делаете внутри этого условия проверку ВСЕХ полей пост запроса, где тут логика?
Так это от корня...
Однако, если изменить в javascript data: {'id': data_uid}, и добавить в обработчик echo $_POST['id']; (внутри isset), а потом глянуть на ответ сервера в обработчике, то он пуст. А вот если echo поставить до isset, то приходит "21 json" (21 это нужный id).Ммм, программирование методом тыка... Найс )
буду разбираться дальше, как получить этот id внутри isset.Ну, как минимум понять что вы проверяете и что отправляете, зачем там это иссет и почему data: {'id': data_uid} не совсем то что нужно ).
$arr = [
0 => [
"Alex","12"
],
1 => [
"Mary","27"
],
2 => [
"Alice","12"
],
3 => [
"Jon","17"
]
];
$arr2 = [
0 => [
"Alex","some"
],
1 => [
"Jon","words"
],
2 => [
"Mary","any"
]
];Как я понял, не сохраняется сессияЭто легко проверить сделав var_dump($_SESSION); и это надежнее чем гадать. Скорее всего с логикой какая-то проблема.
"Не удается получить доступ к сайту".Это ответ браузера или ответ сервера? Смотрите в консоли раздел network - какой код ответа отдает сервер на этот запрос, скорее всего к сессии это не имеет отношения.
Ну так "нету ручек - нет печенья", вы поставили сроки - человек согласился, по факту работа не сделана, значет плюшек не будет.
В принципе - ничего не решает, по опыту - знакомые так работали лет этак 5-7 назад, задача реально писалась за пол-часа, а скрипт делал джигу-дрыгу в кодеа 4 часа, и "работа" скринилась в логи. Человеку который только примерно разбирается в коде визуально отличить от реальной работы практически нереально. Понту с такого рабочего процесса ровно ноль.
Где тут про то как скрины это решают? Тут задача чисто управленческая, что вам мешает вычесть из зп время гулянок, либо оговаривать такие вопросы отдельно? И вообще, создается впечатление что вы работаете не с удаленными сотрудниками, а с фрилансерами, но разницы не видите...