Да, само собой имена всех инпутов должны быть заточены под передачу массивом, то есть кончаться на []

Так как вы копируете целую строку таблицы, крутить безумное решение о том что-бы скрипт находил все id в таблице и добавлял или изменял их, бессмысленно.
Вопрос такой, не возникают ли у вас проблемы с name в чекбоксах.
Потому как при клонировании, 2 строчки с чеками будут работать как единый механизм не давая выбрать 2 элемента в этих двух строчках.

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

Если интересно, объясняю.

На самом дело идет об админке на сайте.
Менеджер должен ввести цены на отель.
Отель имеет основной тип размещения - одноместный, двухместный и пр.
Это одна таблица htl_cost_types.
Еще есть дополнительный тип размещения - стандарт, делюкс, супериор и пр.
Это другая таблица htl_room_types.
То есть одноместный может быть как стандарт, так и супериор и т.д.
А может и вообще не иметь дополнительного типа. Просто - одноместный, двухместный и т.д.
Цены хранятся в третьей таблице, которая имеет, в частности, поля: htl_cost_type_id и htl_room_type_id.

Так вот. На страницу выводятся в таблице ВСЕ основные типы размещения с соответствующими чекбоксами, и в той же строке есть селект для выбора дополнительного типа, в котором присутствуют все доп. типы.

В этой же строке кнопки "+" и "-". Добавить строку или удалить.

К примеру менеджеру нужно ввести тип DBL и еще раз DBL, но уже с типом супериор.
Он копирует (вернее клонирует) строку DBL и в клонированной строке в селекте выбирает доп. тип "супериор".

В итоге вся проблема в том, что $_POST передает ВСЕ селекты, которые даже имеют value="", но не передает чекбоксы, которые непомеченные.

В итоге для сохранения данных в таблице цен пары "основной" и "дополнительный" тип размещения не совпадают, поскольку передаваемые ПОСТ массивы имеют разные ключи.

Чтобы ключи совпадали, мне надо передать в скрипт ВСЕ, даже пустые значения чекбоксов. Для этого вставляю дополнительный input Hidden value="" с тем же name.

Но теперь массив дополнительных типов бодет больше основных, поскольку при добавлении строки массив доп. типов включит и новый Hidden.

Именно поэтому мне нужны уникальные id, чтобы при пометке чекбокса спрятать соответствующий ему Hidden (style="display: none")

Сумбурно объяснил, но как сумел.

Может, это и криво, но я вижу только такой вариант.

Второй вариант, который был бы более простым - сделать так, чтобы непомеченный select (Ну, в первом option которого, скажем, выводится --- НЕТ ---, не передавался в скрипт. Тогда всю остальную мутотень можно и выкинуть на фиг.
Но лично я не представляю, как это сделать.
Вот и пришлось мудрить... :)

Этого было бы достаточно, чтобы понять цель. :) А если Добавить, то клонирование существующих полей формы не годится. Нужно добавлять "чистые поля", и все, которые необходимы для добавления новых данных. И не значение id нужно увеличивать, а индексы полей или же в случае, если дынные привязываются какому либо идентификатору, то копировать в новые добавляемые поля эти идентификаторы, в случае же добавления новых записей, то временный идентификатор, диапазон которого зависит от максимального значения первичного ключа.

Попробуйте написать если и не универсальное на все случаи, но хотя бы в рамках этого администрирования, если вставка нужна не только для данной задачи. А делать это лучше так, например, пусть сам тег формы или иной удобный родитель содержит html-код вставки. Не времени все подробно пояснять, поэтому кратко:

1) html-код вставки - описывает полностью структуру "строки" в форме в которая добавляется, а не только поля формы. То есть, например, если элементы формы находятся в ячейках таблицы, то вставляемый код будет: <tr><td><input name="name(k1:)[]"></td>td><input name="name(k2:)[]"></td>...</td>.

2) :k1:, :k2:,... условно значения имен, ключей и т.п., которые после вставки нужно заменить значениями.

3) кнопка добавления новой строки в атрибутах data должна описывать замещаемые значения и значения на которые они будут замещены. Например, data-rem=":k1:,name1/:k2,<?=$id?>:",...
Подобным образом задаются любые иные параметры, которые необходимо изменять, добавлять или же передавать как значения в функцию, как и содержать ссылки на функции, которые нужно выполнить, если нельзя написать универсально для любой вставки, и требуется выполнение неких специфичных функций.

4) если имена привязываются к первичному ключу/ключам, это означает, на значение сверху наложен лимит. Поэтому вставка должна иметь счетчик, значения которого используются при вставке, и ссылка на счетчик указана в data-rem.

5) html-код вставки храниться также в атрибуте data-ins, а кнопка "Добавить" имеет ссылку на этот атрибут, по ins. то есть вставляемых "html_вариаций" может быть сколь угодно, как и кнопок добавления, каждая из которых будет добавлять свой html-код. При чем вставляемый html-код также может иметь кнопку "Добавить" - добавление внутри добавляемого.

6) кнопка "Добавить" также должна иметь атрибут содержащий указатель родительского элемента в который вставляется код. В примере с таблицей, это будет например, data-prt="table".

7) вставляемый код содержит кнопку "Удалить" содержащую указатель на удаляемого родителя, для пример это будет data-prt="tr".

Непосредственно спрятать в атрибут data html-код не получиться, поэтому можно прибегнуть к base64, но лучше url кодирование, значения будут короче. То есть типа <form data-ins="<?=rawurlencode(вставляемый html-код)?>", а на клиенте в обработчике кнопки "Добавить" получать его - decodeURIComponent(this.getAttribute("data-ins")). Если все обдумать, то единый обработчик будет добавлять любой html-код на страницу, параметры которого описаны в атрибутах.

Laimas. Интересно. Но я сейчас добью первый вариант из принципа. Если будет ок, то пусть уже менеджеры начнут работать. А потом спокойно разберусь с Вашим вариантом. Если он будет проще и правильнее - заменить - как два пальца :)

Есть еще один вариант. Простейший. Но самый тупой :) Вообще без скриптов.
Вывести все основные типы размешения и рядом все доп.типы.
Если учесть, что основных типов штук 100, а дополн тельных штук 50, то получим таблицу в 5000 строк :) А если еще учесть, что из них в каждом отеле надо выбрать в среднем 3-5, то у менеджера это займет кучу времени. Потому и заморочился... :)

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

Согласен, что плодить лишнего не надо.
Если бы речь шла о конечном пользователе, то я бы вылизал все, что можно.
А работники - им главное чтобы ввести данные.
К сожалению, со вчерашнего дня не смог работать. С завтрашего утра начну.
Там посмотрим, чья правда.

Кстати. В данном случае про аякс не понял. Что я должен от него получить?
У отеля нет вообще никаких данных в БД. Какой php скрипт мне что выдаст?
Я только собираюсь забить в БД данные и выбираю, какие. Упс.
Получить данные об основных и дополнительных типах размещения?
Да они у меня вот уже есть. Бес всякого аякса. Простым sql запросом.

То есть даже не знаем и структуры данных, а форма для их приема тоже нечто абстрактное? Ответ сервера, это не обязательно данные из базы.

Это потому что у вас там колхоз. Вы даже слова такого не знаете - datagrid - которую вы и делаете. В качестве годного примера - phpMyAdmin видели? - это datagrid в основе. Само собой термин тянется небось с микрософта, я не проверял, но так все кто пишет называют эту интерактивную таблицу.

Теперь про колхоз. Пустые чекбоксы не successful элементы и конечно не приходят с браузера на сервер вообще. Что никак не мешает опознать отсутствие по наличию модели. Скрипт обработки данных "знает" что должно быть и если его нет - ставит не выбрано, null, 0, или значение по умолчанию.

Еще про колхоз. Размножать инпуты вообще не обязательно. Их можно подставлять по координатам выбранной строки - как в том самом PMA и делается и делается это в общем-то довольно просто. Как тогда отгружать? Ну либо сразу аяксом - по кнопке сохранить или какому-то явному событию, или собирать все добавленные и обновленные данные в json и отгружать через одно текстовое поле, на сервере декодировать и с колес юзать без мороки с постами всякими там.