roman1981, историю вопроса не пробовали изучить прежде чем задавать глупый вопрос в паблике? Этот сертификат будет получше многих платных. А лохотронами всегда успеете воспользоваться, если совестливые люди окончательно переведутся на этом свете.
Я писал не в общем, а как это работает в наших движках :) Если использовать тип/метод сравнения для полей БД, в которых хранятся адреса/слаги, отличный от BINARY/чувствительного к регистру, то даже при хранении в БД слага в виде Articles и автоматическом приведении слага из входящего запроса к articles сравнение этих слагов будет давать положительный результат.---------- Добавлено 17.02.2018 в 00:27 ----------P.S. Другое дело, что лучше так не делать, если у вас где-то на сайте выводится Articles без приведения к нижнему регистру (как обычно и происходит), потому что это будет вызывать лишний редирект Articles -> articles при переходе по ссылке.
Оптимальный вариант – избавиться от множественных точек входа, убрав все лишнее за пределы паблик каталога. Можете просто делать рерайт /papka/ в /foprfjefhoefvh/papka/index.php при наличии соотв. файла. В обоих случаях редирект, если вы по-прежнему будете в нем нуждаться, делается достаточно легко.
Если без предварительной оптимизации, то подобный редирект обычно делается при помощи mod_rewrite и условия с переменной THE_REQUEST.
P.S. Полное отсутствие дублей не означает, что редирект нужно посылать лесом. Эстетство и пользовательский фактор при ручной расстановке ссылок (распространенные неточности, которые можно поправить редиректом) никто не отменял. Например, у нас даже в самых простых движках верхний регистр корректируется автоматом без лишних телодвижений (читай «без сравнения с оригинальными адресами»): http://g09.ru/Articles (большие буквы запрещено/не рекомендуется использовать в адресах; «не рекомендуется» – это когда даже если ты напишешь большую букву и она сохранится, все равно будет работать приведение к нижнему регистру с положительным результатом, хотя конечно тут есть риск лишнего редиректа при переходе по внутренним ссылкам, если они будут выводиться без принудительного понижения регистра; надеюсь, кто-нибудь поймет, что я написал :) ).
search_user, одно другому не мешает. Опускать canonical допустимо, если движок оч. круто заточен в плане SEO и не допускает дублей (чего не скажешь о поп. движках). Иногда бывает нужно специально сделать дубли, чтобы поучаствовать в рекл. компании, собрать стату и т.п. Тогда нужно (хотя бы временно) проставить canonical даже в круто заточенном движке.
Вы про этот сайт?
WP тут без надобности. Пробелы в адресах – это конечно оч. криво, но в принципе допустимо. Подойдут простейшие скрипты для натягивания статика. Можно даже попробовать использовать первый % для структурного деления адреса.
Я в общем-то про это же. Большинство увидит тут Reply-To и проигнорит наши приписки по поводу необходимости тщательной валидации мыла, перед тем как пихать его в заголовок. Если даже не проигнорит, то велик шанс, что сделает криво. Поэтому лучше размещать в содержимом. Кто умеет норм. размещать в заголовке, в наших советах не нуждается.
Тупиц не держим. У нас обычно доставка подобных сообщений идет с ящика noreply, а в Reply-To, адрес для отскока (Return-Path при приеме) заносится адрес того, кто в случае чего может надавать по башке нерадивому менеджеру. В Web-интерфейсе яши, маши достаточно кликнуть по мылу в содержимом, чтобы сформировать заготовку для ответа.
Гораздо проще размещать пользовательское мыло в содержимом.
С последним абсолютно согласен. Рюшечки абсолютно ни к чему для доставки сообщений с сайтов. У нас часто даже подписи к значениям полей не используются. Если полей много, то обычно в мыло включается только несколько идентификационных полей, а полная копия данных остается на сайте.
Между вариантами нет никакой разницы.
Что касается основного вопроса, опыта нет. Адресацию нужно продумывать заранее и в дальнейшем не менять ее кардинально. Также не нужно выбирать движки, которые не позволяют воссоздать имеющуюся адресацию.
