カテゴリー: HTML/CSS/JS, アクセシビリティ
この記事は2016年12月4日に書かれたものです。情報が古い可能性がありますのでご注意ください。
次のようにサイトマップのツリー構造を表現する際、これまでずっとラインの画像をリストの背景として設定し、表現してきました。
古い Internet Explorer が 6、7、8 と次々にサポートが打ち切られた今、これまで画像で表現していたデザインを CSS のみで表現できるようになり、様々な場面で画像を使わなくなりました。一方、サイトマップについては惰性で長らく画像を使っていたのですが、これも CSS のみでできるんじゃないかと思い、やってみました。
カテゴリー: WordPress
この記事は2016年12月4日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress の管理画面の「投稿」を「お知らせ」などのラベルに変更する方法はググるとあちらこちらで紹介されています。ここでも紹介しますが（笑）、functions.php 以下のように記述します。
function change_post_menu_label() {
global $menu;
global $submenu;
$menu[5][0] = 'お知らせ';
$submenu['edit.php'][5][0] = 'お知らせ一覧';
$submenu['edit.php'][10][0] = '新規追加';
}
function change_post_object_label() {
global $wp_post_types;
$labels = &$wp_post_types['post']->labels;
$labels->name = 'お知らせ';
$labels->singular_name = 'お知らせ';
$labels->name_admin_bar = 'お知らせ';
$labels->add_new = '新規追加';
$labels->add_new_item = 'お知らせを追加';
$labels->edit_item = 'お知らせの編集';
$labels->new_item = '新規お知らせ';
$labels->view_item = 'お知らせを表示';
$labels->search_items = 'お知らせを検索';
$labels->not_found = 'お知らせが見つかりませんでした';
$labels->not_found_in_trash = 'ゴミ箱にお知らせは見つかりませんでした';
}
add_action( 'init', 'change_post_object_label' );
add_action( 'admin_menu', 'change_post_menu_label' );一方、投稿の「カテゴリー」や「タグ」のラベルを変更する方法はなかなか見つかりませんでしたが、「項目名の変更 管理画面編 WordPress – WordPress Snippet」でそのヒントが掲載されていました。
カテゴリー: HTML/CSS/JS
この記事は2016年10月7日に書かれたものです。情報が古い可能性がありますのでご注意ください。
CSS で背景にグラデーションを表現する際に利用する linear-gradient() ですが、次のように値を指定することで斜線を表現することができます。
※以下の具体例の表示は、実際に CSS を使って表示しています。ブラウザによって見た目が異なるほか、Internet Explore 9 など linear-gradient() に対応していないブラウザでは斜線が表示されません。
.selector {
background: linear-gradient(45deg, #fff, #fff 49%, #f00 49%, #f00 51%, #fff 51%, #fff);
}45度の方向（左下から右上となります）で、領域の0から49%までを白、49%から51%までを赤、51%から100%までをまた白で塗り潰すという感じですね。
しかし、45度に傾いた斜線の場合は比較的きれいに表示されるのですが、中途半端な角度ではギザギザが目立ちます。まるでアンチエイリアスが効かない古いブラウザで見ている感覚です。
カテゴリー: HTML/CSS/JS
この記事は2016年10月6日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress では、一般設定でタイムゾーンを設定することによって、投稿日時などがその地域の日時で表示されます。日本時間の場合は “東京” または “UTC+9” を設定します。
先日、ユーザー管理のために使用したプラグインで、登録日時は日本時間で表示されるのに、更新日時とログイン日時が9時間プラスされて表示されるという現象が発生しました。世界標準時（UTC）は日本時間より9時間遅れ。今回は9時間プラスなので、世界標準時で表示されているわけでもありません。
原因がわからないので、仕方なく jQuery で日時を修正することにしたのですが、実装後あらためて確認すると、一般設定で “東京” を設定しているうえに、functions.php に
date_default_timezone_set('Asia/Tokyo');を記述していたことが原因のようでした。通常はこのように設定していても問題ないと思うのですが、プラグインのバグでしょうか、functions.php の記述を削除したら正しく表示されました。
でも折角ですし、また何か役立つ場合があるかもしれませんので、今回は表示された日時を9時間戻しましたが、世界標準時（UTC）で表示された日時を日本時間に書き替える（9時間進める）方法を記しておきます。
この記事は2016年8月3日に書かれたものです。情報が古い可能性がありますのでご注意ください。
近年、主に自治体等のサイトで、文字サイズを拡大したり背景色を変更したりできる機能（以下、“閲覧支援機能”とします）を提供しているサイトをよく見かけます。よくWebページの上部にある、「文字サイズ：[小][中][大]」とか「背景色：[白][黒][青]」などとあるボタンです。読み上げ機能や漢字にルビを振る機能が提供されている場合もありますね。自治体サイト向けの CMS に標準で閲覧支援機能が付属しているものが多いからということもあるのでしょう。
ただ、このような機能を提供することは悪いことではないと思いますが、閲覧支援機能を提供することがアクセシビリティだと、勘違いされているケースがかなり多くあるように感じます。
中には、Webサイトのアクセシビリティについて記載されているページに、閲覧支援機能を提供していることだけが、あたかもアクセシビリティに配慮していることをアピールしているかのように書かれているサイトも見受けられます。そのため、一般ユーザーまでもが、閲覧支援機能が提供されてないWebサイトは文字サイズを拡大したり背景色を変更したりすることができない、アクセシブルではないと判断してしまう懸念もあります。
カテゴリー: WordPress
この記事は2016年7月22日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress の投稿画面のスタイルを実際のサイトの見た目に近づけるために、ビジュアルエディタ用の CSS を作成して管理画面に読み込ませることができますね。editor-style.css などとして CSS ファイルを用意し、functions.php の中で
add_editor_style("editor-style.css");を記述することで、ビジュアルエディタにeditor-style.css が適用されます。
しかし、これでは記事部分の CSS を変更する際に、公開画面用の CSS とビジュアルエディタ用の CSS の両方を編集する必要があります。
そこで editor-style.css を公開画面と共有すると便利です。header.php の中で style.css と共に読み込ませるか、style.css の先頭で editor-style.css をインポートすればよいわけですが、記事部分を囲む要素の class 属性の値を工夫する必要があります。
カテゴリー: その他
この記事は2016年7月8日に書かれたものです。情報が古い可能性がありますのでご注意ください。
これまで、サイトを構築する前のサイトマップ（構成図）や画面のワイヤーフレームを作成する際、Cacoo というオンラインドローツールを使っていました。
Illustrator や PowerPoint などの Office アプリでも作れるのですが、専用ツールを使うことで効率よく作成することができます。幾つかのサイト制作や提案のためのサイトマップやワイヤーフレームのほか、昨年、オフィスの配置を変更する際のレイアウト図も Cacoo を使って作りました。
ちなみに、Cacoo の編集画面は Flash が使われていますが、HTML5 に全面移行することが6月22日に発表されています。
Good-Bye Flash ~ CacooはHTML5で生まれ変わります – ヌーラボ [Nulab Inc.]
ただ、Cacoo は無料で作成できるシートは25枚まで。さらに PDF や SVG に書き出そうとすると月額490円の有料プランに加入しなければなりません。そのため、普段は無料プランで利用し、PDF に書き出す必要がある時にだけ、一時的に1ヶ月間だけ有料プランを契約していました。
カテゴリー: その他
この記事は2016年6月14日に書かれたものです。情報が古い可能性がありますのでご注意ください。
Word や Excel などの Office ファイルを開くと、“~$ファイル名.xlsx” といった “~$” から始まる名前の一時ファイルが作られます。通常はファイルを閉じるとこの一時ファイルは消えるのですが、外部のサーバに保存してあるファイルを開いた場合などに、一時ファイルが残ったままになることがあります。
これは、Office 2010 以降の「保護されたビュー」が標準で有効になっていることが影響しているようですが、これを無効にすると当然セキュリティが甘くなってしまいます。
今回、WebDAV 機能が使えるレンタルサーバを使って複数人でファイルを共有する案件があり、それぞれに WebDAV アカウンントを作成して、Windows エクスプローラーのネットワークの場所に各自の共有フォルダへのアクセスを設定してもらいました。
そして、運用してみると案の定上記の一時ファイルが残ったままになってしまいました。少しなら都度削除してもらうなどしてもらえばよいのですが、同じファイルを開くたびに “~$~$ファイル名.xlsx” のように一時ファイルが増えていき、非常に邪魔な存在になります。
クライアントからも「何か解決法はないですかね？」といった相談を受けていたので、一時ファイルを一括削除するプログラムを PHP で作り、cron を使って定期的に実行するようにしてみました。
カテゴリー: WordPress
この記事は2016年6月7日に書かれたものです。情報が古い可能性がありますのでご注意ください。
Webページを Facebook 等にシェアした際に適切な情報を表示させる OGP。これを WordPress のテーマファイルに設定する方法は、ググるといろいろ紹介されています。
その中の og:image を設定する部分の記述ですが、大抵、次のように紹介されています。
<?php
$str = $post->post_content;
$searchPattern = '/<img.*?src=(["\'])(.+?)\1.*?>/i'; // 投稿記事に画像があるか調べる
if ( is_single() or is_page() ){ // 記事か固定ページの場合
if ( has_post_thumbnail() ){ // アイキャッチがある場合
$image_id = get_post_thumbnail_id();
$image = wp_get_attachment_image_src( $image_id, 'full');
echo '<meta property="og:image" content="'.$image[0].'">'. "\n";
} elseif ( preg_match( $searchPattern, $str, $imgurl ) && !is_archive() ){ // アイキャッチは無いが画像がある場合
echo '<meta property="og:image" content="'.$imgurl[2].'">'. "\n";
} else { // 画像が1つも無い場合
echo '<meta property="og:image" content="'. get_bloginfo('template_url'). '/images/ogp_image.png">'. "\n";
}
} else { // 記事や固定ページ以外の場合（ホーム、カテゴリーなど）
echo '<meta property="og:image" content="'. get_bloginfo('template_url'). '/images/ogp_image.png">'. "\n";
}
?>記事ページか固定ページの場合、アイキャッチ画像があればそれを、アイキャッチ画像は無いが本文に画像がある場合はそれを、画像がない場合と記事や固定ページ以外は予め用意したデフォルト画像（上記では ogp_image.png）を設定するという記述です。
ただ、Facebook の仕様では 200×200px に満たないサイズの画像は og:image として設定できないため、上記の記述では、本文内に小さい画像がある場合は、シェアした際に画像が表示されません。
そこで、画像が 200×200px に満たない場合はデフォルト画像を設定するようにしてみました。
この記事は2016年3月12日に書かれたものです。情報が古い可能性がありますのでご注意ください。
以前、「Peter’s Collaboration E-mails」と「User Role Editor」、そして「WP Post Branches」プラグインを使って、公開中のページを更新する際の承認フローを実装した記事を書きました。
→ 公開中のページを公開したまま編集して承認待ちにする
これでうまく実装できたかに思えたのですが、ひとつ問題がありました。どんなに検証を重ねていても、いざ運用してみると見えなかった問題が明らかになるということは多々あります。
今回の案件、元々それぞれのコンテンツに対して担当者は1人という設定だったのですが、運用開始時点でいくつかのコンテンツに対しては複数の担当者が携わることになり、そこで問題が見つかりました。それは次のようなパターンです。
“WP Post Branches プラグインによるブランチの作成者をログインしているユーザーに置き替える” の続きを読む »