なんでこんなにWPサイトが多いんだろう?

という疑問が湧いたので、業務の間に考えてみた。

結論から言うと、WPはCMSとしての利用も当然ながら、フレームワークとしても利用されているんだろうな、という感。

ブログが必要なサイトだったり、日々記事の更新を必要とするようなサイトだったら、そりゃCMSを使う方がいいのだけれど、別段そうでもなさそうなのに、WPサイトにしているというものも見かける。私にとっては「わざわざWPにしなくても・・・(システムアップデートとか面倒だよ?)」って思うのだが、きっと理由はあるはず。
なので、WPでサイトを作る理由について考えてみた。

①HTML書かなくていい

WPはテーマを入れればHTMLやCSSを全く書かなくてもサイトが作れる。カスタマイザーでちょこちょこ変えればそれなりのものができるし、そもそも仕組みとHTMLがわかるのであれば、面倒な定型文(ページを作り始める時にほぼ必ず書かなければならない枠組みぽいところ)をぺろっと描いた状態で出てくるのでありがたい。HTMLを知らない人だけではなく、知っている制作者にとっても工数が減る。

②プラグインとか使うと欲しい機能がほぼ揃う

更新が必要ではないサイトとはいえ、お問い合わせフォームは欲しい、となると、無料やライセンスフリーで使えるお問い合わせ用のプログラムを探して、カスタマイズして、アップして、そしたら時々500エラーとかが出て、しかも原因がなかなかわからなかったりしてストレス・・・・。ということはままあるのですが、これもWPだとプラグイン入れれば解決〜とかになる。とってもストレスフリー。しかもフォームタグとか結構打つの面倒だけど、プラグインはそこらへんがとってもユーザーフレンドリー(その代わり自由度はなくなるけど)なので、設定も楽々、管理画面の上でできちゃう。すごいねー。

③レスポンシブデザインに対応している

これも大きかろう。普通に1から考えるとレスポンシブなデザイン作るのは本当に大変。工数かさむ。(本当に、マジで、全然簡単じゃないから!!!!)
テーマの機能でそこれがまかなえたらかなり短縮になるし、楽ができる。もちろん、カスタマイズしなければならない場所も出てくるし、そのためには、テーマのCSSやJSにどんなことが書いてあって、どこをどういじればどうなる、っていうのを調べるのはそれなりに大変だから、自分で考えたほうが?とか思うこともあるけど、使い慣れてるテーマの1つもあればここは時短ができる。

ざっと思いつくのは、こんなところだろうか。

まとめると、
・サイトとして必要なページは5ページぐらい
・お問い合わせのメールフォーム機能が欲しい
・モバイルでの閲覧が多いからレスポンシブ対応にしたい
というような要件のサイトがあった場合。

上記のような要件のサイトをWPで作ると、インストールから始めても、デザインにこだわりがなければ、たぶんすぐに(半日ぐらいで)できてしまう。

これをHTMLで書くとしたら、デザインはあまりこだわらないとしても、HTML書いて、ひとつひとつCSSをちまちま書いて、かつレスポンシブで確認しながら、スマホ用メニューのJSも書かなきゃだし、さらにお問い合わせフォーム用のシステムを探して入れて(サーバーで簡単インストールできる場合もあるが、カスタマイズはそこそこ時間かかります)、とかやってると日が暮れて、エラーが出たりなんかしようもんなら、もうダメ、明日にする、とか思って、微調整とか最終チェックとか送信テストとかを翌日に回すだろうな、という感じ。(自分が過去に作ったものを使い回す、という手もあるが)

まあ、そりゃ、よっぽどじゃなけりゃWPサイトにしたほうが楽だよねえ。。。

ただし、最初にも少し書きましたが、WPサイトにする以上、逃れられないのは、システムのアップデートです。そういう作業が必要であることを理解してもらった上で、お客さまでもできるように指導をするか、費用をもらって制作者が作業をするなど、アップデートには対応する方がいいです。

それを思うとHTMLは楽ですねー。ですが、お問い合わせフォームのプログラムなんかは時々「惰弱性が見つかりました」ということもあるので、時々配布元のサイトの情報をチェックした方がベターですかね。

CMSならMovable Typeだってあるじゃない、ですが、こちらはライセンス料があるので上記のようなライトなサイトで導入するにはハードルがあるんでしょうね。

WordPressにはフレームワークとしての利用もあり得るのだなあ、と思いました。

スラッグの長さはどれぐらいまで可能か

聞かれたので、調べました。
ひたすら「1234567890」って入力して、保存して、採用になった分の「1234567890」が、以下です。

12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

カウントしたら200文字でした。
マルチバイトの文字列をスラッグに使った場合に、UTF-8エンコードされる場合、UTF-8エンコードされた文字が200文字以内に調整されるようです。なので、マルチバイト文字を使うときは20文字ぐらいまでです。

ふと、URLはどれぐらいの長さまで長くできるのか?って、思って検索したら、下記の記事がありました。4000文字ぐらいのようですね。
https://qiita.com/_matuzaki/items/70fb639f7ed7463f9943

スラッグって何文字ぐらいが適当でしょうか?と聞かれると、答えられないのですが。
いちいち考えるの面倒なので、IDにしたらどうでしょう、と話すことがありましたが、これ悪手のようなので訂正しておきます。
なぜURLをIDにするのはよくないと判断したかというと、Googleの検索セントラルを眺めていたら、URLに関する記述がありまして、そこに、「意味のない長い ID 番号を URL に使用」を推奨しないとあったからです。
https://developers.google.com/search/docs/crawling-indexing/url-structure?hl=ja

ちなみに、私は捨ててもいい記事は面倒なのでID、ずっと残したい記事はなんとなくページで言いたいことを英訳しています。

以上です。

2023-07-14 一部修正、URLの長さについてのリンク先を変更。

Sass勉強会の大雑把な内容(2016.5.15)

勉強会にあたって、下記の書籍を購入しました。
Sassを書いてみたい方にとてもオススメです。
Web制作者のためのSassの教科書
サポートサイトで書籍の正誤表やサンプルソースを見られます→http://book.scss.jp

さて、勉強会のために、下記のページを作りました。
http://www.ccc-labo.net/_demo/sass_lesson1/local/
このページを作る際に書いたSassを例にしてSassの基本的な書き方を確認していきました。

なお、コンパイル結果を確認するために、ウェブツールを使いました。
SassMeister→http://www.sassmeister.com

最初に、Sassの使い所がイマイチない、という話をした。そもそもCSSを書くときの管理方についても明文化できていないのに、Sassを使って効率化、という段階にない、とか、自分がSassで書くと他の人に引継ぎができないとか。そもそも、プログラムアレルギーが強くて馴染めない、などなど。

これらは私がSassを遠ざけた理由そのままだったので、とても納得なのだが、改めてSassをいろいろいじってみると・・・・・・まあ、圧倒的に便利な部分がある。例えば変数とかは使いたくてたまらない。コンパイルとか、環境を作ることがまず大変ですが。。。(苦労しました)
この苦労と、書き方を覚える労力をかけるのと、今まで通りCSSをサクサク書くのと効率としてはトントンかもなあ、という思いがSass導入を遠ざけていたわけです(個人的に)。
しかし、勉強会を機に、一旦コンパイルする環境まで作ってしまえば、逆にこう思った。

「Sassのファイル内でいつも通りCSS書いたらそれは単純にCSSとして書き出されるだけなんだし、Sassの便利なところ、書ける!と思うことだけ取り入れたらええやん。」

と、いうわけなので、楽しいです、Sass。
紹介した書き方が下記です。カキカキ。

入れ子

.entry-header {
	.entry-title {
		font-weight: 300;
		text-align: center;
	}
}


.main-navigation {
		
	ul {
		padding: 0;
		margin: 0;
		text-align: center;
			
		li {
			display: inline-block;
			margin-right: 10px;
			line-height: 1;
			
			a {
				display: block;
				padding: 7px 10px;
				background-color: #333;
				color: #fff;
				text-decoration: none;
				transition: opacity 0.5s ease-in;
				opacity: 1;
					
				&:hover {
					opacity: 0.6;
					transition: opacity 0.5s ease-in;
				}
			}
			
			&:last-child {
				margin-right: 0;
			}
		}
	}
}

 

変数

$window_medium : 600px;
$window_large : 1200px;

$keycolor : #007099;

 

計算と繰り返し
@for関数を使って、繰り返しの処理を書く。

$grid_margin : 2%;/*単位は%*/
$grid_width : ( 100 - $grid_margin * 5 ) / 6;

@for $i from 1 through 6 {
		.grid-small-#{$i} {
			width: ($grid_margin * ($i - 1) + $grid_width * $i);
		}
	}

 

色の計算
キーカラーから派生させた背景色を作る。こうするとトーン配色を守った色使いが考えやすい。

$keycolor : #007099;

.main-visual {
	text-align: center;
	background-color: mix($keycolor,#EEE, 10%);
	padding-top: 40px;
	margin-bottom: 30px;
}

 

@extendの例
同じ処理をまとめるために使う。ただ、後に紹介する@mixinの方がSassで書くものとコンパイルの結果の違和感が少ないよね、という意見もあった。(私もちょっと苦手)

%btnBase {
border-radius:3px;
background-color: #333;
color:#fff;
}

.btn {
@extend %btnBase;
padding: 9px;
}



.item {
@extend .btn;
margin-left:10px;
}

.item2 {
@extend %btnBase;
margin-left:10px;
padding: 4px;
}

ミックスイン
@mixin関数。これは本当に便利だ。
@include kadomaru(); のカッコ内には角丸のサイズを入れることで、変更ができるので試してみてほしい。
例 @include kadomaru(10px);

@mixin iblockHack {
	display: inline-block;
	*display: inline;
	*zoom: 1;
}

@mixin kadomaru($value: 4px) {
	-moz-border-radius: $value;
	-webkit-border-radius: $value;
	border-radius: $value;
}

li {
				@include iblockHack;
				margin-right: 10px;
				line-height: 1;
a {
					display: block;
					padding: 7px 10px;
					@include kadomaru();
}
}

 

ミックスイン複数の値
複数の値をとることも可能。角丸のサイズとパディングの値を変数にしておくと、これひとつで角丸のあるボタンやボックスの調整がたった1行書くだけでできるようになる。

@mixin kadomaruBox($value1: 4px,$value2: 10px) {
	-moz-border-radius: $value1;
	-webkit-border-radius: $value1;
	border-radius: $value1;
padding: $value2;
display: block;
}

a {
@include kadomaruBox(10px,30px);
}

以下、勉強会の時に出てきた質問などについて少し調べておいたので、書き留めておきます。

コンパイルされたCSSの改行とかタブの入り方が気にくわない、修正したい!
こんな記事見つけました。やっぱり思っている人はいた。
http://www.ysakmrkm.com/2012/10/customize_output_format_compiled_by_sass.html
根本的な解決にならない、って書いてあるけど、どうじゃろ、ruby詳しい人に聞けばいいのかな・・・。

Macでの環境構築について
El Captainになって、OSのシステム系のファイルにルート権限でもアクセスできなくなったそうな(すみません、細かいことはよくわかっていません)。
で、Macは標準でRubyが入っているからそっち使ってもいいよ、という感じでやってみようとしたんですが、失敗しまくり。色々やりすぎて何をどうしたのかあまり覚えてもいない・・・・・。
この辺りが参考になる気がします。
https://teratail.com/questions/23280

compassを使う
勉強会の際に使っていたMacBookではできなかったのですが、自宅のiMacでは普通に使えたので、頭を抱えています。バージョンとかも変わらないのですが・・。
ただ、iMacの環境では、compass watchがなんだかうまくいってない風・・・・。謎です。。。。。
これについてはまた何かわかったら書きます。

【第13回】ディレクトリを超えてリンクをしてみる

前回の記事で、日記のHTMLファイルを「201602」と「201603」というふたつのフォルダに、書いた日を基準にして整理しました。そして、全てのページが一覧になったインデックスページを作りました。ほんのちょっとウェブサイトっぽい感じが出てきました。ほんのりですが。

さて、フォルダを整理したことによって、少々問題の出ているページがあります。

“【第13回】ディレクトリを超えてリンクをしてみる” の続きを読む

【第12回】ディレクトリに分けて整理する

ほぼ日更新を宣言しつつ、全然書けてないです、ごめんなさい。

とはいえ連載も10回を超えてきました。HTMLファイルも増えてきましたね。真面目に毎日書いていたら結構な数になっていきます。HTMLファイルが1つのフォルダに無数にあっても、コンピューター的には特に問題はありませんが、人間には少々見づらい感じがします。なので、これを月ごとのフォルダを作って、整理してしまおうと思います。

“【第12回】ディレクトリに分けて整理する” の続きを読む