Да, по субботам могу :)
О! Мы теперь введем новую переменную - форма приобретения кода. Т.е. если кто-то сторонний заказывает написанный код, то он уже не является авторским т.е. "само написанным программистом", а обретает какое-то новое качество и свойство.
В связи с этим вопрос - а заказанная с нуля CMS по требования заказчика - это самопис, CMS или заказанный скрипт?
А вот этот написанный вами комментарий? Он сапопис или невамипис?
До абсурда можно довести любую идею. Стоит только выдернуть из контекста и начать жонглировать уточняющими вопросами 😉
На момент когда вы это личном писали, это был самопис.
И раз вы его писали, вы скорее всего это делали потому, что в нужной вам мере не было необходимой штатной функциональной возможности.
Да будем вам. Все предельно прозрачно. Либо в админке в пользовательском режиме можно это сделать, либо нельзя.
Это и есть штатные возможности.
Всё что дополнительно костылится - внештатные. Вот и вся принципиальная разница.
Зависит от бизнеса его условий, его фактической локации и прочих обстоятельств, которые в том числе касаются разработки, бюджетов и руководства.
Как выше отметил Владимир - для Яндекса приоритетны поддомены, если есть фактическая возможность закрепить региональность. В этом смысле возможность регионального ранжирования через поддомены это ключевая точка роста для прогнозируемого трафика.
Безусловно есть и конечно все их длинным списком и подробными объяснениями излагать вряд ли будут.
Ключевые моменты в аффилированности (хотя Яндекс сейчас на это закрывает глаза), в дублированности контента (потому что как чаще всего товарный набор один и тот же во всех регионах), в региональной структуре, если она имеет необходимость.
Здесь много нюансов на стыке офферов и товарных элементов, но разбирать всё это имеет смысл только применительно к конкретике бизнеса.
Обсуждать особенности у некой умозрительной бизнес конструкции - это всё равно, что натягивать невидимые штаны на сферического коня в вакууме - спора и дискурсов c какой стороны это делать - масса, а полезности - ноль.
Владимир правильно вам намекнул - желаете сделать всё правильно, наймите опытного специалиста. Желаете разобраться самостоятельно - пробуйте, делайте и в конкретике рабочих данных задайте более конкретные вопросы.
Так более вероятно получить более точные и предметные советы.
Главной вопрос - для чего?
Оказать психотропное воздействие на потенциального противника НАТО?
Ну мы то точно знаем, что земля не плоская, поэтому этот абсурдный тезис рассматривать не стоит, а вот то, что у ряда программистов есть свои суждения в отношении того, что PHP не в полной мере является языком программирования и на это есть веские основания - это любопытно.
Но сейчас эту тему я обсуждать не хочу, это просто как дополнение к неочевидным особенностям.
Хорошо :) Тогда на всякий случай я обозначил свою, раз уж я себя им назвал :)
Пожалуйста.
Штатная функциональность это явные рабочие решения, определённые возможностями движка на уровне доступных пользовательских изменений через административную часть, либо дополняющие административные элементы.
Например, в штатной функциональности заявлено, что в административной части можно производить заполнение мета данных OpenGraph и при этом есть соответствующие поля, где в пользовательском режиме можно их активировать и заполнить.
При этом заполнение может быть уникальным, а может быть рекурсивным.
Вот это штатная функциональность.
Когда я вижу, что в административной части CMS не поддерживается работа с OpenGraph данными, я вижу, что нет у движка такой штатной (т.е. заранее определённой) возможности. И тогда я формирую ТЗ программисту, чтобы он это реализовал, если в этом есть рабочая необходимость.
Здесь могут быть варианты. Это штатная возможность может быть реализована в базовой версии, а может быть предусмотрена через установку доп. плагинов и компонентов.
Если вы просто переключаете плагины и темы, то их общую совокупность можно назвать штатными функциональными возможности. Но если мы рассматриваем какую-то базовую часть движка вне функциональных дополнений, то штатными функциями будут только те, что обеспечивает базовый движок.
Cюда же можно добавить мнение, что PHP не является полноценным языком программирования.
В чём странность?
Определённая штатными возможностями CMS.
Полагаю, что это описка и вы имели ввиду "стили".
Да, в этом смысле я и отвечаю не предыдущее замечания, что в широкой трактовке даже изменения CSS уже будет своего рода "самописом".
Давайте посмотрим, какое определением предложит нам поиск,
Пожалуй, соглашусь.
