PathLink: 砂塵の彼方 > 徒然日記 > 小ネタ

エントリー

カテゴリー「小ネタ」の検索結果は以下のとおりです。

[freo] 閲覧制限の扱いをフィルタリングとその他で分ける

「本体設定」の「閲覧制限」の項目で「制限された記事の表示」を「一覧に表示しない」に設定すると、デフォルトではユーザー登録及びグループによる制限がかかっている記事のほか、フィルタリングされた記事も存在が隠蔽されるようになります。
これを、フィルタリングされた記事とその他の制限で、扱いを別々に設定できるようにする方法です。

なお、プログラム本体を書き換えますので、取り扱いには十分気をつけて下さい。
少しでも疑問や不安を感じる時は、この改造は行わない事をお勧めします。

(1)準備

必ず、本体の設置とプラグインの追加が全て終わってから実行してください。

(2)設定ファイルの編集

configs/view.ini の11行目辺り、

;restricted_display bool   "一覧に表示する|一覧に表示しない"

の直後に、

;filtered_display   bool   "一覧に表示する|一覧に表示しない"

を追加します。
次に、 configs/view.ini の最後の行、

;exit

の直前に

;フィルタリングされた記事の表示
filtered_display = Off

を追加します。
これで、フィルタリングされた記事用の設定項目ができました。

(3)プログラム本体の編集

全てのphpファイルを対象に、キーワード「$freo->config['view']['restricted_display']」で文字列検索を行います。
発見箇所の全てが制限された記事の表示に関わる部分で、変更の対象となります。
後日プラグインを追加するなどして新たに閲覧制限を扱う箇所が増えた時には、その都度、該当する部分に下記変更を行って下さい。

※※※
見つかった部分をエディタで開いてみると、以下のような感じになっているはずです。
(※エントリを扱っている例です。ページを扱う場合は変数名が $entry_~ ではなく $page_~ になります。)

//制限されたエントリーを一覧に表示しない
if (!$freo->config['view']['restricted_display'] and ($freo->user['authority'] != 'root' and $freo->user['authority'] != 'author')) {
    $entry_filters = ~
    (フィルターが設定されている記事の扱い)

    $entry_securities = ~
    (ユーザー登録やグループで制限されている記事の扱い)
}

上記の1~2行目をユーザー登録やグループで制限されている記事を扱う部分の前にコピー&ペーストし、上側の if ~の最後を } で閉じます。

//制限されたエントリーを一覧に表示しない
if (!$freo->config['view']['restricted_display'] and ($freo->user['authority'] != 'root' and $freo->user['authority'] != 'author')) {
    $entry_filters = ~
    (フィルターが設定されている記事の扱い)
}

//制限されたエントリーを一覧に表示しない
if (!$freo->config['view']['restricted_display'] and ($freo->user['authority'] != 'root' and $freo->user['authority'] != 'author')) {
    $entry_securities = ~
    (ユーザー登録やグループで制限されている記事の扱い)
}

これで、元々1つだった条件文が2つになりました。
次に、上の if 行中の「restricted_display」を「filtered_display」に書き換えます。
コメントの解説も、分かり易く変えておいても良いかもしれません。

//フィルタリングされたエントリーを一覧に表示しない
if (!$freo->config['view']['filtered_display'] and ($freo->user['authority'] != 'root' and $freo->user['authority'] != 'author')) {
    $entry_filters = ~
    (フィルターが設定されている記事の扱い)
}

//制限されたエントリーを一覧に表示しない
if (!$freo->config['view']['restricted_display'] and ($freo->user['authority'] != 'root' and $freo->user['authority'] != 'author')) {
    $entry_securities = ~
        (ユーザー登録やグループで制限されている記事の扱い)
}

この変更を、検索で発見した全ての箇所に施します。

(4)設定の変更と反映

設定の変更は、本体設定>閲覧制限 で行います。
設定を変えた後、適当なエントリとページを各1つずつ更新すると、タグの集計など一部設定変更だけでは情報が更新されない部分にも設定内容が反映されます。

拍手送信フォーム

[砂塵の彼方] OGP及びTwitter Cards対応(超不定期日記)

Twitterに更新情報を流すので、OGPTwitter Cardsに対応してみました。
その手順記録です。

(1)OGP対応
Twitter Cardsには専用の設定タグがありますが、その多くはOGPの設定で代用できます。
OGPの方が汎用性がありますので、書けるところはOGPで書いてしまう事にしました。

HTMLファイルのヘッダ部分に専用のタグを入れます。
サイトやブログの個別の記事ならこんな感じ。

<meta property="og:title" content="※記事タイトル" />
<meta property="og:type" content="article" />
<meta property="og:url" content="※記事のURL" />
<meta property="og:image" content="※サムネイル画像URL" />
<meta property="og:description" content=" ※記事概要(200文字以内、100文字以内推奨)" />
<meta property="og:site_name" content="※ブログタイトル" />

OGPの仕様で上から4つは必須、その下の2つは任意です。
が、og:imageは敢えて空欄にしてあります。記事毎に画像を準備はできないし、かと言って記事内容に関係ない共用画像の指定は不可らしく。Twitter Cardsの方ではサムネイル画像は任意項目のため、無しでいきます。
og:descriptionは任意項目ですが、Twitter Cardsで必須項目の代わりとして使われます。必ず何か入れるようにしてあります。

OGP絡みでやる事はこれで終わりです。
申請等は必要ありません。


(2)Twitter Cards対応
HTMLファイルのヘッダ部分に専用のタグを入れます。

<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="※サイトオーナーのTwitterID" />
<meta name="twitter:creator" content="※記事執筆者のTwitterID" />

同時にOGP対応する場合は、この3つだけ書けば大丈夫です。
twitter:cardに指定できるカードの種類はいくつかあります。更新情報のお知らせなら記事のタイトルと概要ぐらい表示されればいいので、今回はSummary Cardを選びました。
記事に関する情報は、og:~の方から読んでくれます。


(3)ファイルのアップロード
タグを追加したファイルを、サーバにアップロードします。


(4)Twitter Cards利用申請
最後に、Twitter Cardsの利用申請を行います。

Twitter公式のvalidator toolにChromeなどWebKit系のブラウザで(※1)アクセスし、Twitterアカウントでログイン。
「Validate & Apply」のタブをクリックし、タグを追加したページのURLを入力して情報が正常に表示されるか確認します。
(↑Enter URL to validate の所にURLを入力、Go!ボタンを押す)

表示項目の取得状況やテスト表示を見て問題が無ければ「Request Approval」をクリックし、次に出てくる連絡先やサイト情報を書く欄で必須項目を埋めて(※2)申請を実行します。

正常に申請が終わると、Twitterから通知のメールが届きます。
……が、これが短い英文+URLの一見怪しい感じだったりしましてですね。。
いつまでも届かない場合は、一度迷惑メールフィルタに引っかかっていないか確認することをお勧めします。

(※1)Firefoxではカードのテスト表示ができませんでした。ただ、実際の表示が見えなくても、表示項目がきちんと取得できていれば問題ないと思います。

(※2)だいたいの項目は、申請に使ったTwitterアカウントの登録情報や、直前にvalidator toolで取得した情報を利用して自動入力済みです。私が手入力したのは、サイトの概要とサイトオーナーのTwitterID欄だけでした。


これで全て完了です。
前からやろうと思っていたのを、やっと実行しました。
テンプレートに細工すれば簡単なここだけでもやっとこうかと、、、。


※Twitter Cards補足メモ

  • Twitter Cardsは、申請した後、反映されるまでにしばらくかかるようです。
    私はほぼ直後と言って良いタイミングで使えるようになりましたが、検索で探すと、もっと時間がかかったという話も出ています。
  • 申請はカードの種類ごとに必要です。(今回はSummary Cardのみ申請)
  • 申請は、指定したドメイン内の記事全てに適用されます。独自ドメインでない場合は記入に工夫が必要かもしれません。(独自ドメインと違いがあるのかは調べてません)
  • 基本的に、TwitterにURLが書き込まれた時点の情報が表示されます。
    validator toolで表示のチェックを行ったURLについては、その都度情報が更新されるようです。
  • Twitter CardsのSummary Cardにもサムネイル画像の表示機能があり、twitter:image:srcに画像のURLを指定します。画像は120×120ピクセル以上、サイズは1MBまで。表示は120×120ピクセル固定です。
    指定が無い場合はog:imageから読み込んでくれるのですが、og:imageの推奨サイズは非常に大きく、共通で使うのはかなり無理がありそうです。
拍手送信フォーム

メイリオ

当サイトの通常ページは表示フォントの指定が総称ファミリ名のみなので、フォントはだいたいのところ何でもあり(※1)です。基本的には、ブラウザでプロポーショナルフォントまたは標準フォントとして指定したフォントか、OSの標準フォントで表示されると思います。
そこで、これまで未確認だったWindows Vista以降での見え方を確認しようと、メイリオを導入してみました。日本語部分が等幅になる上に当然ながら文字のデザイン自体が異なるため、MS UI GothicやMS Pゴシックとは劇的に見た目が違います。
このサイトはフォントが何でもそれなりに見られるように作っているつもりなのですが、ちょっと自信がなくなってきました。

※※※
メイリオ導入後、表示がメイリオに変わったサイトが結構あります。ページの表示にメイリオ指定している、もしくはメイリオをMS ゴシック系のフォントより優先的に指定しているサイトがそれなりの数あるという事です。当然と言えば当然ですか。

ただ、文字にアンチエイリアスがかかるのを見辛いと感じてしまう性質の人間にとって、これは割と困りどころです。
画面のプロパティでフォントのアンチエイリアス(←「スクリーン フォントの縁をなめらかにする」というアレです)をONにすると、あちこちでぼやけてにじんだような文字に遭遇する羽目になります。
それならと通常通りアンチエイリアスなしで見ると、やや丸っこいメイリオのデザインが災いしてギザギザ感満載な表示に…(※2)。
どちらにしても見辛いのは変わりません。
その都度Webページ指定のフォントを無視する設定に変えるのも面倒となると、もうデフォルトでブラウザ設定に従うようにするしかないか。。。

私はこんな(↑)ですが、文字がきれいに表示されていいですよ、と仰る方は多いですね。人の好みは本当に色々です。


(※1)
ブラウザの仕様によっては何でもありにならない場合もあります。

(※2)
IEでは詳細設定の「HTML で常に ClearType を使用する」にチェックを入れると、画面の設定とは関係なくブラウザだけClearTypeを使用可能です。

拍手送信フォーム

文字サイズと記事表示幅

先日、サイト内で動的処理をしない部分について、文字サイズの固定と記事表示部の幅固定を外しました。ウインドウ幅いっぱいを使い、文字の大きさはブラウザの設定を基準とした相対的な指定になります。
この修正は2008年から密かに(?)進めてきたサイト改修計画の中で「スタイルシート無効でも大きく崩れない」を目標とした修正の次のステップにあたります。ブラウザの設定に従う事で、来訪者の方お一人ずつの事情に沿った個人にとってより見易い表示を目指そうとするものです。
2年がかりでようやくここまで来る事が出来てやれやれといった心境ですが、心配なのは、レイアウト崩れと、記事表示部の横幅が広くなった場合に整形のための改行をしていない文章が読み辛くなる事ですね。どうしたものか…。

企業や官公庁のサイトでも、文字サイズ・記事表示幅とも固定のところを結構見かけます。恐らくこれは「レイアウトが崩れる心配が無い」という意味での見易さを優先した結果だろうと思います(これまでの自分がそうでした)。
近頃のサイトでメニューから文章から全て画像になっていたり、FLASH表示だったりするのも、見た目の美しさに加え、レイアウト崩れ対策の面があるのかもしれません。

個人によって千差万別の「見易さ」を追及する事はゴールが無いマラソンのようなものです。たぶん正解はありません。
閲覧環境が多様化している今、どんな端末、どんなブラウザでも何の問題もストレスもなく閲覧可能を実現するのは非常に困難ですが、せめて「どんな環境でもそれなりに読める」ぐらいはいけたらなぁと思っています。が、それもまた厳しい道程ではあります。

※※※
改修工事、踊る金狼亭はこれで完了かな...。
時空の塔側はまだまだ。


(2011/2/7追記)
> 記事表示部の横幅が広くなった場合に(中略)読み辛くなる~
この記事を書いた時点ではスタイルシートでmax-widthの指定をすればたぶん問題解決と考えていたのですが、IEだけ上手く反映されない事が分かり、面倒になってそのまま放置していました。
が、最近になって、IE含めて解決できる方法についてとある方からミミヨリ情報を頂きました。興味がある方は下のリンクから飛んでみて下さい。

[外部リンク]
CSS Lecture|min-width、min-height、max-width、max-heightをIE6でも実装する方法

拍手送信フォーム

ページ移動

  • 前のページ
  • 次のページ
  • ページ
  • 1

ユーティリティ

2024年04月

- 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 - - - -

エントリー検索

エントリー検索フォーム
キーワード


翳の回廊(絵置き場)の一部を
TINAMIのスペースに置かせて頂いています。

pixivでも何かやっている……かも。

新着エントリー

cwNowUpのご利用条件の変更(7/14~7/18)について
2022/07/20 23:51
cwNowUp 0.816β
2022/07/12 20:40
cwNowUp 0.815β
2022/04/20 20:30
cwNowUp 0.814β
2022/01/29 00:00
cwNowUp 0.811β~0.813β
2022/01/26 23:40

新着コメント

Re:Re: CWBBS[26]-14
2015/06/23 from simoom
Re:Re: CWBBS[26]-14
2015/06/22 from ああ
Re:Re: CWBBS[26]-14
2015/06/22 from simoom
Re:Re: CWBBS[26]-14
2015/06/21 from 権限がありません
Re:Re: CWBBS[26]-14
2015/06/21 from あ

過去ログ

Feed