Сделать значения списков справочниками

[iAndroS]

Создаю новый тип контента, бесконечно вношу в него правки. Значения списков хранятся в базе данных в виде нулей и единиц, при изменении списка приходится вносить изменения в каждой записи типа контента, что не просто утомляет, а способно убить все желание КМ работать над проектом. Полагаю, данное изменение позволит решить массу других задач, которые сейчас невозможно решить со списками, а именно - внесение новых значений с фронта прямо при редактировании записи, настроить сортировку значений без утери уже созданных записей, сделать фильтр в виде текстового поля с автокомплитом, выводить свойства записей в виде иконок и т.д. и т.п., а также применять различные действия, в зависимости от каждого определенного значения.

[fuzegit]

В чем предложение то, не очень понятно? Много букв и возмущения, а сути мало. Полагаю, судя по многим вашим предложениям, мы должны решать задачи вашего сайта. Этого не будет. Если есть общее предложение, в контексте CMS, то и стоит об этом писать.

Значения списков хранятся в базе данных в виде нулей и единиц, при изменении списка приходится вносить изменения в каждой записи типа контента, что не просто утомляет, а способно убить все желание КМ работать над проектом.

Значит у вас неверный подход к решению вашей задачи в контексте CMS.

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

Для этого значения нужно хранить в таблице в БД. Очевидно, что существующие поля эту задачу не решают.

[iAndroS]

В чем предложение то, не очень понятно? Много букв и возмущения, а сути мало.

Предложение в заголовке поста. Я не возмущаюсь, а предлагаю решение возникающих проблем, которые ограничивают возможности движка. Просто кто-то пилит молча свои костыли, у кого хватает знаний, а кто-то держит просто статейники либо пользует готовые компоненты для решения своих задач, не пользуясь в полной мере дополнительными полями и фильтрами. Я же пытаюсь реализовать свои задачи максимально из коробки. По сути, мой проект будет самым наверное показательным в возможностях движка, не без сторонних, само собой, доработок, но максимально использующий заложенные в нем возможности. И то, что я постоянно упираюсь в какие-то ограничения движка, не говорит о том, что я одеяло тяну на себя, а лишь о том, что ранее никто не протестировал в полной мере функционал, либо же не пытался реализовывать в боевых условиях, возможно, упираясь в те костыли, в которые упираюсь я сейчас.

Если есть общее предложение, в контексте CMS, то и стоит об этом писать.

Когда я вношу какие-то пожелания, я предварительно обдумываю их реализацию не только на своем примере, а и для всеобщего удобства использования CMS. Прикидываю, чем мое предложение может быть полезно для других проектов и как это упростит пользование сайтом его посетителям (в первую очередь думаю о них, потому как планируется UGC-проект).

Значит у вас неверный подход к решению вашей задачи в контексте CMS.

Сто вариантов уже обдумал решения своих задач. Они решаемы, но каким образом, это другой вопрос... И все равно не все ((( Большинство моих предложений направлены именно на улучшение юзабилити движка и его универсальности. Понимаю, что у вас другие планы на развитие, но мое дело, что называется, предложить...

Для этого значения нужно хранить в таблице в БД. Очевидно, что существующие поля эту задачу не решают.

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