Вот именно что админ-панель хо.юа для всех поддоменов использует htdocs.
Может, там для каждого (под)домена свой htdocs или можно поменять имя корня. Вам однозначно нужно разносить корни сайтов на домене и поддомене (иное имеет место только в мультисайтовых движках). Все вменяемые хостинги позволяют это сделать более-менее логичным путем. Если хостинг не вменяемый, лучше свалить с него как можно быстрее. (Добавление)
Может, тариф какой-то сильно урезанный, поэтому не доступен нормальный способ создания второго сайта. Не скупитесь. Лучше заплатить больше, чем внедрять в основу работы сайтов какую-то хрень.
1.Кукисы некрасиво - т.к. их согласно закону DSGVO можно устанавливать только с
разрешения клиента и он может от них отказаться либо стереть в любой момент.
Не понял зачем и почему гет некрасиво, но если не подходит, то попробуйте через сессион.
А «сессион» типа к «кукисам» не имеет никакого отношения? (Добавление)
milov пишет:
Или как можно ещё получить полную ссылку с которой перешли?
Для реализации функционала на своем сайте добавляйте адрес или какой-то идентификатор бэка в адрес целевой. Если строка Get-параметров не нравится, можно использовать концовку адреса, включая путь (но не ограничиваясь одним путем, если у бэка есть строка Get-параметров), например:
/ид_часть_целевой/адрес/бэка?в=целевой
Все это тормоза. Хотя бы посмотрели, как устроены др. серверные шаблонизаторы. В них шаблоны на языке шаблонизатора переводятся в нативные. Нативные тоже каждый раз не парсятся, а хранятся в бинарном, готовом к выполнению виде.
Лично меня использование нативных вообще не напрягает. Имеет смысл что-то изобретать, если у вас шаблоны будут писать домохозяйки, которым опасно давать прямой доступ к php-скриптам.
В свойствах сетевого адаптера. Плюс в маршрутизаторе жестко привязать, если в сети есть «конкурирующие» за этот IP компы. (Добавление)
Ну, и конечно в настройках виртуального хоста прописать, если используется разделение по IP, а не только по имени на любых IP. (Добавление)
mnpartner пишет:
http:// localhost/имя проекта
Это кстати дебилизм серверных сборок. Вменяемые проекты могут вообще не «укладываться» без танцев с бубном в отдельную адресную ветку/папку корня. Об этом мы говорили с don.bidon'ом на др. форуме.
Т.е. вы правильно делаете, что используете для каждого проекта отдельный хост. Но нафига использовать отличный от локального IPшник? Можно делить по портам или по имени хоста. Чтобы добавить доп. имена к локальному IPшнику, используйте файл hosts (или локальный DNS-сервер, если он УЖЕ установлен и вы умеете его настраивать).
Это другое. И тема вообще не про редиректы. Хорош оффтопить. (Добавление)
P.S. Для яши с гошей и делают только один. А если ты кардинально меняешь адресацию, например переезжаешь на др. домен и одновременно с этим меняешь внутр. адресацию (чего лучше не делать), то для этого есть спец. инструменты, например: http://u75[dot]ru/parking-filters http://u75[dot]ru/direct-redirect
До 3 вкл. норм. Но в общем, да, чем меньше, тем лучше.
DlTA пишет:
2) привести строки к нужному регистру (/Аи или /аИ это разные страницы)
3) при переходе на ссылку /Аи нужно делать 301 с переходом на /аи и помним про правило 1
Так привести к нужному или понижать? Тут надо выбрать один из вариантов (Добавление)
Кириллицу в адресах сложнее обрабатывать (приводить к нужному регистру, понижать регистр), поэтому ее лучше совсем не использовать.
По идее должно быть два редиректа. Один фильтр на уровне Web-сервера для коррекции имени хоста (отбрасывания www.) и избавления от трэйлинг-слешей. Другой для понижения регистра и избавления от оставшихся множественных слешей. Простой вариант его реализации показан в статье по ссылке из соседней темы. (Добавление)
Редиректы форума прошу не учитывать
В принципе, все срабатывает, но есть одно "но". Мне не нужно, чтобы, например, после перехода на index.php или magazine.php в адресной строке не отображался сам "index.php" и "magazine.php".
А в стартовом посте было нужно ;)
surin.89 пишет:
И вообще я правильно понял про единую точку входа и двигаюсь в правильном направлении?
Location – это внешний редирект! А мы пока что говорили только о внутреннем! В моей статье внешний редирект используется для автоматической коррекции тайпин-адресов, т.е. похожих по написанию. Вы сначала с основой разберитесь, а потом уже будете доп. плюшки прикручивать.
Осн. смысл единой точки входа – делать в ней все то, что вы в стартовом посте пытались делать в конфиге сервера (т.е. роутинг), и даже больше. Роутинг подразумевает подключение (файлов) частных обработчиков, а не внешний редирект по адресам с их именами. Если вы по слагу mag просто подключите (include/require) файл magazine.php, в нем будут доступны переменные $url[2], $url[3], если соответствующие компоненты пути существуют. Если не существуют, то при обращении к этим переменным будет возникать ошибка. Прежде чем что-то использовать в коде, нужно проверять доступность этого, например можно проверить кол-во (count) элементов в $url ;) (Добавление)
И сразу предостерегаю от кучи блоков вроде
Смысл вам помогать? Я в соседней теме вам подробно расписал, как сейчас делают ЧПУ. А вы опять подсовываете нам древность, на которую все спецы уже давно забили и забыли, что там и как. Идите на серч и т.п. Там такие вопросы до сих пор актуальны
Мжет, тупо пересечение правил? Про флаг L почитайте. (Добавление)
Некоторые сейчас используют автоматический роутинг прямо по БД:
А зачем массивы данных передавать в скрипт, вообще не понятно. По слагу-селектору выбирайте данные из БД. Можно взять фронт, упомянутый в статье. Он может в том числе и данные автоматом выбирать.
Про favicon и т.п. см. там же. Нужно перед запуском фронта поставить условие, чтобы при наличии соотв. файла фронт не запускался. Либо отдавать в том числе и favicon скриптом. Там же в комментах это когда-то обсуждали.
Обрабатывать переходы по «ссылке php» действительно нужно? Если нет норм. бэков, забейте. Будут только плюсы. (При норм. реализации единой точки входа «ссылки php» сами по себе не возникают.)
админка не работает, в браузере пишет так:
Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /htdocs/maia/maia_core.php:590
Это у вас древний код. Понижайте версию пыха на хостинге. И думайте о переходе на новое ПО.
Consul пишет:
каким-то чудом догадался поменять параметры mysql_xxx на mysqli_xxx
и админка стала спрашивать пароль, пускать и даже как-то работать,
но! не видно ни одной страницы для редактирования
Мдяяя... Сам себе программист что ли? Тогда все переписывай!
LIME, для обновления тоже обычно используется PUT. PATCH – это для более сложных способов обновления: https://tools[dot]ietf[dot]org/html/rfc5789 (первый абзац). Когда ты реально выполняешь частичное обновление, желая сократить трафик и т.п.
Если в контексте API, то понятно. Я пока до curl и REST API не дошел
К чему тогда эти вопросы? Именно там это плотно используется. Даже если вы делаете это на JS, как выше написали, считайте, что у вас в рамках сайта работает API.
Пых без хирургических инструментов плохо поддерживает доп. методы, например не разбирает PUT-параметры. Нужно страдать фигней вроде той, что выше показали, а ведь параметры в добавок могут быть переданы не в URL-формате!
Идемпотентность – это когда одинаковые запросы приводят к примерно одному и тому же результату. Например, когда ты PUT-ом пишешь одни и те же данные, ты обновляешь один и тот же объект, а когда POST-ом, то типа каждый раз создаешь новый (дополнительный), т.е. копию предыдущего, но с др. идентификатором. Это все каноны. Конечно, можно и по-другому. Например, у нас много адаптированных API исключительно под GET/POST. Только совсем уж не перегибайте палку. Например, я ржу-не-могу, когда вижу, как пытаются удалять GET-ом (по ссылке). (Добавление)
Perun пишет:
но создавать новую сущность или нет - определяет же логика в процессе обработки данных?
Да. Но там многое завязано на адресацию. Типа GET/POST не достаточно для полного CRUD'а с типичной REST/HTTP-адресацией. Например:
GET /objects – получить данные/список объектов коллекции;
PUT /objects – обновить (собственные) данные коллекции;
DELETE /objects – удалить коллекцию;
а теперь вопрос: Как создать новый объект данной коллекции? Правильно,
POST /objects
В принципе глаголы PUT/POST можно было легко поменять местами, но для определенности решили их использовать так.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 129
Бюджет какой?
Тут надо выбрать один из вариантов 
