【Twenty Seventeenのちょこっとカスタマイズ】フロントページの記事のカテゴリーを絞る

昨日に引き続き、Wordpressのカスタマイズについてです。

Twenty Seventeenではフロントページのカスタマイズがかなり簡単になっています。4ページ分の固定ページのコンテンツを載せられて、そのうち一つは記事一覧も出せます。

でもブログっぽくないページを目指すには全記事一覧が出ちゃうとちょっとなあというケースがあると思います。そういうときは子テーマを作ってさくっとカスタマイズしてしまいましょう。

※ここでは、フロントページを固定ページに、投稿ページをnewsというニュース記事ページに設定している前提でお話してみます。

そもそも何処で動いているのか

まずはテーマオプションで指定できる、フロントページの最大4つのセクションを出力する箇所をピックアップしてみます。 “【Twenty Seventeenのちょこっとカスタマイズ】フロントページの記事のカテゴリーを絞る” の続きを読む

【Twenty Seventeenのちょこっとカスタマイズ】Powered by を書き換える

ひさびさにWordpressを弄っています。色々と変わりましたね。
子テーマとか楽しいなあ。カスタマイズがらくちん。だけれど忘れてしまうのでメモしておこうと思います。(子テーマの作り方は公式サイトなどを参考にしてください。)

Twenty Seventeen、とても良いテーマです。というか、4.7が良いのかな。子テーマまで踏み込まなくてもかなり簡単に色々とカスタマイズ出来ますね。

とはいえ、自分色に思う存分染められるのがWordpressの醍醐味。というわけで、先ずはちょっと申し訳ない気持ちは持ちつつも「Proudly powered by WordPress」をさくっと変更してしまいましょう。子テーマは作っておいてくださいね(このぐらいの変更なら直接親テーマをいじってしまっても良いでしょうけれど)。

Twenty Seventeenのソースの中から該当するファイルを見つけます。

/wp-content/themes/twentyseventeen/template-parts/footer/site-info.php

を子テーマ(ここではtwentyseventeen-child)にコピーします。 “【Twenty Seventeenのちょこっとカスタマイズ】Powered by を書き換える” の続きを読む

HTML5 boilerplateをsassでgulpでstyledoccoな感じにしてみた

Google web starter kit を触っていて、gulpstyledoccoという素敵ツールを知ったのでhtml5 boilerplateをベースにsassとgulpを導入してstyledoccoでstyleguideも自動生成する、というのを作ってみました。(・・・Google web starter kitをベースにする方が早い気もするのですが、モジュールやらコンポーネントの内容やSassの構成とかがイマイチ凡人には理解しかねたので今後のアップデートに超期待しています。) “HTML5 boilerplateをsassでgulpでstyledoccoな感じにしてみた” の続きを読む

続:CSSフレームワークGumbyとFoundationを触ってみた

意外にも続報が早めに書けました。といってもGridとRetina Imagesの2つについてぐらいだけれども。

1. Gridなど

基本的なGridの作り方は、rowの中にcolumnsを突っ込む感じでほぼ同じ。

Gumbyの場合
http://foundation.zurb.com/docs/components/grid.html

小さい画面になると基本的に全カラムが全幅になる感じ。
カラム数が12と14とか、混在させたりも出来るけれど使うところあるのかな・・・。

画像とテキストの組み合わせだと、

Vertical Alignment
http://gumbyframework.com/docs/components/#!/vertical-alignment

を使うと小さい画面でも綺麗に並ぶ。(ずらっと並べるタイル表示は別に方法がある)

あとは

FitText
http://gumbyframework.com/docs/extensions/#!/fittext

というのもあって、画面サイズによってフォントサイズを変えることも可能。

・・・細かいのは自分で作れ、というかそういうデザインには合わないのかな。確かに余程のことがないと小さい画面でグリッド分けるのは避けるべきだなあと思うのでこれで良いのかもしれない。そこがいい感じに見えるキモかもしれない。・・・もしかしたら他に方法があるかも知れないけれど、多分そんな感じ。

Foundationの場合
http://foundation.zurb.com/docs/components/grid.html

画面サイズをSmall、Medium、Largeの3段階で表示するカラム数を選べる。
前の記事にGumbyのMixinのことを書いたけれど、やっぱりFoundationにもたくさんMixinが用意されていてCSS内で完結することも出来そう。
・・・やれることが多すぎて書くことがありません。

2. Retina Images

(予めRetina用の画像を用意して@2xつけて保存しておく。)

Gumbyの場合
http://gumbyframework.com/docs/components/#!/retina-images

retina用の画像を同じフォルダに入れてgumby-retinaて書くだけ。

<img src="/images/logo.png" gumby-retina />

シンプルで便利なんだけどバリデーションしたら無論怒られる。(Gumbyはバリデーションで怒られる前提で使う勇気が必要だ。)

Foundationの場合
http://foundation.zurb.com/docs/components/interchange.html#using-retina-images

Foundationは独自データ属性のdata-interchangeで画像の切り替えを扱っていてretina対応も含まれているらしい。

<img src="/images/logo.png" data-interchange="[/images/logo@2x.png, (retina)]">

という感じかな。(ちゃんと実機で検証してない)

以下のフォーラムも参照するとよさげ。

Images, Interchange, and small Retina devices | Foundation Forum from ZURB
http://foundation.zurb.com/forum/posts/2594-images-interchange-and-small-retina-devices

感想など

・・・どちらも公式サイトをバリデーションするとちょっと残念な感じなんですが、最近はそういうものなのでしょうか。

Gumbyは「オレサマコード!どうだロックだろ!」みたいなイメージかなあ。ソースドーンと落としてぱっぱっと書き換えればいい感じなのがするっと出来る感じ。でもバリデに怒られる。嫌いじゃないというかむしろ好きだけれど、受託案件で使う気はしないです。でも、JSのライブラリとか色々とぱく・・・参考になりまくるソースがあるので美味しくいただきたいと思います。

Toggles & Switches
http://gumbyframework.com/docs/components/#!/toggles-switches

とか

Parallax
http://gumbyframework.com/docs/extensions/#!/parallax

とか美味しそうです。

Foundationは、さすが企業が作ってるって感じで痒いところに手が届く。デザインテンプレートも豊富でまだまだ成長する感じだから、ある程度時間をかけて勉強してもいいと思う。でも頼りすぎると自分がダメになる気がします。

Off Canvas
http://foundation.zurb.com/docs/components/offcanvas.html

ていうサイドバーのオンオフが出来るやつも入ってて便利です。

・・・で、私としてはHTML5 BoilerplateにFoundationをのっけて、Gumbyのエッセンスを所々に使う、のが良さそう。かなー。

CSSフレームワークGumbyとFoundationを触ってみた

第二子出産してる間に、こういうのをCSSフレームワークと呼ぶようになったんですね。CSSのフレームワークにしてはCSS以外の要素が多過ぎる気がしなくもない・・・。
まあどんなフレームワークも、実際に使うかどうか分からなくても、ちょっと触ってみるだけで有益なtipsが沢山得られるので少しだけでも触ってみるのが良いと思っています。
・・・とはいえ時間に限りもあるので、2つに絞って触ってみました。

Bootstrapより癖がない、との評が多い

Foundation
http://foundation.zurb.com/

と、カスタム前提で作られているという

Gumby
http://gumbyframework.com/

です。
それぞれ私目線で比べながら触ってみました。

1.ダウンロードとインストール

Gumbyはダウンロードボタンを押すと、ごっそり一式ダウンロードできてSassファイルも入っているのであとはCodekit(2が出てますね!まだチェックしてない!)に読み込ませるだけで良いのが気楽。

FoundationはSassを使いたければ、

Getting Started With Sass
http://foundation.zurb.com/docs/sass.html

に従ってコマンドラインでゴソゴソする必要があります。といっても数行なのですぐ終わります。

2. 基本の設定(CSS)

Gumbyはダウンロードする前に

Customize
http://gumbyframework.com/customize

でカスタマイズをしてからダウンロード出来ますが、どうせダウンロードしてからも弄るので

/sass/var/_settings.scss

の設定ファイルに慣れるのが早い気がします。

// Welcome to Gumby 2.0 Settings.
// Happy Tinkering!

// Grid Settings
$row-max-width: 940px !default;    				// 940px
$gutter-in-px: 20px !default;      				// 20px
$cols: 12 !default;              				// 12 Column Default Grid
$hybrid: 16 !default;							// 16 Column Default Hybrid Grid

// Responsiveness Settings
$min-device-width: 320px; 						// iPhone Portrait
$tablet-device-width: 768px;					// iPad Portrait
$document-width: $row-max-width;				// Default Document
$max-device-width: 2880px;						// Max Document Size

みたいな設定値がずらっとあるので該当箇所をいじってみると

css/style.css

に書きだされて

ui.html

に反映されるのでわかりやすいです。

Foundationも同じく、サイト上でカスタムしてからダウンロードできますが、
Sassで使う場合には上に書いた方法でインストールすると、

/scss/_settings.scss

というファイルがあってコメントを読みつつ必要な箇所をコメントアウトしてカスタムしていく感じです。すると

css/app.css

に圧縮して書き出されます。

・・・うーん、最初から圧縮して書き出すのはどうなの?最終的には圧縮するかも知れないけれども。
GumbyはConfig.rbすぐ見つかるから良いけれど、・・・!

とか思ったら私FoundationのほうをGrunt + Libsassとやらのほうで作ってたのでした。
ちゃんと読んで無いのバレバレだ・・・。

えーと、Compassのほうで作ると、
Sassファイル弄る前は該当のCSSは書き出されておらず、設定すると、

stylesheets/app.css

というファイルが生成されます。
しかもちゃんと圧縮されずに。。。

index.html

が反映先ですが、全部のパーツが見たかったら、

Kitchen sink
http://foundation.zurb.com/docs/components/kitchen_sink.html

をDLしてみるのが良いのかな。

3. HTMLとブラウザ対応

どちらも配布ソースでは、HTML5ながらdivタグのみ。

Gumbyはpaulirish.comのhtmlタグハックが付いてるけれど、

http://gumbyframework.com/docs/#!/browser-compatibility

IE8以上ということになってます。

Foundationはhtmlタグはまっさらながら

http://foundation.zurb.com/docs/v/2.2.1/qa.php

をみるとIE7以上なのかな。
でもどうやって個別対応するんだろうか・・・。

あと、GumbyにはSemantic Gridという手法もあって、
Sassのmixinを使ってCSS内で完結する感じが素敵。
(Foundationでもsectionなんかのタグは使えるけれど、classとかidとかは残念な感じのまま。)

・・・って書いてみたものの、2つともドキュメントが膨大過ぎて機能の半分も把握出来てない気が。
やっぱりもうちょっと実際の開発作業に突っ込んでみないと分からないので、いつ出るかわからない続報にご期待ください・・・。

CompassでSprite画像の書き出しをちょこっとカスタマイズ

Compassの大きな魅力のひとつ、Sprite画像の書き出し。
凄く素敵な機能ですが、
画像名からclass名が自動生成されちゃうのとかちょっとイヤなので、
もう少し私好みに出力してもらうためのカスタマイズ。

sprite/ 以下に対象のpng画像を入れておきます。
ここではimg_a.png、img_b.png、img_a_hover.png、img_b_hover.png、の4ファイルが入っている想定です。

$sprites: sprite-map("sprite/*.png");
$sprites-img:sprite-url($sprites);
@mixin sprite-background($name) {
 	height: image-height(sprite-file($sprites, $name));
 	width: image-width(sprite-file($sprites, $name));
 	background-position: sprite-position($sprites, $name);
}
@mixin sprite-background-pos($name) {
 	background-position: sprite-position($sprites, $name);
}

とmixinを書いて、
お目当てのところに

a {
    display: block;
    background-image: $sprites-img;
    &.class_a {
        @include sprite-background(img_a);
        &:hover {
            @include sprite-background-pos(img_a_hover);
        }
    }
    &.class_b {
        @include sprite-background(img_b);
        &:hover {
            @include sprite-background-pos(img_b_hover);
        }
    }
}

という感じに指定。
高さや幅も一定だったら、それもmixinに入れずに書くのが良いかも。

参照:

CSS Sprite Helpers for Compass | Compass Documentation
Compassでスプライト画象を高速に書き出す方法[to-R]

CakePHP2.xとPHP5.4でStrict Errorが出た場合の対処法

PHPでは、error_reportingの設定により出力するメッセージを変更可能ですが、PHP5.4からE_ALLにE_STRICTが含まれるようになりました。
通常、E_ALLからE_STRICTを除いてエラーを出力したい場合、php.iniで

error_reporting = E_ALL & ~E_STRICT

とすることで制御可能になります。
エラーレベルについては、マニュアル参照
http://www.php.net/manual/ja/errorfunc.constants.php

但し、CakePHPでは、フレームワーク中でerror_reportingを定義している為、php.iniの設定が反映されません。

その設定が、
cakephp/lib/Cake/bootstrap.php

error_reporting(E_ALL & ~E_DEPRECATED);

で設定されています。

但し、これはフレームワーク本体のプログラムですので、ここを修正すべきではありません。

Cake 2.x では Error コンフィギュレーションが設定ファイルで定義出来るようになりましたので、これを利用します。
cakephp/app/Config/core.php

Configure::write('Error', array(
   'handler' => 'ErrorHandler::handleError',
   'level' => E_ALL & ~E_DEPRECATED,
   'trace' => true
 ));

のlevel部分に~E_STRICTを追加します。

Configure::write('Error', array(
   'handler' => 'ErrorHandler::handleError',
   'level' => E_ALL & ~E_DEPRECATED & ~E_STRICT,
   'trace' => true
 ));

これで、E_Strictのエラーが表示されなくなります。

尚、error_reportingは、PHP5以降で下記の様に変わっています。

バージョン 説明
5.4.0 E_STRICT が E_ALL に含まれるようになりました。
5.3.0 E_DEPRECATED と E_USER_DEPRECATED が追加されました。
5.2.0 E_RECOVERABLE_ERROR が追加されました。
5.0.0 E_STRICT が追加されました (これは E_ALL には含まれません)。

エラー処理なんて、そんなに変わる所でもないと思うのですが。。。メジャーバージョンアップ毎に変わっていくのがPHPらしいですね。