hxxk.jp

法令や制度（特に税制など）や、Web（HTML/CSS、WordPress）などの情報を深く掘り下げながら記録するweblog

NEW ARTICLE
出張査定業者の訪問を受けたので、注意点をシェア

WordPress導入・運用開始の個人的記録

WordPress導入・運用開始の個人的記録

記事内目次

  1. WordPress導入時から運用開始後につまずいたところをメモ
  2. hxxk.jpにおける前提条件
  3. 「WordPressアドレス(URL)」と「サイトアドレス(URL)」を別にする場合
  4. 子テーマ導入と追加CSS設定
  5. タグクラウドの一部が表示されない（初期値の最大表示個数が45だった）
  6. （未解決）コードエディターの謎挙動をどうにかしたい
Advertisement

WordPress導入時から運用開始後につまずいたところをメモ

このサイトは、2018年11月から2ヶ月ほどはてなブログで仮運用を行い、2019年1月に独自ドメインhxxk.jpに設置したWordPressにて本運用を開始しました（そのあたりの流れは、今後大まかなサイトの歴史にて追記していくかもしれません）。

その際にWordPressを導入し、自分好みに手を入れていくにあたってつまずいたところをメモしていく記事です。

よって、つまずかなかったところはメモしないため、一からインストール手順を知りたい場合はWordPress のインストールなどの記事を参照してください。

↑ 記事内目次にもどる

hxxk.jpにおける前提条件

hxxk.jpの場合、以下のようなサーバースペックおよびWordPressバージョン・テーマでインストールしました。

サーバーのメモリー
131,913MB
Apacheのバージョン
2.4
PHPのバージョン
7.0.32
MySQLのバージョン
5.7.24
WordPressのバージョン
5.0.2
WordPressのテーマ
LION BLOGテーマ

↑ 記事内目次にもどる

「WordPressアドレス(URL)」と「サイトアドレス(URL)」を別にする場合

WordPressをインストールした後は、「サイトアドレス(URL)」はhttp://hxxk.jp/（ドメインのルートディレクトリ）で公開したいと考えていました。
しかし、WordPressを構成するインストールファイルはドメインのルートディレクトリ直下に配置すると管理上煩雑になるため、例えば/wordpress/というディレクトリに配置したいと考える方が多いと思います。

その場合、WordPressの管理画面から「設定」→「一般」と辿り、「WordPress アドレス(URL)」欄にインストールファイルを配置したディレクトリを、「サイトアドレス(URL)」欄に公開したいディレクトリを入力するのですが、あわせて既存のサブディレクトリを使ってルートディレクトリに表示する場合を参照しながら、index.phpの内容を修正して配置しなおす必要があります。

上記のように、/wordpress/というディレクトリにファイルを配置している例だと、

修正前
require( dirname( __FILE__ ) . '/wp-blog-header.php' );
修正後
require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' );

のように修正します。
閲覧者はhttp://hxxk.jp/（のindex.php）にアクセスして来るのですが、ファイルの要求は/wordpress/ディレクトリにあるwp-blog-header.phpに対して行われなければならないからです。

↑ 記事内目次にもどる

子テーマ導入と追加CSS設定

WordPressのデザインを編集する3つの方法という記事で、

テーマファイルそのものを編集する場合も、子テーマを作成して編集する場合も、HTML/CSSの知識だけでなくWordPressの知識を必要とする（例えば、functions.phpを適切に編集する必要がある）ため、WordPress初心者には少々難しいかもしれません。

と書きましたが、LION BLOGのように、テーマ作成者側であらかじめ子テーマを用意してある場合は、子テーマの導入は難しいことではありませんでした。

既存の子テーマを導入する場合、WordPressの管理画面から「外観」→「テーマ」→「新規追加」→「テーマのアップロード」と辿り、子テーマの.zipファイルをアップロードするだけでOKです。（アップロード後に「有効化」するのも忘れずに！）

WordPressのデザインを編集する3つの方法 – 方法3: 追加CSSで変更するでは、

追加CSSの記述はページごとにhead要素内のstyle要素として出力されるため、追加CSSの記述を多くしてしまうと、ページのファイルサイズが大きくなるだけでなく、UAもページごとにその都度スタイルを読み込んでしまいます。

テーマファイルや子テーマのように外部スタイルシートの.cssファイルを読み込む場合は、キャッシュが機能することでページごとのスタイル読み込みは抑えられるため、いずれは子テーマ作成を検討した方が良いでしょう。

というデメリットを述べていますが、子テーマを有効化した後に、それまで追加CSSに記述していた内容を子テーマの.cssに移すことでそれらのデメリットは解消されます。

↑ 記事内目次にもどる

タグクラウドの一部が表示されない（最大表示個数が初期値は45だった）

順調に記事数を増やしていたある日、タグクラウドに一部のタグ、それも最近作成したタグが表示されていないことに気付きました。

調べてみると、タグクラウドに表示されるタグの数の最大値は、初期値だと45個となっていて、作成順に45番目までのタグを表示しているとのこと。

【WordPress】タグクラウドの最大表示数を変更する方法 – ONZEを参考にして、WordPressの管理画面から「外観」→「テーマの編集」と辿り、LION BLOG Childの方のfunctions.phpに以下のコードを追記しました。

//20190115 add START
//https://on-ze.com/archives/7177

function my_tag_cloud_number_filter($args) {
	$myargs = array(
		'number' => 0,
	);
	$args = wp_parse_args($args, $myargs);
	return $args;
}
add_filter('widget_tag_cloud_args', 'my_tag_cloud_number_filter');

//20190115 add END

↑ 記事内目次にもどる

（未解決）コードエディターの謎挙動をどうにかしたい

私は基本的にローカルのHTMLエディタで、HTMLマークアップまで行った上でWordPressのコードエディターに貼り付けて投稿しているのですが、未解決の点がいくつかあります。

<p>hoge</p>と書いた部分がhogeとして保存される
wpautop関数が関係しているのかな？と思い、TinyMCE Advancedというプラグインの導入や、functions.phpへのremove_filter( 'the_content', 'wpautop' );およびremove_filter( 'the_excerpt', 'wpautop' );の記述も試しましたが、この関数は連続した改行をパラグラフに変換する機能であって、保存後には結局<p>と</p>は消してしまいます。

記事として生成されたソースには<p>と</p>が出現しているので、エディター上でのみ消しているようです（classが指定された<p>要素は消さないようですが、全てのパラグラフにclassを指定するのはナンセンスです）。

<ins>要素が（おそらく）ブロックレベル要素を内包しない
ちょっとしたリライトには用いていませんが、明確な追記理由があったり追記の日時に意味がある時には<ins>要素で追記部分をマークアップするのですが、<ins>要素内に<p>要素や<ul>要素などのブロックレベル要素を内包させようとすると、エディター上で</ins>がワープします。

入力中。ins > pという親子関係になっています。
入力直後。内容が空の<ins>要素になって<p>要素となるテキストの前に生成されています。

前述の通り<p>と</p>が消えているのはまあいいのですが、</ins>が前にワープしてしまい、追記部分がどこまでを示しているのか分からなくなっています。

ちなみに、<ins>inline text</ins>のように、インラインテキスト（あるいはインラインレベル要素）を内包する場合は</ins>がワープすることなく、要素の内容を保持します。

<section>要素の閉じ方がおかしくなる
#脱脱社畜サロン という流れが起きかけている話ではtwitterの埋め込みを行っているのですが、こういった場合も前述の<ins>要素と同じように</seciton>がワープします。

通常のHTMLの場合はきちんと</section>の位置が保持されるので、埋め込みタグの何かが影響しているようです。

↑ 記事内目次にもどる