EAMann
  • 0
Гуру

Как легко перенести установку WordPress из стадии разработки в рабочую среду?

  • 0

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

Есть ли лучшие способы сделать это?

Share
  1. Для новичков в вопросе. Год спустя я все еще использую плагин @MikeSchinkel. У него есть версия 0.7, на которую я без проблем перенес пару установок. mikeschinkel.com/downloads/wp-migrate-webhosts-0.7.zip

    • 0
  2. @ Insanity5902 : Развертывание сайта WordPress из одной коробки в другую было PITA с первого дня, когда я начал работать с WordPress. (По правде говоря, это был PITA с Drupal за 2 года до того, как я начал работать с WordPress, так что проблема, безусловно, не только в WordPress.)

    Меня беспокоило то, что каждый раз, когда мне нужно было переместить сайт, мне приходилось тратить так много усилий, часто повторяющихся, и это мешало мне проводить развертывание для тестирования так часто, как я бы предпочел. Итак, около 4-6 месяцев назад я начал работать над плагином для решения проблемы миграции веб-хостинга и рассказал о своих идеях на форуме WP Tavern.

    Что ж, перенесемся в сегодняшний день, и я в значительной степени заставил его работать, и я назвал его « WP Migrate Webhosts ». Несмотря на то, что плагин все еще находится в бета-версии (возможно, даже в альфа-версии), учитывая ваш вопрос, я думаю, что готов позволить людям начать его использовать.

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

    1. сначала разработчик обрабатывает загрузку всех измененных файлов тем и плагинов через FTP,
    2. затем полностью загружает базу данных разработки MySQL на тестовый сервер и, наконец,
    3. затем запускает плагин для переноса любых ссылок из предыдущего домена в новый. (Мой плагин не пытается решить слияние новых полей или таблиц базы данных с оперативными данными; ЭТО гораздо более серьезная проблема, которую я не знаю, как решить.)

    Вы можете загрузить плагин с моего веб-сайта и разархивировать в каталог плагинов (если вы не знаете, как это сделать, то этот плагин не для вас, потому что для его использования требуется кто-то, кто знает, что он делает). держите этот плагин в сети, пока я не опубликую его на WordPress.org, после чего вы должны искать его там.

    Чтобы использовать его, вы используете другой подход в своем wp-config.php обычном режиме, комментируя четыре (4) определения DB_NAME, DB_USER и вместо этого регистрируя значения по умолчанию для веб-хостов, а затем регистрируя информацию о каждом веб-хосте DB_PASSWORD . Вот как может выглядеть этот сегмент (обратите внимание, что в первом разделе закомментирован ненужный код, а также обратите внимание, что я настроил свой файл hosts на своем локальном компьютере с немаршрутизируемыми доменами верхнего уровня, чтобы упростить повседневную разработку. На Mac VirtualHostX делает это проще простого):DB_HOST wp-config.php .dev

    // ** MySQL settings - You can get this info from your web host ** //
    /** The name of the database for WordPress */
    //define('DB_NAME', 'wp30');
    
    /** MySQL database username */
    //define('DB_USER', 'wp30_anon');
    
    /** MySQL database password */
    //define('DB_PASSWORD', '12345');
    
    /** MySQL hostname */
    //define('DB_HOST', '127.0.0.1:3306');
    
    require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
    register_webhost_defaults(array(
     'database'  => 'example_db',
     'user'      => 'example_user',
     'password'  => '12345',
     'host'      => 'localhost',
     'sitepath'  => '',        // '' if WordPress is installed in the root
    ));
    register_webhost('dev',array(
     'name'      => 'Example Local Development',
     'host'      => '127.0.0.1:3306',
     'domain'    => 'example.dev',
     'rootdir'   => '/Users/mikeschinkel/Sites/example/trunk',
    ));
    register_webhost('test',array(
     'name'      => 'Example Test Server',
     'rootdir'   => '/home/example/public_html/test',
     'domain'    => 'test.example.com',
    ));
    register_webhost('stage',array(
     'name'      => 'Example Staging Server',
     'rootdir'   => '/home/example/public_html/stage',
     'domain'    => 'stage.example.com',
    ));
    register_webhost('live',array(
     'name'      => 'Example Live Site',
     'rootdir'   => '/home/example/public_html/',
     'password'  => '%asd59kar12*fr',
     'domain'    => 'www.example.com',
    ));
    require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');
    

    Надеюсь, это (в основном) самоочевидно. Я попытался сделать код как можно более чистым, но, к сожалению, он требует этих двух загадочных require_once() строк до и после блока регистрационного кода веб-хостинга, поскольку у меня не было возможности « перехватить » WordPress до wp-config.php вызова.

    После того, как вы обновите свой wp-config.php, вы можете просто использовать ярлык URL wp-migrate-webhosts, чтобы перейти к экрану администратора, например:

    http://example.com/wp-migrate-webhosts

    Приведенное выше приведет вас к экрану администратора, подобному следующему, который имеет довольно много текста описания и позволяет вам мигрировать ИЗ любого другого домена веб-хостинга одним щелчком мыши после выбора доменов для миграции ( ПРИМЕЧАНИЕ : этот пример показывает переход ВНИЗ с тестовых/стадийных/живых серверов на локальную разработку, но будьте уверены, что он может мигрировать В любой домен, где он находится.Это также означает , что плагин отлично подойдет для использования существующего живого сайта и быстрого запуска локальной среды разработки! ):

    введите описание изображения здесь

    Если это не ясно, « миграция » в этом контексте означает обновление всех ссылок в текущей базе данных, чтобы они соответствовали текущему определенному веб-хосту (и « текущий » анализируется путем проверки $_SERVER['SERVER_NAME'] .)

    Что хорошо в плагине, так это то, что он реализует некоторые базовые миграции, но любой может подключить его и выполнить свои собственные миграции. Например, если вы добавите плагин галереи, который хранит полные пути к изображениям в базе данных, вы можете перехватить migrate_webhosts действие, которое будет передано веб-хосту « от » и веб-хосту « к » в виде массива метаданных, и вам будет разрешено чтобы выполнить все, что вам нужно сделать в базе данных, используя SQL или любые применимые функции API WordPress для выполнения миграции. Да, любой из нас мог бы сделать это без плагина, но без плагина я обнаружил, что написание всего необходимого кода требовало больше усилий, чем оно того стоило. С плагином проще написать эти крошечные хуки и покончить с этим.

    Вы также можете столкнуться с тем, что мои миграции не работают в крайних случаях, которые я не тестировал, и, возможно, вы можете помочь мне улучшить плагин? Любой, кто хочет, может написать мне по электронной почте через мою учетную запись gmail (мой псевдоним «mikeschinkel»).

    Кроме того, плагин был разработан для приема определяемых пользователем метаданных веб-хостинга в дополнение к тем, которые он распознает, например database , user , password , host , domain и т. д. Прекрасным примером может быть googlemaps_apikey то, что вы можете хранить разные ключи API для каждого домена, который требуется вашему плагину Google Maps. для правильной работы (кто из вас, кто использовал плагин Google Maps, не развернул приложение на работающем сервере и забыл изменить код на правильный ключ API? Да ладно, будьте честны… 🙂 С этим плагином элемент googlemaps_apikey в вашем массиве register_webhost() и небольшой пользовательский migrate_webhosts хук, вы можете эффективно устранить это как проблему!

    Ну вот и все. Я запускаю этот плагин здесь, на WordPress Answer’s Exchange, потому что его запустил вопрос @Insanity5902. Дайте мне знать, если это будет полезно, здесь, если это уместно, или по электронной почте, если нет.

    PS Если вы решите использовать это, помните, что это альфа/бета, и это означает, что оно будет изменено, поэтому будьте готовы к небольшой операции, если вы хотите использовать его сейчас, а затем используйте выпущенную версию, как только ее обыграют многие руки.

    PPS Какие у меня цели при этом? Мне нравится видеть, как это переносится в ядро ​​​​WordPress, чтобы каждый имел к нему доступ. Но прежде чем это можно будет даже рассмотреть, многие люди должны быть заинтересованы в его использовании, чтобы убедиться, что он действительно решает больше проблем, чем потенциально может создать. Так что, если вам нравится эта идея, то во что бы то ни стало используйте ее и помогите мне набрать обороты для возможного включения в ядро ​​​​WordPress.

    • 0
  3. Когда это возможно, я устанавливаю WP_HOME и WP_SITEURL в wp-config.php . Это, в сочетании с дампом базы данных и импортом, является самым простым из всех решений, с которыми я знаком.

    http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php

    • 0
  4. Мой любимый хак; добавьте параметр в свой /etc/hosts, чтобы производственный домен указывал на ваш блок разработки, только на вашем компьютере. Для развертывания в рабочей среде вы синхронизируете все файлы и передаете базу данных.

    Риски этой стратегии очевидны; вы можете спутать свою среду разработки с производственной средой.

    Это все еще легко исправить.

    • 0
  5. Я хотел что-то подобное, когда несколько месяцев назад переходил на WP, поэтому я написал довольно простой сценарий оболочки, который использует rsync и mysqldump поверх ssh:

    http://snarfed.org/sync_wordpress

    Это не сложный или веб-ориентированный, но я доволен этим.

    • 0
  6. WP Engine — это новый сервис, предлагающий «постановку в один клик»:

    В WPEngine есть эксклюзивная функция под названием «постановка». Вот как она работает: Прежде чем вносить пугающие изменения в свой блог, нажмите кнопку «моментальный снимок». Мы делаем полную копию вашего блога и размещаем ее в отдельном безопасном месте. Вы можете играть с чем угодно; ничего живого. Только когда вы будете готовы воплотить его в жизнь, вы прикасаетесь к своему основному сайту.

    Похоже, это очень простой способ быстро перейти от разработки к производству, особенно с уже работающим сайтом.

    • 0
  7. Плагин Duplicator: Вот плагин, над которым я работал. В настоящее время он находится в стадии бета-тестирования, но он выполняет свою работу для большинства сайтов. Прямо сейчас он предназначен для небольших установок WordPress. http://wordpress.org/extend/plugins/duplicator/

    Ресурсы: Дополнительные ресурсы для плагина можно найти здесь: http://lifeinthegrid.com/duplicator/

    Сообщество: Сообщите нам о своих успехах или проблемах, с которыми вы можете столкнуться! Чтобы упростить управление различными темами, размещайте вопросы на форумах плагинов WordPress.org. Пожалуйста, не публикуйте данные регистрации из плагина на онлайн-форумах. Данные регистрации можно отправить на наш сайт поддержки.

    • 0
  8. Вы можете взглянуть на продукт от iThemes под названием BackUpBuddy. Я использовал его только дважды, каждый раз были заминки или два, но в целом это выглядит многообещающе.

    • 0
  9. Я лично решаю этот вопрос в своем проекте на Github, который называется Autopress. У меня пока нет идеального решения, но я приближаюсь, особенно с помощью плагина wpstage от разработчиков wpengine.

    • 0
  10. Это выглядит многообещающе. Мы работаем над некоторыми сценариями для обработки переноса некоторых данных, например, wp-options, изменения путей в базе данных, копирования через носитель.

    У меня проблема в том, что живой сайт продолжает расти, в то время как другой находится в разработке. На одном сайте, над которым мы работаем, ежедневно размещается 20 постов и более 3000 комментариев. Это слишком много данных для перемещения с помощью phpmyadmin или через командную строку. Кроме того, перемещение данных по какой-то причине всегда вызывает проблемы с UTF.

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

    Я проверяю весь свой код в SVN и развертываю код через FTP с сервера (Beanstalk). Это не вносит изменения в БД для меня и не активирует новые плагины.

    Мой план прямо сейчас состоит в том, чтобы создать файл манифеста, пока я разрабатываю, чтобы внести все свои изменения в работающий сайт.

    Например, файл будет иметь удобочитаемые строки.

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

    Как только я протестировал это и был уверен, что все получил, я мог быть уверен, что это будет работать на производстве.

    Этот плагин все еще только идея, но у меня есть код, написанный для него.

    Кроме того, если вы хотите внести изменения только в URL-адрес в своей БД, вы можете использовать следующий SQL.

    просто замените $old$ на старый домен и $new$ на новый

    update wp_postmeta set meta_value = replace(meta_value, '$old$' , '$new$') ;
    update wp_posts set post_content = replace(post_content, '$old$' , '$new$') ;
    update wp_options set option_value = replace(option_value, '$old$' , '$new$') ;
    
    • 0
  11. По состоянию на 2017 год я нашел два лучших способа переноса базы данных WordPress из разработки в производство.

    WP Migrate DB Pro / WP Синхронизация БД

    https://wordpress.org/plugins/wp-migrate-db/

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

    • Экспортирует вашу базу данных в виде дампа данных MySQL (так же, как phpMyAdmin)
    • Находит и заменяет URL-адреса и пути к файлам
    • Обрабатывает сериализованные данные
    • Позволяет сохранить его на свой компьютер в виде файла SQL

    Я сторонник того, чтобы мне платили за работу, поэтому я рекомендую вам поддержать г-на Брэда Туэснарда и купить лицензионную копию настоящего продукта. WP Sync DB является репликой, и в результате она всегда отстает в поддержке. С этим плагином процесс предельно прост:

    1. Установите/активируйте плагин на вашем локальном хосте и в производственной среде.
    2. Настройте push-передачу с вашего локального хоста/сервера разработки на вашу продукцию.
    3. Заполните правила для переноса таблиц и определите правила поиска и замены для выполнения.
    4. Вот и все!

    Поиск и замена баз данных для баз данных WordPress от InterconnectIT

    https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

    Этот бесплатный инструмент не является плагином, он устанавливается в корневой каталог вашей производственной установки WordPress. Это не так хорошо, как WP Migrate DB Pro, потому что требует нескольких ручных шагов, но, тем не менее, это отличный вариант, который стабильно работает. При использовании этого подхода процесс выглядит следующим образом:

    1. Сделайте резервную копию вашей локальной базы данных, это абсолютно необходимо, так как мы скоро будем повторно импортировать ее.
    2. Добавьте скрипт в папку в корневом каталоге установки.
    3. Запустите поиск и замену в вашей базе данных
    4. Экспортируйте свою базу данных и сохраните ее для своей производственной среды.
    5. Повторно импортируйте резервную копию с шага №1, чтобы восстановить свой локальный хост.
    6. Подключитесь к вашей производственной базе данных и создайте ее резервную копию (как вы всегда должны делать, прежде чем делать эти вещи)
    7. Импортируйте экспорт, который мы сделали ПОСЛЕ запуска процедуры поиска/замены с шага № 4.

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

    • 0
  12. Два проекта Google Summer of Code, преследующие схожую цель:

    • 0
  13. Я использую команду экспорта subversion для установки файлов WordPress (http://core.svn.wordpress.org/tags//), а также всех плагинов в репозитории (http://plugins.svn.wordpress.org//tags). //), затем просто заархивируйте тему и пользовательские плагины и установите их в обычном режиме. Как только все это запущено и работает без контента, я экспортирую тестовую БД и выполняю поиск/замену URL-адреса И пути к файлу (хранящегося для мультимедиа) и импортирую в пустую базу данных, а затем просто переключаю информацию базы данных в wp-config.php. Обычно у меня уходит около 10-20 минут.

    • 0
  14. Обычно я вхожу в phpMyadmin, загружаю базу данных и редактирую содержимое wp_options>siteurl и wp_options>home на ожидаемый домен. Если вам нужно обновить URL-адреса в ваших сообщениях и содержании страниц, вы можете выполнить поиск/замену URL-адреса и пути мультимедиа/загрузки в файле.SQL перед загрузкой. Это быстрая работа.

    • 0
  15. Хотя здесь нет недостатка в хороших решениях, в духе обмена я решил добавить свой скрипт развертывания bash в кучу: https://github.com/jplew/SyncDB

    SyncDB — это скрипт развертывания bash, предназначенный для облегчения синхронизации локальной и удаленной версий сайта WordPress. Это позволяет разработчикам, работающим в локальной среде (например, MAMP), быстро «отправлять» или «извлекать» изменения на свой производственный сервер или с него с помощью одной команды терминала.

    Этот сценарий хорошо работает с WP-Skeleton Марка Джакита и использует mysqldump, git а rsync также для синхронизации всего вашего сайта — базы данных, кода и мультимедиа — в два простых шага:

    ./syncdb
    git push hub master
    
    • 0
  16. Я использую http://wordpress.org/plugins/wp-clone-by-wp-academy/. Он прекрасно работает!

    Всего 3 шага:

    1. Установите плагин на оба сайта.
    2. Используйте плагин для создания резервной копии на старом сайте.
    3. Возьмите резервный URL-адрес, который он вам дает, и подключите его к странице плагина на новом сайте, нажмите «Перейти», и ваша миграция будет завершена всего за несколько секунд!

    Он автоматически настраивает все URL-адреса, включая замены сериализованных строк, поэтому нет риска потери конфигураций виджетов и т. д.

    Единственные проблемы, с которыми я столкнулся, связаны с некоторыми веб-сайтами с большими базами данных (~ 300 МБ), что вызывало тайм-ауты выполнения скрипта PHP во время импорта резервной копии сайта.

    • 0
  17. так как я запускаю свои сайты в IIS (я также запускаю asp.net, поэтому мне нужны окна), я использую WebPI из Msft для установки нового экземпляра, затем копирую шаблон и использую импорт/экспорт для передачи данных.

    Это не идеально, но все это занимает меньше часа.

    Очевидно, было бы неплохо иметь решение в один клик, но это то, что мне показалось самым простым.

    • 0
  18. Еще одно платное решение: платформа тем Xtreme One выпустила версию 1.2 с Xtreme Backup, которая позволяет вам «экспортировать или импортировать настройки ваших дочерних тем, макетов или виджетов со всеми их настройками/содержимым в виде XML-файла».

    • 0
  19. Коллега нашел это. Интересная концепция, хотя похоже, что она не работает на разных серверах. Я все еще изучаю его, но похоже, что он отлично подойдет для промежуточного экземпляра.

    http://code.google.com/p/deploymint/

    • 0
  20. Этого, возможно, не было, когда вы задали вопрос, но я использую службу под названием Blogvault в течение пары месяцев, и она делает это безупречно. Я, наверное, сделал более 50 миграций (между доменами, поддоменами и веб-хостами), без заминок и совсем не занимая времени.

    Это платная услуга (за домен в месяц), но не так уж много.

    • 0
  21. RAMP — это новый плагин для развертывания контента от Crowd Favorite, и он выглядит очень стильно. Это 250 долларов, так что я еще не пробовал. Однако может просто окупиться за сэкономленное время, так что я рассматриваю это.

    Большое преимущество, которое он имеет по сравнению с большинством других упомянутых методов, заключается в том, что он может разумно объединять сообщения, комментарии и т. д. Это не просто импорт mysqldump, это больше похоже на систему управления версиями для базы данных. Например, при развертывании сообщения будут также развернуты теги для этого сообщения, если они еще не существуют в рабочей среде.

    • 0
  22. Позвольте мне отдать один из моих любимых 🙂

    // proven local<->live codefork (covers local network testing, i.e. from mobile devices):
    $GLOBALS['is_local'] =  
        in_array( $_SERVER['REMOTE_ADDR'], array("127.0.0.1","::1")) || // simple localhost (IPv4 IPv6)
                  $_SERVER['HTTP_HOST'] == 'local.workblog'          || // call by local name (adjust)
           substr($_SERVER["REMOTE_ADDR"],0,8) == '192.168.';           // (mobile) device in local network
    
    $table_prefix  = NULL; // ensure scope
    
    if ( $GLOBALS['is_local'] )  // LOCAL fork ------------------------
    {
            ....
    }
    else  // STAGE/LIVE fork -------------------
    {
    

    … и затем вы работаете свой путь оттуда. ИМЯ_БД, ПОЛЬЗОВАТЕЛЬ_БД… префикс_таблицы. Лично я включаю ALTERNATE_WP_CRON на локальном компьютере (чтобы избежать некоторых надоедливых предупреждений ), WP_DEBUG на обоих (если вы не разработчик) или только на live (если вы), другой ini_set('display_errors', '0'); для live также может быть полезен, и, наконец, муравей, как упоминалось выше: WP_HOME и WP_SITEURL на соответствующий локальный/фактический URL-адрес.

    Это почти все, ничего не осталось кроме классического WordPress «Все, прекратите редактировать!» линия…

    192.168. часть позволяет вам проводить локальное тестирование (например, с планшетов или телефонов) в вашей локальной сети)

    $GLOBALS[‘is_local’] также может пригодиться при разработке вашей темы для дополнительного вывода отладочной информации и т. д.

    • 0
  23. Я уже давно использую плагин backupbuddy. Это позволяет вам сделать резервную копию базы данных и всех файлов, загрузить их в виде zip или отправить непосредственно на другой сервер через FTP. Он также находит и заменяет URL-адрес для вас. Обычно на весь процесс у меня уходит около 5 минут. А поскольку все файлы заархивированы, процесс загрузки/выгрузки происходит намного быстрее. И нет, я не работаю на них, но этот плагин действительно значительно упростил весь этот процесс.

    • 0
  24. Еще одним полезным инструментом для обработки миграции серверов для сайтов является интерфейс командной строки WordPress. В этой статье содержится хороший обзор того, что он может сделать, но, в частности, раздел «Поиск и замена» полезен для поиска всех ссылок на старый / dev URL-адрес сайта. :

    Расширенное управление WordPress с помощью WP-CLI

    • 0
  25. Это самый простой способ: https://themes.artbees.net/docs/website-migration/
    Это займет всего два клика. Один на экспорт, один на импорт.

    Это возможно с помощью плагина All in one WP Migration. Ссылка выше показывает, как его использовать.

    • 0
  26. Если вы пытаетесь добиться непрерывной синхронизации, я предлагаю использовать rsync вместе с пользовательским заданием cron для перезаписи любого URL-адреса или данных, специфичных для сайта.

    • 0
  27. После того, как я некоторое время следил за этим ответом, я создал свой собственный небольшой плагин — Pitta Migration. Причины:

    1. Из всех опробованных здесь идей самая простая это WP_HOME и WP_SITEURL варианты
    2. Затем я использую их для установки двух совпадающих wp_options URL-адресов, которые охватывают случаи, когда плагины/темы игнорируют эти
    3. Это дает мне 100% уверенность в том, что меняется в моей базе данных.
    4. Это также работает кросс-платформенно (все эти bash-скрипты плохо работают в Windows)
    5. Легко понять, что делает плагин
    6. Там нет конфигурации, кроме двух констант — сделайте mysqldump и импорт mysql в вашу локальную базу данных, и плагин увидит, что константа и таблица отличаются, и обновит их, чтобы они соответствовали
    7. Нет текстового поиска и замены
    8. Нет шансов взломать вашу базу данных — я использую объект базы данных WordPress для двух обновлений и ничего больше
    9. Он отлично сочетается с такими вещами, как WordPress Skeleton, где вы можете иметь все в системе управления версиями и устанавливать локальную конфигурацию.
    10. Я поместил его в каталог плагинов WordPress и на Github, так что он бесплатный, полностью с открытым исходным кодом, его легко разветвить и легко установить.
    11. Как только он установлен, вы можете забыть об этом, и он должен «просто работать» — он дает вам небольшое уведомление о том, что база данных была изменена.
    12. Он должен работать с любым процессом резервного копирования / FTP / восстановления.
    • 0
  28. На мой взгляд, самый простой способ, которым я следую, — это перенос вручную. Просто скопируйте папку wp-content и файл wp-config.php на новый хост. Экспортируйте базу данных со старого хоста и импортируйте ее в новую базу данных нового хоста.

    В базе данных нового хоста перейдите в таблицу wp-option и измените URL-адрес сайта и URL-адрес блога на Новый адрес хоста со старого хоста. например с http://localhost/wp на http://example.com

    Теперь в файле wp-config просто измените информацию о базе данных и пользователе на новую информацию о хосте.

    Теперь войдите в новый wp-admin, перейдите в настройки и сохраните постоянную ссылку.

    Вы сделали. Я думаю, что это просто без использования каких-либо плагинов.

    Я пробовал разные плагины, и у всех у них много проблем.

    Поэтому я предпочитаю эту простую ручную передачу, которая, как мне кажется, проще.

    • 0
Оставить ответ

Оставить ответ

Browse