Михаил Жабко, а что вы понимаете под словом "администрировать"? Имхо, на одном сервере (тем более мелком) держать много сайтов не есть ок. Это раз. Два - все начальные действия по разворачиванию проекта должны быть scriptable и автоматизированы чуть более чем полностью:
раз и создал базу данных
Это должен создавать скрип развертывания, который висит на хуке composer - post-root-package-install или post-create-project-cmd. Вместе с юзером и привилегиями. Действие одноразовое.
раз и создал сайт
Что входит в понятие "сайт"? В моем понимании сам сайт это код из репозитория + данные. Конфиг nginx? Смотрим предыдущий пункт про БД. Но вообще конфиг руками править наверняка придется, у каждого сайта свои нюансы могут быть.
раз и создал пользователя ssh
Во-первых, нет "пользователя ssh", есть просто пользователь системы, который может подключаться по ssh. А во-вторых создавать кучу пользователей на сервер - дело ненужное. Те, которые реально нужны - админ/девопс, www-data и deployer - "системные" (кроме первого) и делаются на начальном этапе настройки сервера, раз и навсегда. Сервер должен быть закрыт для модификации напрямую, раздавать доступ всем подряд - не ок.
и всё друг с другом связано когда через панель создаешь
Что именно и с чем связано?
А если ручками, то нужно права прописывать
Какие права и чему надо прописывать?
Время - вот самый бесценный ресурс
Совершенно верно. Поэтому все эти вещи должны быть, как я уже писал, scriptable и автоматизированы чуть более чем полностью.
А при помощи панели можно экономить время.
В принципе, если у вас сервачок с кучей своих проектиков, клиентских сайтов с посещениями 20 человек в месяц + там же вы ставите всякие экспериментальные проекты, показываете клиентам текущую работу и тд - тогда да, панелька вам нужна и она реально сэкономит кучу времени. Или же вы предоставляете услуги shared-хостинга. Тогда да (впрочем, тогда вы бы использовали Cpanel). Во всех остальных случаях - нет, от слова совсем.
Михаил Жабко, а зачем вся эта свистопляска с поддержкой DNS, FTP, почтовых серверов, XMPP, кучей версий PHP и HHVM, пользователей разных ролей, apache и nginx рядом, вебалайзеры всякие, квотирование... Зачем это все на небольшом (и тем более микро) серваке для одного/нескольких проектов, которые к тому же управляются одним разработчиком? Это все и есть ресурсы, которые разбазариваются налево и направо, совершенно необдуманно.
Aleksandr Yurchenko, ну вы же понимаете, что на самом деле только спрятали ссылки из меню, а по прямой ссылке все равно можно перейти и все будет работать? И кстати зря не пользуетесь - с ним один раз разобраться, научиться делать свои секции и контролы, и дальше очень удобно туда пилить всю кастомизацию сайта для клиента. Быстро делается на этапе разработки, клиенту очень удобно визуально все настраивать c предпросмотром.
Ярослав, вы неправильно делаете, не понимая суть id в базах данных. ID записи (строки) в БД - это внутреннее свойство, на которое вам опираться в ссылках не нужно. Для ссылок есть slug, который вы можете устанавливать на свое усмотрение.
Boris Korobkov, нет, в одно время человек имеет 1 паспорт (или по 1му паспорту разных типов - внутренний и загран, в некоторых странах). В случае замены происходит именно ЗАМЕНА, старый паспорт теряет свою актуальность и по хорошему должен быть заменен в БД на новый. Хранить неактуальные паспорта нет необходимости если только вы не паспортный стол. В вопросе нету конкретного требования хранить несколько паспортов, такое допущение может только выплывать из наличия свойства documentType. В этом случае, если ваше предположение верно, то связь будет oneToMany конечно же.
WP_Query принимает массив параметров, одним из которых вы можете передать тег / массив тегов, посты с которыми следует исключить из результатов. Подробнее о всех параметрах WP_Query смотрите в документации.
Не путайте теплое с мягким. Функция is_admin() возвращает true если вы находитесь в админке, а не залогинены под админом. Это разные вещи. Если вы залогинены как админ, но находитесь на фронте сайта, то функция вернет false.
Антон Дымов, Для начала укажите с каким конкретно виджетом вы работаете. Возможно у него есть нужный хук и вообще не надо ничего делать. Это раз. Два - чтобы запилить свой виджет (если это таки понадобится) нужны знания PHP и понимание OOP. Писать виджет за вас никто не будет, это задача для фриланса.
WebDev, нет. Вы сами можете использовать на нескольких компьютерах - дома (стационарный + ноутбук), на работе и тд. Ровно до тех пор, пока это ваши компы и вы сами за ними работаете. Передавать лицензию другому человеку - это уже нарушает лицензию. Вы же вопрос тогда изначально четко ставьте - могу ли я дать соседу поюзать мою лицензию (или купить одну на двоих изначально). Юридически - нет, не можете. Но вы же спросили совершенно другое - можете ли вы сами пользоваться на разных компах. Это - разрешается.
Это должен создавать скрип развертывания, который висит на хуке composer - post-root-package-install или post-create-project-cmd. Вместе с юзером и привилегиями. Действие одноразовое.
Что входит в понятие "сайт"? В моем понимании сам сайт это код из репозитория + данные. Конфиг nginx? Смотрим предыдущий пункт про БД. Но вообще конфиг руками править наверняка придется, у каждого сайта свои нюансы могут быть.
Во-первых, нет "пользователя ssh", есть просто пользователь системы, который может подключаться по ssh. А во-вторых создавать кучу пользователей на сервер - дело ненужное. Те, которые реально нужны - админ/девопс, www-data и deployer - "системные" (кроме первого) и делаются на начальном этапе настройки сервера, раз и навсегда. Сервер должен быть закрыт для модификации напрямую, раздавать доступ всем подряд - не ок.
Что именно и с чем связано?
Какие права и чему надо прописывать?
Совершенно верно. Поэтому все эти вещи должны быть, как я уже писал, scriptable и автоматизированы чуть более чем полностью.
В принципе, если у вас сервачок с кучей своих проектиков, клиентских сайтов с посещениями 20 человек в месяц + там же вы ставите всякие экспериментальные проекты, показываете клиентам текущую работу и тд - тогда да, панелька вам нужна и она реально сэкономит кучу времени. Или же вы предоставляете услуги shared-хостинга. Тогда да (впрочем, тогда вы бы использовали Cpanel). Во всех остальных случаях - нет, от слова совсем.