Alexey Epsilon

Да, писал на базе PHP. Основной идеей была модульность и автоматическое отслеживание изменений.

1) Какой системой вдохновлялись или брали за образец?

Никакой, считал все остальные CMS "недосистемами", недостойными подражания.

2) Писали ли к ней инсталятор или предполагался другой способ установки?

Нет, предполагалось, что это PHP скрипт, который начинает работать сразу после установки.

3) Какой использовали визуальный редактор для админки? Один из 2 известных, что-то другое, или свой?

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

4) Была ли у неё какая-то специализация - магазины, визитки, лендинги, что-то ещё?

Нет, модульность подразумевала полную универсальность.

5) Разделяли ли ядро и дополнительные модули?

Да, ядро было небольшим, весь функционал был (предполагался) в модулях.

6) Предусматривалась ли какая-то система шаблонов? (юзали ли шаблонизатор или на php)?

Да, в качестве шаблонизатора для страниц можно было использовать plain-php или smarty-шаблонизацию.

- Ну и если есть ссылки на репозитории кидайте кому не стыдно показать если в открытом доступе у вас.

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

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

Нужно было просто посмотреть существующие CMS и использовать одну из них. Жаль потерянных лет.

Таблица users, в ней все пользователи. Таблица clients, в ней все клиенты всех пользователей.

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

Второй вариант - когда каждый клиент может быть прикручен к нескольким пользователям. Тогда нужно завести ещё одну таблицу users_clients, в которой будет два поля user_id и client_id. Каждая запись в этой таблице прикручивает одного любого клиента к одному любому юзеру (вариант М:М).

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

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

Объект в ООП - это замкнутая в себе законченная сущность, с которой можно работать дёргая за рычажки - методы. Это позволяет абстрагироваться от того, что происходит внутри объекта. Удобно, например, в случае с вашей галереей, представить одиночное изображение как объект и получать из него всякие свойства, такие как imageUrl (путь к изображению), запускать ресайз изображения (resizeImage) и всё такое прочее, совершенно не думая о том, как это всё внутри сделано.

Аналогично, если всю галерею представить как объект, можно работать с ней через её методы, например, получить список всех изображений через getAllImages(), выбрать только популярные через getPopularImages() или реализовать более мощную функцию с возможностью отбора по параметрам getImages($params), добавление новых изображений через addImage($img) (при этом в коде галереи будет содержаться весь код, необходимый для сохранения изображения в БД и на диске, формирования статической ссылки и всё такое прочее.

Можно создать несколько галерей простым вызовом new MyGallery() и быть 100% уверенным в том, что галереи никак не будут мешать друг другу в работе.

Научитесь думать в ООП-стиле и ваша жизнь в корне изменится.