カテゴリー別アーカイブ: WEB制作

Xserverでドメイン変更とWordPressサイト移転した方法

Xserver内で新規ドメインを取得して、ドメインの変更をし、サイトを7つほど新規ドメインへの移転をしてみました。

わりとすぐにできるかと思いきや、いろいろと設定項目や問題が発生し、結構数日にわたり設定や反映を考慮しなくてはならなくなりました。

 

1.ドメイン変更の時に注意したいこと

・ドメイン取得タイミング

・WordPressの導入方法

・WordPressのデータ移管方法

・メールアドレス

・日本語URLページのリダイレクト

・データベースの命名

・その他

 

とかなり注意項目があり、WPテーマやデータ形式、構造などがそれぞれことなるサイトが複数ある場合、結構骨の折れる工程になりました。

次にそれぞれの工程について個別に説明していきます。

あくまでひとつの方法や考え方なので、この通りが一番良いともいえないので、参考程度にしてもらえるとよいかもしれません。

 

2.ドメイン取得のタイミング

複数サイトの場合は、3~6ヵ月前が理想です。

ドメインの移転が決定したらすぐ、取得されて移転を初めていったほうがよいでしょう。

半年以上更新期限はあったのですが、ドメイン移転を決定してからは、すぐに取得、移転を開始しました。

リダイレクト対応期間やサーバー移転の際の問題発生対応、その他あとから発見させる引っ越しの際の設定や告知手続きなどもあり、運営期間が長く、外部サイトとの関連付けが多ければ多いほど、比較的長めの期間をもって準備しておくことがよいと思いました。

ドメイン代がもったいないから2週間前で十分、という方はそうしてください。

ドメイン1つあたり、たかだか数百円から高くても数千円ですので、問題が発生したときの損出や常に更新タイミングを気にしていることの経費を考えると、ほとんどメリットはないと考えました。

 

3.WordPressの導入方法

新しいドメイン用のWordPressの導入にもすこし時間がかかりました。

最近のホスティングレンタルサーバーは、標準で管理画面でWordPress自動インストールが可能なサーバーが多く、Xserverでも管理画面内で画面遷移だけでWordPressがインストール可能です。

またXserverにはWordPressの移転機能「WordPress簡単移行」という、他のサーバーからも可能な移転機能がついており、こちらも導入方法を迷わせてくれた原因でもあります。

結果としては、MySQL設定でMySQLユーザーとMySQLデータベースを新規に名前を付けて作成し、そちらのデータベースを指定して、「WordPress簡単インストール」で個別にインストールしました。

WordPress簡単移行はWPログイン情報と移転元と移転先の指定で可能なのですが、1つのサイトを除き、他サイトはエラーメッセージが表示され、そのまま移行ができませんでした。

その対処や原因を調べる手間を考えると、あまりにも非合理的な気がしたので、従来通りの手間が一番かからずあとあと管理しやすい方法とおもわれる手順で行いました。

 

ちなみに、簡単インストールで自動でデータベースを作成する場合、データベースの名前が自動でつけられてしまうため、あとからどのサイトのデータベースかがすぐにわからないため、すべて名前を付けて新規にMySQLでデータベースを作成しています。

WordPress簡単移行でも自動的にデータベースが作成されてしまうのですが、こちらは管理画面でデータベースの名前が確認できるため、いちおう管理上は問題なさそうでした。

 

また、このタイミングでマルチサイトの導入を検討する場合もあるかもしれませんが、リスクや運営上の不便が多いため、各サイトは同じドメイン内のサブディレクトリでも別々のWordPressで管理することにしています。

マルチサイトは例えば一つのサイトの不具合で、管理するサイトすべてが表示されなくなる、データの移管や管理が全体と紐づいているため、個別でのカスタマイズにかなり支障がでる可能性が高くなるなど複数のデメリットがあるからです。

 

 

4.WordPressのデータ移管方法

こちらも結構悩みどころでした。

とくにサイト全体のコンテンツ量が大きい場合は、むずかしいことがたくさん発生しやすいかもしれません。

プラグインAll-in-One WP Migrationを使用したのですが、やはりこちらが一番良かったです。

旧バージョンは512Mbyteまで対応しているので、よほどボリュームが多いサイト以外はこちらで対処できます。また、一部のデータを間引いてエクスポートできるので、余計なファイルデータなどを省くことでそこそこの規模のサイトは移管しやすいです。

最新の無料版はエクスポート、インポートともにサイズ制限がかなり低くなっているため、いきなり30Mbyteまで下がっているようでした。

エクスポートのメディアライブラリなどを手動で移動するだけでも、かなり可能かもしれませんが、有料版も1万円強なので、コンテンツが膨大なサイト管理をしている場合はすぐに購入したほうが良いかもしれませんね。

ということで、データ移管についてはやはりプラグインのAll-in-One WP Migrationが一番合理的で効率的な気がしますので、同じXサーバー内ということもありスムーズにできました。

WordPressのバージョンやサーバー環境やPHPのバージョンが異なる場合は問題が発生する場合が多いので、既存サイトで移転先の環境と同じバージョンにアップデートしてからデータ移管を行うなどの注意が必要です。

 

 

5.メールアドレス

ドメインを変更する場合に大きなネックとなるのがメールアドレスです。

住所がすべて変わるわけですので、すべて関連するメールアドレスを変更しなければならないでしょう。以前のドメインをしばらく使用できるように余裕をもってドメインを取得するのは、メールアドレスなどの移行の点も考慮しています。

お問い合わせフォームや、顧客や利用者がいれば全てに告知しなければなりませんし、外部サイトの登録をしていればそれらもすべて変更する必要があります。

サイト自体は2-3ぐらいのメールアカウントのみにして、可能であれば用途ごとにできるだけ一つのメールアドレスに集約しておくと、運営管理上は非常に楽になります。

もちろん転送などを利用して、さらに集約することも可能ですが、基本的にはドメイン単位で管理しておくことがよいと考えています。

メールのデータ移行は基本できないので、やはりドメインを早期に取得して新規メールアカウントと並行して移行していくことがよいのではないかと考えられます。

 

 

6.日本語URLページのリダイレクト

リダイレクトは.htaccessによるワイルドカードを利用した301リダイレクト、つまり、サイトドメインのURLが恒久的に移転する場合に使用する転送処理のためのステータスコードで一括で可能ですが、日本語URLなどの場合はこのまま適用されませんので、個別に転送が必要になります。

SEOなどを念頭に実験的に記事名を日本語URLで記事ページを大量に作成していた場合、このリダイレクトは手動で設定しなくてはならないようです。

この場合htaccessに数十から数百の指定を文字コードの変換を行って記述するのは現実的ではありませんから、WordPressのプラグイン[Redirection]を使用して個別に行いました。

正直数百ページを個別に設定するのはさらに現実的ではないため、アクセスの上位ページ数十ページのみプラグインでリダイレクト設定して、他は.htaccessの301ステータスコードでリダイレクトするようにしました。

そのため、日本語URLの記事ページなどは大量に残ってしまい新規サイトと重複ページが発生してしまいますが、こちらは検索エンジンからの評価がほとんどないとみられるため、自然に新規ドメインページが認識されるように運用ベースで人的なリダイレクトにするほかないようでした。

アクセス上位の記事ページ以外だと、カテゴリーページや固定ページが日本語URLの場合、同じようにリダイレクト設定しておいたほうがよいでしょう。

ちなみに新規ドメインでは日本語URLをすべて廃止しました。

SEOはもとより、カテゴリーやカスタムタクソノミーの運用上もわかりずらくなるため、運用上は日本語URLはないか、となりました。

 

7.データベースの命名

データベースはMySQLの追加で新規に追加しているのですが、ユーザー名やDB名が被ってしまいわかりずらくなるので、既存のものに”n”をつけるなどあとからわかるように命名しておくとよいでしょう。

データベース名は基本的にドメインやサイト名にちなんだ名前があとからわかりやすいので良いと考えています。

 

8.その他

ドメインの変更は、複数のサイトが重なる場合結構たいへんでした。

URL自体が変更になるので、これまでのURLは後々無効になりますから、これまでに被リンク資源などはほぼ、なくなるわけです。

そのほか、変更を告知したり登録している外部サービスなどすべて変更する必要があるので、よほどのことがない限りはドメインの変更はお勧めできません。

またWordPressサイトなどの場合はメールフォームなどの設定変更もやり直すことが必要になるので、わりと煩雑な手間がかかることが予想されます。

 

いずれにしても、Webサイトの引っ越しにという負荷のあるイベントになるので、知見のない人は引っ越し業者に依頼したほうが無難で、かなりの時間と費用のロスが発生するため、よくよく検討してからドメイン変更およびサーバー移転は実施したほうが良いかもしれませんね。

 

 

 

掲載情報につきましては、当サイトが独自に調査、検証および収集した情報です。

情報の妥当性や確実性を一切保証するものでなく、情報や内容が訂正や修正、変更されている場合があります。 よって、当サイトの利用により生じたいかなる損害等についても運営側にて一切の責任を負いません。

掲載情報の修正・変更等をご希望の場合はお知らせください。

InstagramのAPIでアクセストークンとユーザーIDを取得

画像を読み込んでホームページ内に一覧表示させるために、InstagramからAPIでアクセストークンとユーザIDを取得してみる。(2019年5月 現在)

 

1:インスタグラムにログインする

画像を読み込むインスタグラムのアカウントにログインします。

 

 

2:アプリケーション登録

ログインしたら一番下のフッターメニューの「API」をクリック。

画面がかわるので、Developer Signupで対象サイトURLなどを入力。初回は電話番号が必須らしい。

 

登録申請すると、管理画面から[Resister Your Aplication]でアカウント作成して、Register new Client IDで新しいアカウントを作成します。

基本項目はなんでもよいのですが、Valid redirect URIs:(基本的に読み込ませたいサイトURL)は覚えておきます。

 

3:アカウント作成

アカウントを作成すると[Manage Clients]にinsta_appが追加されるので、Client ID xxxxxxxxxxxを確認。

以下のアドレスにアクセスして、CLIENT-ID(取得したクライアントID)とREDIRECT-URI(登録時のValid redirect URIs)の部分を作成したアカウント情報でアクセス。

 

https://www.instagram.com/oauth/authorize/?client_id=CLIENT-ID(取得したクライアントID)&redirect_uri=REDIRECT-URI(登録時のValid redirect URIs)&response_type=token

 

このとき、エラーメッセージなどが表示される場合は、引数が間違っているので正確にコピペしてつなげる必要がある。

 

 

例)リダイレクトURLが登録したものと違っている。

error_message “Redirect URI does not match registered redirect URI”

 

 

4:API認証

情報が正しいと、This app is in sandbox mode and can only be authorized by sandbox users.という認証画面に遷移するので、承認ボタンをクリックで完了。

 

そうするとリダイレクトサイトURLに移動するので、アドレスバーにアクセストークンが表示される。

 

https://リダイレクトURL/#access_token=xxxxxxxxx.xxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx(アクセストークン)

 

これでアクセストークンは取得できる。

 

 

 

5:ユーザーIDの取得

以前はユーザーIDは登録時に生成されていたが、APIが終了してしまったというこで、アクセストークンで取得しなければならない。

 

以下のようにアクセスすることで、APIから情報が取得できるので、一番上のID情報がユーザーIDになる

 

https://api.instagram.com/v1/users/self/?access_token=xxxxxxxxx.xxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx(アクセストークン)

 

 

 

ページヘッダには以下が必要。

<script type=”text/javascript” src=”js/jquery-2.1.4.min.js”></script>
<script type=”text/javascript” src=”js/instafeed.js”></script>
<script type=”text/javascript”>
$(document).ready(function() {
var userFeed = new Instafeed({
target:’instafeed’,
get: ‘user’, //ユーザーから取得
userId: ‘user idをいれる’, //ユーザーID(先ほど確認した’user_id’)
sortBy: ‘most-recent’,//最新記事から順に取得
links: true , //画像リンク取得
limit: 10, //取得する画像数を設定
resolution: ‘low_resolution’, //画像サイズを設定
template: ‘<li><a href=”{{link}}” target=”_blank”><img src=”{{image}}”></a></li>’,
accessToken: ‘access tokenを入れる’ //アクセストークン
});
userFeed.run();
});
</script>

 

 

ホームページ内にインスタグラムの画像を表示させるために必要なアクセストークンとユーザーIDは以上の手順で取得できました。

 

※2019年7月時のもので、仕様変更している場合があるので、都度、確認が必要です。

 

 

 

 

 

掲載情報につきましては、当サイトが独自に調査、検証および収集した情報です。

情報の妥当性や確実性を一切保証するものでなく、情報や内容が訂正や修正、変更されている場合があります。 よって、当サイトの利用により生じたいかなる損害等についても運営側にて一切の責任を負いません。

掲載情報の修正・変更等をご希望の場合はお知らせください。

font awesomeがローカル環境で表示されない対処方法

サーバーからページに名前を付けて保存した場合に、font-awesome.cssは読み込まれているのにフォントアイコンが表示されないで□みたいになり表示されないとき。

 

 

CDNなど最新を読み込んでも表示されない場合があります。
その場合はfont awesomeのクラス名があるバージョンのcssファイルをCDNで読み込んでみます。

 

 

<link rel=”stylesheet” href=”https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css”>

 

 

今回はこのケースである程度、ローカル環境でもWebフォントでアイコンを表示させることができました。一部、表示されないものがある場合は、別のバージョンで試してみると表示されるかもしれません。

 

 

基本的にはclass=”fa fa-xxxxxなどからはじまるセレクタ名をヒントに探していくとよいでしょう。

掲載情報につきましては、当サイトが独自に調査、検証および収集した情報です。

情報の妥当性や確実性を一切保証するものでなく、情報や内容が訂正や修正、変更されている場合があります。 よって、当サイトの利用により生じたいかなる損害等についても運営側にて一切の責任を負いません。

掲載情報の修正・変更等をご希望の場合はお知らせください。