Так это понятно. Управление содержимым, включая создание-удаление "объектов хранения", действительно может выполнять обычный пользователь (качество подготовки содержимого в расчет не беру, здесь тоже нужны определенные навыки). Но этим управление не ограничивается. Возьмите хотя бы установку или обновление системы.
Я написал, что нужно сделать, чтобы "быть честным с пользователями".
Не люблю CMS на файлах из-за их ограниченности. Но лайк поставил. Для создания визиток пойдет.
Это медленно. Даже если использовать обратный прокси с короткими ответами (без содержимого) от фонового обработчика, все равно сложно получается. Можно кэшировать в файловой системе под теми же "адресами", чтобы Web-сервер сам выводил кэш.
Может. В некоторых системах я использую такой подход. Имя каталога как раз совпадает с идентификатором пользователя.
Все зависит от конкретной системы. Что у вас, я так и не понял.
Да, переименование - это в общем случае хорошо, чтобы минимизировать в именах кириллицу и т.п., но полагаться только на id, особенно если они числовые, все-таки плохо.
А как без расширения будет определяться Content-Type? Или вы свой файловый сервер написали, который "подтягивает" метаданные из базы данных? 😃 Проще запретить чему-либо выполняться там, где хранятся загружаемые файлы.
Это утопия. В лучшем случае из-под рук таких пользователей будет выходить что-нибудь монструозное. И это при условии, что сам инструмент получится более-менее годным. Правда, сайты бывают очень разные. Что-нибудь простое и "обвязанное" шаблонами можно сделать. Но я, например, выбрал бизнес-модель, когда пользователи самостоятельно управляют только содержимым и подключением крупных модулей, а во всем остальном полагаются на разработчиков и поддержку.
Слишком абстрактный вопрос. Давайте конкретнее.
Уберите target="_blank".
А чтобы самому выводить страницу "Спасибо", не нужно предоставлять пользователю возможность управлять переходом на другой сайт. Если речь об API стороннего сервиса или если у него есть соответствующий API, нужно программно выполнять обращение к сервису (на сервере или на клиенте), обрабатывать ответ и выводить, что нужно.
Если сделано, как полагается, т.е. на основе Web-сервера, то напрямую ничего нельзя сохранить. Только через админку или SCP/SFTP-клиент, либо локально установленный редактор, имеющий функцию (модуль) подключения к серверу. Также можно через сетевую файловую систему отредактировать файл или сохранять измененную копию файла на сервере под тем же именем.
Распространенный SCP/SFTP-клиент упямянут в этом сообщении: https://searchengines.guru/ru/forum/1107755/page5#comment_17066350 (и можно целиком тему прочитать для расширения кругозора).
Для этого и нужна переадресация. Для офлайн- и частично онлайн-рекламы можно будет использовать COM, пока аудитория не созреет.
Не нужно бояться использовать New gTLD как таковой при наличии переадресации с gTLD или ccTLD. Единственное существенное ограничение я вам назвал - стоимость может быть очень нестабильной (или какой-то другой сюрприз от регистратуры). При этом уже есть хорошо зарекомендовавшие себя регистратуры, например Радикс. В крайнем случае можно будет сменить главное зеркало.
Если вы не пользуетесь услугами специалистов и сами не имеете соответствующей компетенции, есть риск возникновения путаницы у аудитории из-за неуместного использования одного из доменов. В этом случае используйте COM и забудьте про красивый/более короткий New gTLD в качестве основного домена. В крайнем случае потом опять-таки можно будет сменить главное зеркало.
