Сергей Ермилов

Недавно тоже столкнулся с данной проблемой на нескольких проектах, когда в WordPress при сохранении черновика появляется надпись "updating failed. you are probably offline" (рус. - обновление не удалось). И да, эта проблема часто возникает у тех, кто пользуется Gutenberg.

Кроме решения от ТС в виде обращения к Хостеру ниже напишу пару вариантов решений от себя.

Буквально недавно я каким-то образом проникся Gutenberg, хотя всё предыдущее время постоянно ставил плагин "Classic Editor", который возвращал старый добрый вордпрессовский редактор. Для решения "updating failed" пришлось копать весь Google, но большинство решений сводилось к тому, чтобы установить плагин "Classic Editor" и не мучиться.

Но скажем честно, классический редактор - это костыль. Так как со временем все перейдут на новый Gutenberg, т.к. он удобнее априори. Итак, если вы хотите быстрое решение в виде костыля - бежим и устанавливаем плагин Classic Editor.

Ну а тем, кто хочет разобраться - я подскажу направление куда копать. Реальная проблема заключается в SSL и здесь два варианта:

1. Установлен непонятный SSL
   
2. Криво сделана переадресация на HTTPS.
   

Первый вариант - редкий и скорее всего для решения достаточно написать хостеру и попросить проверить всё ли нормально с сертификатом и правильно ли он установлен. Если хостер скажет, что всё окай, то переходим ко второму варианту.

Второй вариант заключается в том, что есть, скажем так, конфликт переадресаций. Обычно после установки WordPress на сайт с SSL в настройках мы прописываем HTTPS, плюс у WP есть внутренняя умная переадресация. Но также есть редирект на сервере с HTTP на HTTPS. И когда всё настроено криво, то при редактировании статей мы получаем ошибку "Mixed content", которую можно увидеть в консоли (например):



Какие действия можно предпринять?

1. После установки SSL на сервер мы прописываем в настройках (Настройки -> Общие) адрес Адрес WordPress (URL) и Адрес сайта (URL) с HTTPS.

2. Можно более жестко прописать в корне сайта в файле wp-config.php строки:

define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/');

Если вы пропишете эти строки, то не сможете редактировать адреса через настройки.

3. Устанавливаем плагин Really Simple SSL и активизируем его. Включаем редиректы в нем.

4. Далее мы можем прописать в файле .htaccess следующие строчки:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
</IfModule>

Зачем они нужны? Очень часто при установке SSL и настройки переадресации с HTTP на HTTPS мы забываем делать переадресацию, например, с WWW на без-WWW, т.е. когда URL https://www.site.ru редиректит на https://site.ru. Эти строчки выше прописываются в htaccess с этой целью.

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

Есть все в документации. Важно понимать про позиционирование и работу relative и absolute. Пример расположения текста по четырем углам и по центру.

Стили:

.container {
  position: relative;
  text-align: center;
  color: white;
}

.bottom-left {
  position: absolute;
  bottom: 8px;
  left: 16px;
}

.top-left {
  position: absolute;
  top: 8px;
  left: 16px;
}

.top-right {
  position: absolute;
  top: 8px;
  right: 16px;
}

.bottom-right {
  position: absolute;
  bottom: 8px;
  right: 16px;
}

.centered {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

HTML:

<div class="container">
  <img src="imgage.jpg" style="width:100%;">
  <div class="bottom-left">Низ, слева</div>
  <div class="top-left">Верх, слева</div>
  <div class="top-right">Верх, справа</div>
  <div class="bottom-right">Низ, справа</div>
  <div class="centered">По центру</div>
</div>

Такие вещи уже разбирались на Стэке. Хорошим способом сделать это будет использование toggleClass и размещение обертки вокруг содержимого.

Код, который можно использовать для примера:

$(document).ready(function(){
    $(".collapsed").click(function(){
    $("#coverthishere").toggleClass("coverall");
    });
});

Пример на fiddle.

Используется класс меню collapsed в качестве триггера. И цель - ID coverthishere, чтобы добавить/удалить класс .coverall.

Смена домена. Через PHPmyAdmin запускаем SQL (меняем URL на свои):

UPDATE wp_options SET option_value = replace(option_value, 'http://domain.ru', 'http://newdomain.ru') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'http://domain.ru','http://newdomain.ru');
UPDATE wp_posts SET post_content = replace(post_content, 'http://domain.ru', 'http://newdomain.ru');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://domain.ru','http://newdomain.ru');

По поводу главной и других страниц:

Нужно зайти в "Настройки" в Админке, потом "Постоянные ссылки" и просто нажать "Сохранить изменения".

Реализация (пример) по ссылке - jsbin.com/jojoqu/2/edit

Субъективно бы сделал так:
1. Создаем на сервере поддомен (new.site.ru)
2. Копируем туда все файлы
3. Создаем копию БД
4. Прописываем данные от копии БД в скопированных файлах
5. Если нужно - правим htaccess
6. В файлах меняем через БД адрес сайта на новый (new.site.ru вместо site.ru)
7. Убираем ненужные скрипты

1. С большой долей вероятности проблема с Базой Данных. Вы переносили сайт недавно? Создавали сайт и БД? Импортировали может быть БД?

Попробуйте отредактируйте wp-config.php и добавить:
define('WP_ALLOW_REPAIR', true);

Затем нажмите на URL "ремонта" базы данных (но прежде не забудьте сделать бэкап):

SITE/wp-admin/maint/repair.php

2. Такое бывает на мультисайтах.

3. Еще попробуйте стандартный способ с отключением плагинов.

4. Проверьте functions.php темы на проблемный код.

Вы можете использовать функцию get_current_user_id() и использовать её на всех активных элементах для отслеживания:

<?php $user_id = get_current_user_id(); ?>
<a href="/my-plugin-url<?php echo $user_id; ?>">View/Download plugin</a>

Или просто использовать в ссылках:

https://www.example.com/somepage/?userid=12

Считается, что это не всегда безопасно и на 100% точно, т.к. некоторые "умные люди" любят копировать ссылки и удалять лишнее.

Может быть есть смысл задавать переменную сеанса для отслеживания доступа к вашему сайту после авторизации пользователя.

На зарубежных сайтах предлагали такое решение:

1. создать GUID-значение, уникальное для этого пользователя после входа в систему и сохранить его на сеанс
2. создать другие нужные переменные
3. связать GUID с другими переменными
4. добавить это значение к URL-адресу
5. дать посетителю URL-адрес
6. когда пользователь нажимает на URL-адрес проверяем значение GUID с переменной сеанса, чтобы убедиться, что оно совпадает с GUID в URL

Если всё ок, то ок, а если нет - если нет пишем посетителю предупреждение/сообщение об ошибке с просьбой войти в систему и повторить попытку.

GUID может быть легко скомпрометирован, поэтому сделайте его длиной в 40 символов. Генераторы GUID можно нагуглить.

Храните его в качестве переменной сессии, тогда он будет доступен пользователю до тех пор, пока он остается на вашем сайте.

Неправильно настроен хостинг или что-то неверно указали в htaccess.

Вы можете добавить в конец htaccess:

Options -Indexes

И на всякий случай для того, чтобы директории не открывались нужно добавлять index.php пустой, который есть во многих папках самого Wordpress с таким содержанием:

<?php
// Silence is golden
?>

Просто по ссылке (195.245.112.137/1.mp3) браузерный плеер работает корректно.

У вас по ссылке в коде контроллер video:

<video controls="" autoplay="" name="media"><source src="http://195.245.112.137/mp3.php" type="audio/mp3"></video>

Почему так?

Можно попробовать стандартный метод:

$myAudioFile = "myAudiofile.wav";
echo '<audio autoplay="true" style="display:none;">
         <source src="'.$myAudioFile.'" type="audio/wav">
         <source src="'.$myAudioFile.'" type="audio/mpeg">
      </audio>';

Или так:

<?php 
    $file = file_get_contents('/audio/file_0.mp3'); 
?>
<audio src="data:audio/mp3;base64,<?php echo base64_encode($file); ?>"></audio>

Изучил API 2Gis, вот это вот skin=dark работает только для элементов управления. Вам, скорее всего, хотелось перекрасить всю карту в темный цвет (как ночью), но это скорее всего в API не заложено, это пользователь выбирает в настройках.

Вы можете поиграться на Codepen, где сейчас стоит light и описание маркера на светлом фоне, а меняете в URL скрипта на Dark и описание маркера становится темным:



Для пользователя же их приложения есть 4 режима:

1. Как в приложении
Навигатор и приложение 2ГИС всегда будут работать с одними настройками. Если тёмная тема включена в приложении, то она будет действовать и в навигаторе. Если выключить тёмную тему в приложении, она автоматически отключится в навигаторе.
2. Автоматический
Тёмная тема будет включаться автоматически после захода солнца и выключаться — после восхода.
3. Включён всегда
4. Выключен

Если смотреть по вашему скрину, то непонятно зачем вам изменять /wp-json, т.к. он и должен быть в noindex.

Если вопрос в общем, то этот тег может задаваться на уровне:
1. SEO плагин Wordpress
2. robots.txt
3. на уровне сервера

Обычно и довольно часто в robots.txt можно найти такую директиву (или очень похожую):
Disallow: */wp-json/*

Дальше смотреть на целесообразность запрета.

Есть Flexi и User Post Gallery – UPG

Непонятно, что вы имеете ввиду - стили или функционал характеристик для растений?

Если вы про стили - то можно таблицей. А если про функционал, то тут есть два простых варианта:

1. Использовать Woocommerce просто как каталог без корзины и возможности продажи товаров. И тогда вы просто выбираете подходящий шаблон и настраиваете Woocommerce.

2. Использовать "Произвольные поля". Подробнее можно прочитать здесь.

Можно попробовать:

<?php 
 $catsy = get_the_category();
 $myCat = $catsy->cat_ID;
    wp_list_categories('orderby=id&child_of='.$myCat); 
?>

Скорее всего спасет просто чистка кукис в браузере.

Также можно добавить вот это в wp-config.php:

define( 'ADMIN_COOKIE_PATH', '/' );
define( 'COOKIE_DOMAIN', '' );
define( 'COOKIEPATH', '' );
define( 'SITECOOKIEPATH', '' );

Также в интернете есть мнение, что проблема связана с переадресацией и SSL, некоторым помогла эта строка:

define( 'FORCE_SSL_ADMIN', true );
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
	$_SERVER['HTTPS'] = 'on';
}

Ну и еще может быть стоит добавить вот эту строку в functions.php:

add_filter( 'wc_session_use_secure_cookie', '__return_true' );