Алеандр

А в БД тоже ежедневные изменения структуры? Сомнительно. Если же только файлы, то один раз сделать копию БД для тестов, для файлов данных создать симлинки. Остальные, изменяемые часто файлы переложить в другую папку, назначить другой поддомен на них, закрытый не просто в роботс, но и банальной Basic Auth на уровне апача и с этой копией работать.

Выглядит это так: 2 рядом расположенных папки рабочего домена и поддомена для тестов. Все глобальные картинки, аплоад файлы и тд, чаще всего лежащие в папке upload - их сделать линками, так будет работать, но тягать туда-обратно не придется. Остальные файлы тем - обычные файлы. Файл конфигурации и база - разные. Обычно она нужна только для данных и тестов на ней. Делается копия и из поддомена смотрится в нее.

После тестирования изменений в файлах шаблонов или движка достаточно перезалить эти файлы в соседнюю папку с реальным доменом и ничего мигрировать не нужно.

Конечно, все зависит от сложности постоянных изменений, но для ежедневных очень сомнительно, что переписывается все подряд и сразу много.

Для душевно больных, ослабить их муки, но укрепить веру в несуществующее.

С подсознанием нужно и можно работать, но не в таком виде "на случай", а создавая реальный соответствующий настрой на достижение результата, при этом обязательно работая над внешним собой. А лежать на диване и посылать сигналы в космос на полном серьезе - это уже клиника )

Текст внутри блока отзывов содержится исключительно в поле

data-elfsight-testimonials-slider-options

и при этом зашифрован в единую строку, потому простым поиском по странице не находится.

%7B%22template%22%3A%22singlePostcard%22%2C%22layout%22%3A%22slider%22%2C%22sliderArrows%22%3Atrue%2C%22sliderDrag%22%3Atrue%2C%22sliderSpeed

Боты поисковиков, конечно, выполняют JS уже давно, но это совсем не означает, что они этот текст будут считать полноценным текстом на странице. По факту - могут учитывать, в реалиях - как на душу положат. Если этот текст важно учитывать в поиске, то имеет смысл его все же дублировать на странице как нормальный текст.

Давным давно перестал туда что-либо публиковать, так как эффекта было всегда ноль. Тем более, что они уже полноценно запустили Турбо, собирая контент другим, более удобным для них способом и в текстах уже нет для них смысла. Собственно, еще тогда была мысль, что это не ради подтверждения авторства, а для сбора "чистых" текстов на дальнейшую обработку.

Мобильную всегда можно подправить, тем более у вас есть основной адаптив. Единственное, что смутило, не проверял на мобиле, но в эмуляции кнопка каталога наверху почему-то не жмется. Это бы проверить, ну может еще где-то что-то по мелочам.

В вашей тематике, мне кажется, не так много трафика и объема заказов, а значит и сильно там гнаться за новым функционалом незачем. Для CMS главное, чтобы апдейты безопасности этой версии были установлены. Если с этим нет проблем, то все новое - враг устоявшегося.

Лично как по мне, если я бы переживал за позиции - я бы ничего глобально не трогал, делал только доработку адаптива. В противном случае результаты могут быть какие угодно. Принцип "не трогай, если работает" - никогда еще не подводил ) Да и по себе сужу, чем больше я делаю современных примочек в угоду ПС, тем хуже позиции они дают. А смена урлов-шаблонов - всегда провал на какое-то время и хорошо, если потом хотя бы вернется на свое место.

В общем фиг знает, я бы лишний раз подумал, так ли важны плюсы, которые будут получены сменой версий и шаблона в соответствии с возможными рисками. Если плюсы перевешивают риски - то менять, если они мифичны, то оставлять как есть и просто доработать адаптив, если вызывает сомнения.

Подайте на неустановленного владельца домена иск. Сделайте копию и отправьте гуглу, что вы подали на владельца домена в суд, но эти данные не разглашаются и владелец для вас анонимен. Больше этого вы вряд ли сделаете, а если владелец домена не регистрировал на свои реальные данные - то вы их вообще не узнаете, ибо домен может висеть на Пупкине. Если это гугл не удовлетворит, то опять же, через суд - признавать сайт нарушающим авторское право и через РКН добиваться его блокировки без участия поисковиков. Ну или с судебным решением потом к хостеру и регистратору домена. Или хостер заблочит, или регистратор затребует проверку данных и в итоге удалит домен.

Я не юрист, но при чем тут отчество? К примеру, издательские дома прекрасно подают в суд и потом в РКН на блокировку сайтов с нарушением контента даже без имени владельца домена. Просто на домен, владелец которого нарушил их подтвержденные права.

Вот и вам нужно по примеру издательств подать в суд на владельца сайта с нарушением, подтвердив все ваши притязания. Это и требует гугл, показать, что вы подали иск, а не на словах говорите, что это мое.

Судя по его варианту, как должно быть:

$newArray = [
0=>{0,0,0 ...одни нули (склеиваем подмассивы где только нули и которые идут подряд)},
1=>{0,0,1 ...есть единица (склеили подмассивы в которых есть единица и которые идут подряд},
2=>{0,0,0 ...одни нули (склеиваем подмассивы где только нули и которые идут подряд)},
]

ваш вариант не подойдет, ибо он соберет все только в 2 массива, а ему нужно свести только пограничные.

Вообще все по-другому написал, потому у тебя получилось сколько на входе, столько и на выходе, чего не должно быть при слиянии одинаковых нулей и единиц. Количество массивов на выходе должно стать меньше. По твоему коду будет совсем не то.

Вон выше дали еще пример, только я задачу понял немного иначе. В моем случае будут массивы схлопнутые по нулям и единицам, а в примере выше будет всего 2 массива, содержащий нули и содержащий единицы.

prevtmp=2;
foreach oldarray
if in_array(1,subarr) { tmp=1} else { tmp=0 }
if tmp!=prevtmp {
newarr[] = subarr; prevtmp = tmp }
else {
array_merge subarr+last elem newarr }