FanatPHP

Так вам же и написали: более подробную информацию можно найти в логе ошибок.

Подсказка: у посетителей сайта тостер.ру доступа к логам твоего сервера нет.

Первое, что надо узнать - ЗАЧЕМ тебе это нужно - " делать автоинкремент только тогда, когда он добавил реально запись"? Какая тебе разница, какое значение у этого поля?

Отвечать подробно

Чувак, тебе сюда: www.freelansim.ru

Странный вопрос. Не понимаю, что здесь надо учить?
Неужели с бэкграундом явы код на РНР не читается как открытая книга?
По-моему, проблема языка высосана из пальца.

Если речь о внедрении в рабочий процесс, то это к языку имеет весьма опосредованное отношение к языку.
Если вопрос по конкретным CMS, то учить надо конкретные CMS - знание языка здесь не поможет.

Ну и, разумеется, по доброй традиции, все ответы - только на заголовок вопроса. Отвечатели на тостере такие отвечатели.

Жалоба на вопрос: вопрос ведет к дискуссии или спору.

Надо просто подумать.
Взять и представить мысленно, чем отличается
site.com/region/section/13?page=1
от
site.com/region/section/13

И потом подумать, как из первого получить второе.

Мне кажется, верстальщику вообще не нужно знать РНР.
Особенно учитывая, что доля шаблонов на чистом РНР страмительно сокращается в пользу специализированных языков шаблонизации - Smarty, Twig, Blade.

Все что нужно - это уметь отличать верстку от операторов, управляющих динамическим содержанием АКА логикой отображения. Но это обычно и так видно - любая конструкция, которая не ХТМЛ тег - это логика, и в неё верстальщику лезть не надо.

Учитывая выбранные теги (казалось бы - какая связь между исполнением задания на сервере и запросах из браузера?), порекомендую освоить базовые принципы работы с БД. Которые несколько отличаются от принципа работы привычного каждому школьнику линейного списка АКА "классный журнал".

В базе данных, помимо прочего, можно фильтровать записи по какому-либо признаку.
В частности, для того, чтобы не выводить какую-то запись, её совершенно не обязательно удалять физически - достаточно всего лишь поставить условие в запросе.

Попробуй - тебе обязательно понравится.

вместо php_flag пиши php_admin_value

И не забудь исправить ошибки.

Для начала желательно оценить осмысленность задачи.

Как уже написали выше, совершенно непонятно, зачем здесь веб-технологии вообще.
Откуда такое требование - обязательно рисовать таблицу в браузере? Почему нельзя нарисовать её в бычном окне?
Учитывая, что GRID в браузере - это совсем не так трививально.

Плюс городить целый веб-сервер в нагрузку к маленькому приложению - это и вовсе за пределами моего понимания.

Я на всякий случай поясню: веб-технологии используются, когда доступ к данным требуется обеспечить неограниченному кругу клиентов. Для этой цели устанавливается веб-сервер, доступный из сети, коорый все данные харнит у себя, и выдает или сохраняет их по запросу.

Если же надо вывести таблицу для редактирования и сохранить результаты на диск, то рекомендую использовать MS Access, или что там сейчас вместо него.

Вопрос не очень понятен. О какой куке речь? Как она связана с сессией?
О какой сессии речь? О сеансе работы с сайтом или о РНР сессии?
Если речь о той куке, в которой передается идентификатор сессии, то её вообще не надо руками трогать, оставив все параметры по умолчанию, в том числе и всремя жизни.
В этом случае время жизни куки будет выставлено в 0, и кука будет жить ровно столько, сколько длится сессия - не больше и не меньше.

Если все же залезть шаловливыми ручонками в настройки и выставить время жизни куки в 15 минут, то РНР сессия умрет вместе с кукой, разумеется.

Если остались вопросы, то сначала обязательно прочитать, что такое сессии

unity_ultra_hardcore++

Плюс, если дело именно в работе над одним и тем же файлом, то я бы предложил декомпозировать этот файл, разделив его на модули, чтобы разные программисты могли работать каждый со своим файлом.

А ты пробовал?

Обращение к элементам объектов и массивов не имеет ни малейшего отношения к теме SOAP и WSDL.

К свойству объекта обращаются так: $obj->svoistvo
К элементу массива обращаются $array[index], но обычно массивы перебираютс с помощью foreach()

И что - принимающий сервер не принимает?

Если речь о 20-и строках, то вопрос о скорости не имеет смысла. Можешь делать в базе, можешь в скрипте, а можешь попеременно - на скорости это никак не скажется.

В целом же, для нормальных, а не микроскопических баз данных, любую фильтрацию надо делать только в базе.

Поиски же более быстрого решения надо производить только тогда, когда текущее тормозит.

Неправильно.
Правильно будет так:
1. пишем в адресной строке браузера mysqli_fetch_assoc
2. В открывшемся окне переходим по первой ссылке
3. Внимательно читаем.
4. Думаем.
5. Смотрим примеры.
6. Пишем правильный код.

Странное условие. Чтобы написать такое "без фреймворков", надо, по сути, написать одноразовый фреймворк, который всю эту красоту - "использование паттернов, namespace, PDO" и реализует. (Впрочем, ПДО здесь лишний - хороший код никогда не будет использовать прямое обращение к DB API, а завернет такие обращения в абстракцию).

Плюс, само понятие "хорошего кода на ПХП" в 2014 году включает в себя непременное условие "с использованием фреймворков".

Но если хочется так прям говнокодить по-старинке, но думать, что используешь правильные паттерны - www.phptherightway.com