ラベル 作業覚書 の投稿を表示しています。 すべての投稿を表示
ラベル 作業覚書 の投稿を表示しています。 すべての投稿を表示

2016年6月15日水曜日

WordPress(ワードプレス)アーカイブテーマでカスタム投稿の名前表示

WordPress(ワードプレス)覚書

※使用するテーマによって、表示される内容が違うので、要確認。

カスタム投稿を使った一覧表示の場合、デフォルトだと、
archive.php
ファイルで表示されるので、content内(またはメインのコンテンツ画面内)で表示される
ページタイトルが「アーカイブ」になってしまいます。

これを、カスタム投稿で作った名前にする方法。

<?php $postname=get_post_type_object(get_post_type())->label;
echo $postname;
?>

表示タイトル部に、上記のphpを挿入。


2013年8月27日火曜日

WordPress ページナビゲーション制作

ワードプレスのページナビゲーション(記事一覧)をプラグインを使わずに制作します。

プラグインを使わないメリットは、バグ等の回避やバージョンUPに伴う不具合回避出来ます。
プラグインは確かに便利ですが、CMSにとってはトラブルの原因となる確立が高いので、簡単な物であれば、自作する事をお勧めします。
自作する事で、自らのスキルも上がりますから、一石二鳥です。





目的

ページナビゲーションは複数ある一覧リストページを快適に使うためのナビゲーションです。
今回の改造は、元のプログラムでは、現在見ているページを中心に、新旧で2ページ分しか表示しない※1ので、記事量が増えた場合に、最新の記事や古い記事にアクセスしにくいと言う問題を解消する為に、ナビゲーションに最新記事と最古の記事にアクセスすための、ボタンを追加します。

※1表示件数は任意に設定出来ますが、ひとまず書籍通りの内容で話を進めます。




元になるソース

一覧表示が必要な元ファイル。
home.php
category.php
など。

ページナビゲーションを表示したい箇所に、下記phpコードを追加します。

<?php get_template_part('pagenation'); ?>



プログラムファイル
pagenation.php

<?php $maxpage = $wp_query->max_num_pages;
$current = $paged;
if(!$current) {$current = 1;}
?>


<?php
$minpage = 1;
$sidenum = 2;
$shownum = $sidenum * 2+ 1;


if($current > $sidenum && $current < $maxpage-$sidenum+1){
 $start = $current - $sidenum;
 $end = $current + $sidenum;
} elseif($current <= $sidenum) {
 $start = 1;
 $end = min($shownum,$maxpage);
} else {
 $start = max($maxpage-$shownum+1,1);
 $end = $maxpage;
} ?>


<?php if($current <= $sidenum+$minpage): ?>
<?php echo ''; ?>
<?php else: ?>
<a href="<?php echo get_pagenum_link($minpage); ?>">&lt;&lt;</a>
<?php endif; ?>


<?php previous_posts_link('&lt;'); ?>
<?php for($i=$start; $i <= $end; $i++): ?>
 <?php if($i == $current): ?>
 <span><?php echo $i; ?></span>
 <?php else: ?>
 <a href="<?php echo get_pagenum_link($i); ?>"><?php echo $i; ?></a>
 <?php endif; ?>
<?php endfor; ?>
<?php next_posts_link('&gt;'); ?>


<?php if($current >= $maxpage-$sidenum): ?>
<?php echo ''; ?>
<?php else: ?>
<a href="<?php echo get_pagenum_link($maxpage); ?>">&gt;&gt;</a>
<?php endif; ?>


解説

////////// 現在ページへのリンク回避 //////////
<?php $maxpage = $wp_query->max_num_pages;
$current = $paged;
if(!$current) {$current = 1;}
 ?>

これは、現在閲覧しているページへのリンクを設定しない処理です。


////////// 記事リストのループ処理 //////////

<?php
$minpage = 1;
$sidenum = 2;
$shownum = $sidenum * 2+ 1;


if($current > $sidenum && $current < $maxpage-$sidenum+1){
 $start = $current - $sidenum;
 $end = $current + $sidenum;
} elseif($current <= $sidenum) {
 $start = 1;
 $end = min($shownum,$maxpage);
} else {
 $start = max($maxpage-$shownum+1,1);
 $end = $maxpage;
} ?>

ページ表示に必要なループ処理です。
$minpage はページ最小値として1を入れるための変数です。
$sidenum は現在ページを中心に、何ページ表示させるかの変数です。
$shownum は現在ページを中心にして、$sidenum分+1ページ(現在ページ分)を表示させる変数です。

if分以下は表示ループ処理です。



////////// ナビゲーションの表示 //////////


// 最古記事へのリンク処理 //
<?php if($current <= $sidenum+$minpage): ?>
<?php echo ''; ?> ←上のifがtrueならば、非表示(ブランク表示)
<?php else: ?>
<a href="<?php echo get_pagenum_link($minpage); ?>">&lt;&lt;</a>
<?php endif; ?>


最古記事へのリンク処理ですが、最初の1行で最後の記事ページがリストとして表示された場合は、リンクを表示しないように設定しています。




// ページ番号処理 //
<?php previous_posts_link('&lt;'); ?>
<?php for($i=$start; $i <= $end; $i++): ?>
 <?php if($i == $current): ?>
 <span><?php echo $i; ?></span>
 <?php else: ?>
 <a href="<?php echo get_pagenum_link($i); ?>"><?php echo $i; ?></a>
 <?php endif; ?>
<?php endfor; ?>
<?php next_posts_link('&gt;'); ?>


1~順にページ番号を表示させます。また、閲覧中のページにリンクを設定しないようにも、処理をしています。



// 最新記事へのリンク処理 //
<?php if($current >= $maxpage-$sidenum): ?>
<?php echo ''; ?> ←上のifがtrueならば、非表示(ブランク表示)
<?php else: ?>
<a href="<?php echo get_pagenum_link($maxpage); ?>">&gt;&gt;</a>
<?php endif; ?>


最古記事と同様に、ナビゲーションリストに最後のページ番号が表示された時点で、リンクボタンを非表示にしています。

ナビの表示にブランクを使ったのには、ifループで妙な結果を出さない措置です。
もう少し上手い処理の仕方もあるかと思いますが、php初心者に理解しやすい様に、あえてブランクを表示させてあります。

phpを理解している方ならば、この辺りの処理をもう少し綺麗に出来ると思います。


2013年5月13日月曜日

アプリ設定メッセージ July 2013 Breaking Changes


今回は
「アプリ設定メッセージ」
についてのお話。

ゴールデンウイークの頃から、アプリ設定のメッセージに「緊急修正」です。
というアラートがたまに入って来ていたのですが、う~ん翻訳しても、どうも意味が良く解らない??





英語力が無いからなぁ。

アラート
July 2013 Breaking Changes

Your app, Hondaweb has not enabled the migration for the July 2013 Breaking Changes.
Once you have confirmed your app is compliant or unaffected by the July 2013 Breaking Changes, set the migration setting to "Enabled" in the 詳細設定 section of the App Dashboard. This will apply the July 2013 Breaking Changes to your app and prevent you from receiving future alerts about these changes.
Hondaweb, is currently using the following deprecated features:
Social Plugins (Like Button, Like Box) without absolute URL's in their `href` parameter.
These changes will be permanently enabled for all apps in 58 days on 2013年7月11日.


内容をみると、どうやら
2013 Breaking Changes
を修正しないと、7月以降にアプリで問題が発生する可能性があるから、修正してください?

と言った内容らしいので、とりあえず修正をしておきました。

アラート画面の下にある【移行設定を編集】ボタンを押すと、設定画面に切り替わるので、
2013 Breaking Changesの項目を、有効にして保存します。



作業はこれだけ。

これで、メッセージ画面には「これ以上修正の必要はありません」と新たなメッセージが表示されます。



どうもこの設定を有効にしていないと、このアプリに関連する【いいねボタン】と【Like Box】に不具合がでる?あるいは不具合が出ても、アラートが届かない?

と言う内容の様です。


しかもこれアプリ毎に対応しないとダメな様で、複数アプリを管理している人は、全てのアプリに個別対応が必要です……

つまり、アプリ毎に全て設定し直し、と言う結構面倒な対応が必要です。
サイト制作会社で、お客様のアプリを多数管理している所などは、かなり面倒な作業になります。

しかし、日本語のメッセージぐらい出しても良さそうなモノだが……
毎度のことだけど、技術情報は日本語にローカライズしてから、アナウンスして貰いたいもんです。

2012年12月19日水曜日

Facebookページの予約投稿と修正。

ご無沙汰しております。
気が付けば、一月近く更新していませんでした。
最近Facebook関連の雑務が色々とあって、企業でもFacebookの重要性を理解して、動く方向にシフトしている企業様もいいです。

しかし、中小企業の場合はやはり情報収集能力の違いと言いますか、まだまだインターネットでの集客そのモノに懐疑的なお客様もいます。

そんな方々とお話する日々で、Facebookの詳細機能についてのお話が多々出ます。
と言う事で、本日のお題は

【Facebookページの予約投稿と修正】です。

Facebookページの予約投稿機能は皆さんご存じの方もいるかと思います。
え?そんな機能知らない?

そんな方は下記の記事をご覧ください。
要するに、普通のブログと同じ様に、決められた時間に投稿をUPしてくれる機能です。

リリースは、半年ほど前ですが、以外と知られていない様なので、一応あげておきます。



また、この予約機能は一度設定した後で、変更する事が少々面倒なようです。

通常この手の変更は、設定した画面を使って再度設定変更するやり方がポピュラーですが、Facebookページでは【アクティビティログ】の画面から行ないます。アクティビティログは他にも各種の変更機能を持っているので、何らかの変更が必要な場合に、その変更方法が不明ならば、真っ先にアクティビティログを見てみましょう。

また、Facebookページに限った事ではないのですが、デザイン上の制約か、はたまたFacebookの陰謀?でしょうか(笑
ボタン機能を言葉(テキスト)ではなく、アイコンのみで表示して言葉で示さない場合が多くあります。
そのアイコンも目立たない色なので、解りにくい場所や一見するとデザインに見えるボタンなどがあり、実際に触らないとその機能が解らない物が多数あります。

確かに、世界中で使われているFacebookですから、世界標準でのデザイン性が求められるのでしょうが、もう少し親切であっもいい様な気もしますけどね。








2012年10月26日金曜日

PC復旧の手順 今さら……第45回


今さら聞けないネットのあれこれ。
今回はWindowsXPで
「PCが壊れた?と思ったらやる作業」
についてお話します。


重要度:★★★★★
難易度:★~★★★★★(場合によって)



先日、仕事で使っているPCが突然ダウン!

原因を探ったけど、最終的には【不明】でした。
胡散臭い挙動は幾つかあったのですが、最終的に決めてが無く【これが原因】と言えるこのがありませんでした。 実際の話として、【原因不明の不具合】はよくあることですが、気分的にすっきりしません。

とりあえず、現状なんとか動いているので今は【これでよし】としています。

と言う事で今回はPCが不調になった時に行なう修復手順と言うお話をしましょう。

復旧方法の詳細につては、それそれの項目をクリックして頂ければ、Googleでの検索画面が表示されますので、それを確認してください。

そう言えば、今回のお話はあくまでもWindowsXPでのお話です。
Vistaや7では若干違いますので、ご了承ください。

OSが通常起動する場合の手順 ※可能であればセーフモードで作業してください。
1.ウイルスチェック
2.ハード空き容量確認
3.復元ポイント
4.デフラグ
5.ディスククリ―アップ
6.レジストリ修復

上記の方法でまだダメなときは、下記の方法を行う。※1

OSが起動しない場合
1.システムの再インストール(OSの上書き)
2.クリーンインストール(ハードディスクをフォーマット後、システムを最初からインストール)


OSのインストールをしても起動しない・あるいは不安定な場合。
この時点で、一般的な方はPCをサポートセンターなり、ある程度専門知識を持った方に診てもう事が良いでしょう。 この症状の場合ハード系トラブルの可能性が高いので、メモリー交換・ハードディスク交換を行う必要があります。また最悪の場合は、マザーボードが破損している可能性があるので、自作PC以外はこの時点で【終わり】ですね。


/////////////////////////

ざっとあげると上記の様な事を行う訳ですが、殆どの場合【レジストリ修復】までの作業を行えば、不具合は解消されます。
PCの不具合で多いのは、【ハードディスク容量不足からくる、システムの不安定化】【レジストリー改変による動作不良】の二つの場合が殆どです。※2

Windowsに限らす、PC上のOSは通常ハードディスクの空きスペースを使って様々な処理を行っています。

この空き容量が少ないと、その処理が実行出来ない為に、動作が遅くなったり【仮想データを置いておく場所】が無い為にプログラムが動かせないなどの不具合がおきます。

そう言った不具合を無くす為にも、ハードディスクの空き容量は15~20%を見てください。10%以下の空き容量では、動作が不安定になり、最悪の場合はデフラグすら行えなくなります。

基本的にOSが入っているCドライブにあるデータ(プログラムを含め全てのデータ)は少なければ、少ないほどPCは快適に動作してくれます。

次に多い不具合は【レジストリ】に関する不具合です。
レジストリとは、アプリケーションなどで使用する【拡張情報】として扱われるファイルで、OSまたはアプリケーションなどによって、情報が書き変わる性格のモノです。

このレジストリが、OSの不具合などでいきなりシャットダウンされると、書き込まれた情報が破損してしまい、関連したプログラムが上手く動作しないと言った不具合に見舞われます。

そこで、このレジストリを修復する事で、不具合を解消するわけです。

レジストリ修復の方法は、色々とありますがsfc /scannow システムファイルチェッカーと言うモノがWindowsにはあります。また無料・有料のソフトとして、レジストリーを修復するソフトも有りますので、試してみるのもよいでしょう。

ただし、レジストリの修復は必ずしも良い結果をもたらす訳ではないので、注意が必要です。
と言うのもレジストリを変更すると言う事は、【現状の設定とは違う設定に書き換える】とも言えます。
つまり、レジストリを変更することで、今まで使えていたソフトやサービスが使えなくなる可能性もあります。大抵の場合は、アプリケーションの削除と、新規インストールで問題は解決できますが、そう言ったリスクを理解した上で行う事が求められます。


いずれにしても、不具合が出て動作に不安があるようなら、ある程度覚悟を決めて徹底的に【修復】した方が後々いい結果を招きます。



/////////////////////////////////////

※1
代表的な作業項目を列挙しただけです。
本来であれば、メモリーチェックやHDDチェックなども行なう事が必要ですが、今回は省略させて頂きました。

※2
ウィルスによる不具合は除きます。




2012年10月12日金曜日

Modx ユーザー別管理画面の編集関係。


ご無沙汰しています。

ここのところ、少々立て込んでいて放置していましたが、時間を見てまた再開します。

今日はModxの覚書です。

ユーザー管理関連で、色々と実験をしていたので、その内容の覚書です。

※2012/10/15 追記
この設定方法は、Modx1.0.6.-r6以降のバージョンにて行なってください。
r6以前のバージョンだとエラーが発生して、編集したコンテンツを保存できません。

別な方法により設置は可能でしょうが、今回の方法ではr6以前のバージョンでは対応致しません。
下記の方法を試される場合は、
必ずr6にバージョンUPした状態で、行なってください。



ユーザー管理から、ロール設定、グループ設定等を行うと、設定されたユーザー権限のページしか表示できない機能がある事はご存じかと思います。

しかし、フォルダの階層構造上、どうしても【権限が無い】あるいは【グループ制限なし(Public)】のページを表示しなければならない場合があります。

それは、編集させたいページの上位フォルダーとされるページです。

ロール設定では、フォルダ(コンテナ)に対し設定された管理権限が無いと、そのフォルダ内の物は全て表示されなくなります。(編集可能なコンテンツはありませんと表示されます)

このようなときに、そのフォルダは【グループ制限なし(Public)】※1状態にして、誰もが閲覧・編集可能な状態にするしか手段がありません。

しかし、そのページはユーザーに編集させたくない場合にどうしたらよいか……

と言う事で、どうしても表示されてしまうが、「編集させたくないページ」を

MODX管理画面でフォルダ(コンテナ)内だけを編集可能にする。

上記の方法で回避する事を試してみます。

しかし、この記事はあくまで
ManagerManager
をある程度使用した事がある。と言うことが前提で実際の使い方(コードの設置方法等)が今一つ……

なので、このコードの設置のしかたを書いておきます。
(私もあまり使った事が無いので、完全に自己流です)


メインのコードはmm.inc.php

上記のメインになるコードは、

/plugins/managermanager/mm.inc.php

に書き込み。

mm.inc.phpを開き、最終行以下に、下記コードをペースト。

// テンプレートID指定でアクセス不可を設定する関数
if (! function_exists("mm_deny_templates")) {
function mm_deny_templates($role_users, $tpl, $denied_message) {
global $mm_current_page;
$templates = makeArray($tpl);
if (in_array($mm_current_page['template'], $templates)) {
$docid = (int)$_GET[id];
mm_widget_accessdenied($docid, $denied_message, $role_users);
}
}
}


この時に、サイトに書いてある最後の変数に関しては、記述しない事。

//////// この部分は記述しない ///////////////
$role = '!1'; // 管理者(ロールID:1)以外のユーザに対して
$tpl = '1,2'; // テンプレートIDが1,2の場合、ユーザは編集不可にする。
$msg = 'このフォルダ自体は編集できません。子リソースを作成・編集して下さい。';
mm_deny_templates($role, $tpl, $msg);


これを書いてしまうと、ページを表示したときにエラーコードが表示されるので、注意が必要。


後は、実際の命令文を、

エレメント管理>チャンク>mm_rules

に記述する。
記述位置は、3行目以降で、

/* =============

とコメントアウトしている前。

書き込み例

mm_widget_showimagetvs(); // Imageタイプのテンプレート変数の画像をプレビューします
if($modx->config['track_visitors']==='0') mm_hideFields('log');

//// ここから下 /////

mm_deny_templates('3', '4', 'このフォルダ自体は編集できません。子リソースを作成・編集して下さい。');


//// ここより上 /////

/* ==========================================================

と言った感じ。


書き込む書式は、下記のようにすれはOK。

mm_deny_templates('3', '4', 'このフォルダ自体は編集できません。子リソースを作成・編集して下さい。');

解説
上記の書式は、管理者ID3番は、テンプレートID4番の場合、編集出来ないようにする。
編集出来ない画面には「このフォルダ自体は編集できません。子リソースを作成・編集して下さい。」と表示しなさい。

と言った内容。

少し解りにくいかと思うので、もう少し柔らかく。
要するに、

ID3番のユーザーは、テンプレート4番以外のぺーじは編集できます。

と言う事です。


この方法は、はっきり言って自己流です。

でも、問題無く動いているで、とりあえずOKと言う事で。
もう少しスマートな方法があれば、コメントをください。



※1
必ずしも【グループ制限なし(Public)】である必要はありません。
この階層以下を編集するユーザーが関連した、他の管理ロールでも問題ありません。





2012年9月19日水曜日

Concrete5のベースURLについて。




先日、久しぶりにConcrete5での仕事を頂きました。
ただし、少々特殊な作業内容だったので、覚書として記憶の片隅&Concrete5ユーザーの助けになればと思います。


Concrete5のベースURLは、日本サイトでは具体的な使い方は、phpを使った方法しか書いていません。



phpでの記述方法

<?php echo BASE_URL . DIR_REL ?>


この記述方法では、実際のサイト内での使用はほぼ出来ません。
しかし、海外では下記のコマンドが一般的に使われています。

{CCM:BASE_URL}


これを、サイト制作の際にHOMEボタン等のリンクURL等に使うと、便利なので覚えておいて損はありません。
ただし使い方が限定されるので、注意が必要です。

使い方としては、

<a href="{CCM:BASE_URL}">HOME</a>


とすれば、自動的にHOMEへのリンクになります。
httpから始まるドメインを記述しなくて済むだけではなく、ドメイン変更やサーバー移管等の事態が起きても、ソースコードの修正が必要無いので、非常に便利です。

しかし、使い方にコツ?があります。
通常であれば、HTMLブロックを選択して、記述したいところですが、HTMLブロックで記述すると、リンク表示がおかしくなります。

どうやら、これはバグ?なのでしょうか。
HTMLブロックで上記のタグを記述すると、ベースURLを認識しません。
(詳しくは説明しませんが、とにかくHTMLブロックでは上手く表示しません)
※2012/9/20修正。
HTMLブロックでのバグでは無く、HTMLブロックには、純粋にHTMLしか表示されないようです。



ではどうするか?

記事ブロックで追加してください。記事ブロックでのHTML表示にて、ソースコードを入力すれば、問題無く表示されます。
ベースURLの考え方はCMSを使う上で非常に重要になるので、他のCMSでも可能な限り使う事をおすすめします。
まぁ、サーバー移転はよくある事ですが、ドメイン変更はあまり無い?かもしれません。
しかし、もしもの時に備える事も、web屋の腕の見せ所です。

こういった見えないところで、ちょっとした気遣いを忍ばせておく事が出来るのが、プロだと思いますよ。




2012年8月7日火曜日

Modx Dittoのfilterで50音別にリスト分け【表示スニペット】

Modx Dittoのfilterで50音別にリスト分け

店舗名称や商品名称など、意外と50音順に並べ替えてみたい事が、時々あります。

今回は、Dittoのfilter機能を使って、50音順にリスト化するスニペットを作ります。

基本スニペット

[!Ditto? &parents=`指定id` &tpl=`指定テンプレート` &showInMenuOnly=`1`  &filter=`ふりがな,あ,6|ふりがな,か,5` &orderBy=`ふりがな ASC`!]

解説
parents
親ドキュメントの指定

tpl
表示テンプレートの指定

showInMenuOnly
メニュー表示がされているモノのみ選択。

filter
テンプレート変数:ふりがなの、【あ】という言葉以上を選び、or ふりがなの【か】までを取得しなさい。

orderBy
取得たデータのテンプレート変数:ふりがなを、【あ】から順番に表示しなさい。

filterパラメーターの書き方の詳細は、下記参照でお願いします。
http://www.modx.liolion.net/resource/ditto2.html

説明
指定した親ID以下のリソースページの【ふりがな】というテンプレート変数に入力された、テキストを抜き出し、そのテキストを、あ~おの順番に並べ変えて、表示しなさい。
と言った内容です。

このスニペットのキモは、やはりfilterパラメーターの扱いです。

今回の設定で言えば、【あ】よりも大きい。つまり50音で言う【あ】以降の文字全てを選びなさい。という条件付けがされています。しかし、このままでは50音全ての文字が取得されてしまうので、どこかで取得を止めなければなりません。そこでもう一つのパラメーターを設定します。

filterパラメーターは、複数条件の指定が出来ます。各条件の関連はORです。
通常で考えれば「AまたはB」という考え方になりますが、入力設定のmodeで抽出条件の設定を変えることで、取得を止めます。

今回は、【あ行】の取得が目的ですので、【お】までの文字列を取得できれば良いですから、下記のようなパラメーターを設定します。

【ふりがな,か,5】

これは、【ふりがな】から【か】以下※の文字を取得しなさい。となります。

つまり、「あ~お」までの値を抜き出した事になります。

これで、あ行の取得設定が出来たことになります。
同様のやり方で、か行以降のスニペットを作れば、50音全ての取得設定が可能です。

さて、カンの良い人はお気づきかと思いますが、この条件だと50音にしか対応していません。つまりアルファベットや数字には対応していない状態です。

アルファベットや数字の場合も同様のスニペット設定で取得が可能ですので、アルファベット用や数字用といったスニペットを用意すれば、それぞれのリスト制作が可能です。

今回あらためて、Dittoの強力なデータ抽出を実感しましたが、奥が深いというよりも、色々と実験してみて、初めて判ることがまだまだあるなぁと感心しました。と同時に、MODxは本当に「決まった型のない、カスタマイズ思考の強いCMS」だとあらためて思いました。



本来はあ行であれば、あ~おなので、取得終了は【お】で良いのでは?と思われがちですが、
【お】で終了設定をすると、【お】が含まれない状態になるので、一つ先の【か】までを取得条件としています。





2012年7月18日水曜日

WEBで使用する画像の種類 今さら……第38回

今さら聞けないネットのあれこれ。
今回は
「サイトで使用する画像の種類」
についてお話します。


重要度:★★★
難易度:★★★



サイト制作で使用する画像は大きく別けて、GIF・JPG・PNGの3種類があります。

当然3種類とも特徴があり、それぞれに適した使用目的があります。

詳しく話せば、小一時間は話が出来るほど、実は奥が深い話ですが面倒なので、ざっくり判りやすくお話します。

後ほどサンプル画像をよく見ていただければ、判ると思いますので、簡単に説明します。

GIF画像
主に画像変化の少ないイラストなどに用いる。(グラデーションが多用されていると、問題あり)

短所
表示色数が最高で256色しかないために、写真などの保存にはあまり向かない。
またデータ保存の方法により、グラデーションの表現が弱く、綺麗に表示できない。


JPG画像
主に写真などの色数の多いものや、グラデーションが多用された画像に用いる。

短所
JPGは保存を繰り返すと、データの劣化が進み画像が荒れる特性を持つので、可能な限り保存を繰り返さないようにする。また、広い面に単一色(バックグラウンド等)が適用された画像などでは、極所的に画像の荒れが起きてしまうので、注意が必要。


PNG画像
イラスト・写真など特にデザインを選ばない。また画像の透過※1も出来るので、WEBには非常に向いている形式。

短所
JPG のように画像劣化が起きない分、綺麗な画像を制作できるが、その反面ファイルサイズが肥大化してしまうので、使用する場合は注意が必要。


ざっくり説明すると以上のようになります。

実際、私の場合は複数の保存データを作って、どれが最適か?という作業をします。
まずは、画像の劣化を確認して、その上でファイル容量の軽い(少ない)画像を選びます。

1.複数のフォーマットを見比べて、劣化の少ない画像を選ぶ。
2.選んだ画像のファイル容量の少ない画像を選ぶ。

特殊な使用目的、またはどうしてもその画像フォーマットでなければならない場合以外は、上記の方法で、画像を選定しています。

まぁ、基本的に綺麗であれば、良いとは思いますが、あまり画像容量の多き画像は、表示に時間がかかったりするので、気を付けてください。


サンプル画像 どの画像も 画像サイズ 横400 縦300px で制作してあります。

写真をベースとした各種フォーマット画像
GIF 128色
容量:38.2 KB

解りにくいかもしれませんが、おでこ付近の色がグラデーションでは無く、段階的にトーンを配置している様になっています。
 JPG 60%圧縮
容量:9.15 KB

WEBで使用する一般的な圧縮率60%の画像。
全体的にシャープ感に欠けるぼやけた感じ。
しかし、画像容量としては非常に軽くなっている。
PNG-24

容量:163 KB

JPGに比べて約16倍という非常に容量のあるデータ。
しかし、画像の劣化は少なく非常に綺麗な仕上がり。















イラストをベースとした、各種フォーマット画像


GIF 128色
容量:45.6 KB

赤のグラデーション部分が段階的なトーンに変更されている。
また画像容量も、肥大化している。










JPG 60%圧縮
容量:28.1 KB

写真同様、全体にぼやけた感じでの仕上がり、また【JPG】と書かれた文字の脇付近で画像の劣化によるバターンが確認できる。











PNG-24
容量:163 KB

写真の時と同様、綺麗な画像だがやはり容量はかなり大きい。














それぞれの、画像の中から、使用する画像を選ぶとすれば、ここはやはりJPGの圧縮率を上げた画像(80%圧縮)程度を使用する事がベターだと思う。

もちろん、画像の綺麗さを強調する必要なサイトであれば、やはりPNGを選択するだろう。
また、今回のサンプルはグラデーションのキツイモノを選んだので、GIFの出番はありませんでしたが、シンプルなイラストの場合は、やはりGIFが一番良いです。

このように、使用する画像の構成によって、フォーマットを変える事で、より快適で綺麗なサイト制作が出来ます。


透過※1
PNGは、画像そのものを透過させる事が可能な形式で、特殊な効果を使いたい時に、重宝する形式です。ただし。透過PNGはファイル容量も大きくなるので、扱いは十分に検討してかが良いでしょう。



2012年7月9日月曜日

Facebookアプリページのスクロールバー


フェイスブックはすぐに仕様を変更するから……

先日、アプリページのスクロールバーを消せない……
と記事を書きましたが、どうやら消す事が出来ました。






下記のコードを</body>の直前に書きます。


<div id="fb-root"></div>
<script>
(function() {
    var e = document.createElement('script'); e.async = true;
    e.src = document.location.protocol + '//connect.facebook.net/ja_JP/all.js';
    document.getElementById('fb-root').appendChild(e);
}());
window.fbAsyncInit = function() {
    FB.init({
        appId: 'アプリID',
        status: true,
        cookie: true
    });
    FB.Canvas.setAutoGrow();
};
</script>



これで、先日まで苦労?していたスクロールバーともオサラバ出来ました。

普通に制作すれば……

実は、アプリページ内にシェアボタンを設置すると、スクロールバーが表示されます。
どうも、シェアボタンで使用している、FB.Shareのjavascriptが絡んでいるようで、今回もお手上げ……

しかし「いいねボタン」であれば、スクロールバーは表示されないので、いいねボタンを使えば、問題ありません。

現在フェイスブックとしては、シェアボタンは正式に対応していないボタンなので、いいねボタンに対応させる為の嫌がらせ?のように見えてしまうのは、私だけ?

まぁ、そんな事を言っても、この方法もいつ使えなくなるかわからない。
そう、facebookは簡単に仕様変更を行って、「変えたから、宜しくね!」と言って終わらせるからなぁ。

しかも技術関連のレポートは翻訳しないし……
仕様の変更はかまわないけど、もう少し情報をわかりやすくアナウンスしてほしいもんです。




2012年7月5日木曜日

facebookページのスクロールバーを消す。


いまさらの情報で申し訳ないのですが……
どうも、スクロールバーを消すと不具合が、と言うかですね。どうも

FB.Canvas.setAutoGrow();

の仕様が変った?感じですね。
急遽色々と検証した結果、結論は。


スクロールバーを表示させたくないのであれば、iframe内の表示を
横810px 縦1280px以内の収めるしか方法が無いようです。

どうも今回の変更だと、基本画面サイズを超えた場合に、縦のスクロールバーに関しては表示の回避が出来ないようになってしまったようです。

つまり、基本画面サイズ横810px 縦1280pxまでの大きさならば、スクロールバーの非表示が可能ですが、それを越えた場合、必ずスクロールバーが表示されます。

以前であれば、基本サイズを超えた大きさ(殆どの場合、縦方向)はそのままブラウザーのスクロールバーで下にスクロール出来たのですが、現在の仕様では、あくまでiframe内で処理をするようになっている様です。

つまり、iframeの基本画面サイズである横810px・縦1280pxを越えた場合、iframe内部にスクロールバーが表示されるようになってしまうようです。そう、横810px・縦1280pxの内部にスクロールバーが表示されるので、実際の画面は横810pxで制作すると、右側がスクロールバーで隠れてしまいます。

また、CSSを使って強制的にスクロールバーを非表示にすることも可能ですが、それをやると画面が固定されてしまい、結局基本サイズ以上の表示は出来ないようです。(スクロールバーが表示されず、画面サイズは横810px・縦1280pxのままです)
※CSSでの強制非表示は、bodyタグに対して、縦方向のオーバーフローを非表示にする設定。
body{overflow-y: hidden;}

また、</body>の直前に入れる下記のスクリプトで、高さを指定してみましたが……

<div id="fb-root"></div>
<script>
 FB.Canvas.setAutoGrow({ width: 810, height: 1280 });
</script>

1280px以上の大きさにはならない事がわかりました。
つまり基本画面サイズの横810px・縦1280pxは何をどうやっても変更出来なくなっています。

他にも色々とやってみましたが、結論は……
完全にスクロールバーを消したいのであれば、コンテンツを基本サイズ内に収める事。
しか手立てが無いようです。

もし、コンテンツが基本サイズより、大きくなる様ならば、横幅を790pxで制作する事をお勧めします。
このサイズで制作すれば、縦が1280pxを越えてスクロールバーが表示されても画面右側に余裕があるので、デザイン的に崩れる事はないと思います。
(横790pxだと、横のスクロールバーも表示されません)

これに関して、もしかすると、アプリ系の何か?を変更すれば、表示が出来る??
なんて事は無いと思いますが、いずれにしてもここまで来ると専門外になってしまうので、私には厳しいですね。

この件に関して詳しい方がいましたら、ご連絡ください。
と言うか、誰かこの辺のネタ、書いておらんですかね??


2012/7/9 追記
どうやら、スクロールバーが表示されてる原因を特定しました。
これで、スクロールバーを消す方法が解りましたので、こちらをご覧ください。
http://hon-web.blogspot.jp/2012/07/facebook_09.html



2012年5月9日水曜日

Facebookファンゲートのエラー表示

ファンゲートを設置したら、エラーが表示されて、しばらく格闘してしまった……
ファンゲートに関するエラー情報が以外と少ない。
というより、エラーは想定していない設定マニュアルもどうなんだろうね……

ところでファンゲートについて簡単にご説明を。

ファンゲートは、フェイスブックアプリの一つで、いいねボタンを押した人と、押さない人で閲覧できるページを変えるという機能を持つモノです。


多分フェイスブックを使っている人は、一度ぐらいは見かけた事があるのではと思います。

例の「いいねボタンを押してね」とか「この先の情報はいいねボタンを押すと閲覧出来ます」というあれです。

興味がある人は「ファンゲート」で検索すると色々と出てくるの探してください。

さて、本題です。
このファンゲートを設置した……わ、いいけど、下記のエラーが表示される状態にハマり、情報を収集。


Fatal error: Call to undefined function json_decode() in


なに?Jsonが無い??そんなはずはないんだが……
と思っていたら、しまった!サーバーの設定か……

使っているwebサーバーの仕様で、ある設定をしないと、php4で稼働するになっている事を、すっかり忘れていました。

json_decodeはphp5から追加されたモノなので、上記のエラーコードが表示されていた様ですね。
幸い、php5に変更するのは簡単でしたので、変更後テストすると。問題無く動く事が確認されました。

ちなみに、使用しいるwebサーバーは、hetemlですが、契約が結構古いので、現状でもphp4とphp5での共存稼働状態です。
最近の契約であれば、自動的にphp5になっているはずですが、ご心配な方はサーバーの仕様を確認してください。

ちなみに、どうしてもphp4で動かしたい場合は、下記のサイトを参考にしてください。


facebookアプリのファンゲート機能をPHP4で実装する


Facebookページ:iframeで「いいね!」を押す前と押した後で表示を変える“ファンゲート”について



2012年2月22日水曜日

Thunderbird 起動直後エラー表示で固まる…… 修復方法


Thunderbird 10.0系あるいは、旧バージョン可能かも?
旧バージョンについては、下記の方法で修復を行った場合の動作保障は致しません。

Thunderbirdに新しいアカウント設定を行ったあとで、下記の様なエラーメッセージが表示された。


まぁ、Thunderbirdは昔から、新規設定直後にこの手のダイアログはよく出るので、別段気にもしなったが…… エラーメッセージ表示後、なんと完全に固まる状態に……

何もクリック出来ない。

これはマズイ!
何しろ完全にソフトが固まっている状態で何もできない。

とりあえず何が悪いのかを確認するために、いくつか起動を試みる。


セーフモードのでの起動
まず、【スタート】【すべてのプログラム】【Thunderbird】で
Shiftボタンを押しながら、Thunderbirdを起動させて、すべてのアドオンを無効化にチェックを入れて、【セーフモードを続ける】をクリック。


その後、Thunderbirdが起動するが……状況は変わらす、同じエラーが表示されて、再びハング……

では、オフラインではどうか?と思ったのですが、これまた問題でオフラインに変更しようとしても、起動直後にエラーアラートが表示されてしまい、メニューバーをクリックするような時間を与えてくれません。

つまり、起動後即ハングの状態。

エラー内容から、先ほど設定したアカウントに何らかの問題があって、固まっていているような雰囲気なので、そのアカウントを削除すれば、上手く起動しそうな感じですが、ソフトが固まっているので、通常の手続きではアカウントの削除は出来そうにありません……

では、どうするか……

Thunderbirdのサイトではこのような場合は、バックアップを取った上で、新規インストールを薦めていますが、アカント設定そのものが固まる原因の場合、バックアップにも当然問題のアカウントはあるはずですよね。そう考えると、新規インストールについては疑問が残ります。じゃあどうすればいいか……

こうなるともう、プロファイルデータを直接手動で変更するしか、手がないです。

と言う事で、ここから先の作業については、自己責任にてお願いします。
この作業を間違えた場合は最悪ソフトの起動すらできなくなる状態になり可能性もあるので、

あくまで自己責任でお願いします。
上手く動かなくても当方に文句わ言わないように。

では、まず肝心のプロファイルデータですが。場所は下記にあります。

Application Data/Thunderbird/Profiles/*****.default/

内にある、prefs.js です。

まずこのファイルのコピーをとっておきます。
これは今後の作業でファイルが壊れた場合のバックアップです。
(上手く修正出来れば、最終的に削除してください)

コピー後このファイルをエディター等で開いてください。
そうすると、下記の様な表記がズラズラとでてきます。
で、削除したいアドレスを検索して関連する箇所を削除すれば、OKなのですが、どこを消せばいいか?

と言う事で、サンプルです。
削除したいアカウント【info001@ab012.com】
これを検索すると、赤文字の部分が出てきます。
実際には、もう2・3箇所検索ででるのですが、それはフォルダー関連ですので、今回は*****とさせていただきました。

さて、では削除しましょうか……?
何処から、どこまでを消せばいいの?
JavaScriptoが理解できる人はいいですが、そうでない人には、どこを削除すればいいのか、さっぱりですよね。(私もJavaScriptoは断片的しか理解できていないので……)

アドレスが表記してある行を消せばいいの?それともアドレスだけを消せばいいの??

と言う事で、削除範囲は、黄色になっている範囲全部です。
結構ごっそりです。

わかりやすい判断基準はそれぞれの、アドレスが入っている行の青文字の箇所を確認してください。
良く見ると選択範囲は全て同じ条件ですよね、つまり、その箇所が同じと言う事は、データ的には何らかの関連があると考える事が自然なので、同じ変数のエリアを削除します。

//////////////////////////////////////////////////////////////////////////

user_pref("mail.identity.id11.stationery_folder", "mailbox://*****");
user_pref("mail.identity.id11.tmpl_folder_picker_mode", "0");
user_pref("mail.identity.id11.useremail", "*****@ab012.com");
user_pref("mail.identity.id11.valid", true);
user_pref("mail.identity.id2.archive_folder", "mailbox://*****"); ここからid2
user_pref("mail.identity.id2.doBcc", false);
user_pref("mail.identity.id2.doBccList", "");
user_pref("mail.identity.id2.draft_folder", "mailbox://*****");
user_pref("mail.identity.id2.drafts_folder_picker_mode", "0");
user_pref("mail.identity.id2.escapedVCard", "");
user_pref("mail.identity.id2.fcc_folder", "mailbox://*****");
user_pref("mail.identity.id2.fcc_folder_picker_mode", "0");
user_pref("mail.identity.id2.fullName", "abcd0012");
user_pref("mail.identity.id2.organization", "");
user_pref("mail.identity.id2.reply_to", "");
user_pref("mail.identity.id2.smtpServer", "smtp3");
user_pref("mail.identity.id2.stationery_folder", "mailbox://*****");
user_pref("mail.identity.id2.tmpl_folder_picker_mode", "0");
user_pref("mail.identity.id2.useremail", "info001@ab012.com");
user_pref("mail.identity.id2.valid", true); ここでid2が終了

user_pref("mail.identity.id3.archive_folder", "mailbox://*****");
user_pref("mail.identity.id3.attach_signature", true);
user_pref("mail.identity.id3.doBcc", false);
user_pref("mail.identity.id3.draft_folder", "mailbox://*****");
user_pref("mail.identity.id3.drafts_folder_picker_mode", "0");

//////////////////////////////////////////////////////////////////////////

user_pref("mail.server.server2.login_at_startup", true);
user_pref("mail.server.server2.name", "オーダー");
user_pref("mail.server.server2.realuserName", "******@ab012.com");
user_pref("mail.server.server2.spamActionTargetAccount", "mailbox://*****");
user_pref("mail.server.server2.type", "pop3");
user_pref("mail.server.server2.userName", "0123");
user_pref("mail.server.server3.ageLimit", 30);  ここからserver3 
user_pref("mail.server.server3.applyToFlaggedMessages", false);
user_pref("mail.server.server3.check_new_mail", true);
user_pref("mail.server.server3.cleanupBodies", false);
user_pref("mail.server.server3.daysToKeepBodies", 30);
user_pref("mail.server.server3.daysToKeepHdrs", 30);
user_pref("mail.server.server3.defer_get_new_mail", true);
user_pref("mail.server.server3.deferred_to_account", "account1");
user_pref("mail.server.server3.delete_by_age_from_server", true);
user_pref("mail.server.server3.delete_mail_left_on_server", true);
user_pref("mail.server.server3.directory", "C:\\*****");
user_pref("mail.server.server3.directory-rel", "[ProfD]Mail/*****");
user_pref("mail.server.server3.downloadByDate", false);
user_pref("mail.server.server3.downloadUnreadOnly", false);
user_pref("mail.server.server3.download_on_biff", true);
user_pref("mail.server.server3.hostname", "mail.mail.jp");
user_pref("mail.server.server3.keepUnreadOnly", false);
user_pref("mail.server.server3.leave_on_server", true);
user_pref("mail.server.server3.login_at_startup", true);
user_pref("mail.server.server3.name", "info001@ab012.com");
user_pref("mail.server.server3.numHdrsToKeep", 2000);
user_pref("mail.server.server3.num_days_to_leave_on_server", 14);
user_pref("mail.server.server3.port", 995);
user_pref("mail.server.server3.socketType", 3);
user_pref("mail.server.server3.spamActionTargetAccount", "mailbox://*****");
user_pref("mail.server.server3.spamActionTargetFolder", "mailbox://*****");
user_pref("mail.server.server3.type", "pop3");
user_pref("mail.server.server3.userName", "info001@ab012.com"); ここまで

user_pref("mail.server.server4.defer_get_new_mail", true);
user_pref("mail.server.server4.deferred_to_account", "account1");
user_pref("mail.server.server4.directory", "C:\\*****");

//////////////////////////////////////////////////////////////////////////

削除が終わったら、ファイルをセーブして、上手く行きますようにとお祈りしながらThunderbirdを起動します……

結果は…… バッチリです。

通常起動に成功。元の状態に戻りました。
今まで受信したメールも無事です。

とりあえず一安心です。
一時は、再インストール?などと怖い考えも有りましたが、なんとか元に戻りました。

ただし、あくまでこの作業は緊急時に行なう手動でのアカウント削除作業です。
通常は、ソフトから正規の手順で削除してください
また単に偶然?上手くいった可能性も否定できませんので、作業はあくまで

自己責任でお願いします。

また、今回はアカウント関連でのエラーだったので、上記のような方法を取りましたが、違うエラーの場合は、今回の作業で必ずしもうまく行くとは限りませんので、ご注意ください。

要するにイヂルなら、自己責任でお願いします。

と言う事です。(笑





2012年2月15日水曜日

EC-CUBE2.11.X テンプレートカスタマイズ HTML5化?の覚書


EC-CUBEのテンプレートは基本的にHTML4で書かれています。スマートフォン用のテンプレートはHTML5ですが…… まぁ、ブラウザーもまだIE6あたりも使っている人もいますし、WindwsXPユーザーだと、IEを使っているかぎり、HTML5の恩恵は受けられないですしね。

しかし、制作者サイドとしては既に多くのサイトをHTML5で構築していると、

もうHTML4には戻れない!

というのが正直な感想では?と思うのですが……

ま。HTML5と言うより、CSS3の機能が使いたいだけ、なんですけどね。
CSS3の強力なグラフィカル表現だと、装飾画像の類がかなり省けるので、ブラウザーに優しく、表示も早い?です。

さて、前置きはこのくらいで。

では、HTML5とCSS3を実装するにはどうしたらいいのか。

単純で至極簡単です、ヘッダーのドキュメント宣言を変更すれば、完了です。

EC-CUBEのヘッダー情報はどこのファイルかといいまと、

/data/Smarty/templates/default
内の

site_frame.tpl

になります。


///////////////////////////////////////////////////////////

<!--{printXMLDeclaration}-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--{*
この下はコピーライト関連

 *}-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=<!--{$smarty.const.CHAR_CODE}-->" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="Content-Style-Type" content="text/css" />





///////////////////////////////////////////////////////////

と、こんな感じです。

で、肝心のドキュメント宣言はどこでされているかと言うと、冒頭の2行目ですね

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

これを、

<!DOCTYPE html>

と変更すれば、HTML5の出来上がり……ですが、実は、1行目にXML宣言がされています。
ブラウザーからソース確認して頂くとわかりますが、1行目の

<!--{printXMLDeclaration}-->

によって、XML宣言がされています。これって大丈夫なのかな?
殆どのサイトでは、HTML5は

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Example document</title>

の様な書き方で書かれています。
つまりXML宣言が無いモノが殆ど。

では、HTML5ではXML宣言は不要なのかな?と思いきや。
どうやら、別段XML宣言がされていても問題は無いようです。
ただし、XML宣言をした場合は下記のように記述する必要があります。

W3C原文 ///////////////////////////////////////

The other syntax that can be used for HTML5 is XML. This syntax is compatible with XHTML1 documents and implementations. Documents using this syntax need to be served with an XML media type and elements need to be put in the http://www.w3.org/1999/xhtml namespace following the rules set forth by the XML specifications. [XML]

Below is an example document that conforms to the XML syntax of HTML5. Note that XML documents must be served with an XML media type such as application/xhtml+xml or application/xml.



<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Example document</title>
  </head>
  <body>
    <p>Example paragraph</p>
  </body>
</html>


////////////////////////////////////////////////////

つまり、XML宣言されたHTML5ファイルの場合は、application/xhtml+xmlまたはapplication/xmlメディアタイプでないとダメですよ。
と言っています。

では、どうするか?

方法は2つ。

1.上記のようにXML宣言タイプに変更する。
2.XML宣言を消して(テンプレートから、変数を削除)ドキュメント宣言文に変更する。

この2種類になります。
どちらのファイルタイプを製作しても、問題無くブラウザーので動作はするので、使用するテンプレートによって使い分けていいかと思います。

上記の変更で、基本的にHTML5に対応したhtmlファイルになります。

後は通常と同じ作業で製作すれば、OKです。
装飾系にCSSを限定して、HTML構文に変化(HTML5専用タグ)を使用しなければ、HTML5未対応のブラウザーでの表示でも崩れる事は無いかと思います。

このあたり、はクロスブラウザーチェックで回避するしか手段がありませんが、まぁこの程度の変更で、MTML5&CSS3が使えるのであれば、良いのではないかと。

参考サイト
HTML5 differences from HTML4
http://www.w3.org/TR/html5-diff/

2012年1月31日火曜日

【覚書】Googleマップのふきだしを消す。

さて、サイトでGoogleマップの地図を表示したい場合、表示したい住所で検索をした後、そのページのソースを貼りつければ、基本的には完了ですが。

この貼りつけたソースのままだと、検索住所の吹き出しが表示されていまいます。
まぁ、地図の大きさがそれなりの場合は、マップ登録して、店舗名称等の情報を表示すれば、それなりに見栄えのいい?ページに出来そうですが、表示さいずが小さい場合、この吹き出しが表示エリアから見切れてしまうので、なんともカッコ悪くみえます。



大きな地図で見る


300px×300pxのサイズで表示。
デフォルトの状態だと、吹き出しが見切れる…

これではあまりにも酷いので、なんとかこの吹き出しを消す方法はないのか?
と探したら、やはり有りましたね。
しかもお手軽です。


先ほどのソースコード
<iframe width="300" height="300" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="http://maps.google.co.jp/maps?f=q&amp;source=s_q&amp;hl=ja&amp;geocode=&amp;q=%E6%A8%AA%E6%B5%9C&amp;aq=&amp;sll=35.485834,139.66095&amp;sspn=0.428276,0.617294&amp;brcurrent=3,0x60185d2db5c8ae09:0xc208776b5141af0a,0&amp;ie=UTF8&amp;hq=&amp;hnear=%E7%A5%9E%E5%A5%88%E5%B7%9D%E7%9C%8C%E6%A8%AA%E6%B5%9C%E5%B8%82&amp;t=m&amp;ll=35.44368,139.638033&amp;spn=0.020978,0.025749&amp;z=14&amp;iwloc=A&amp;output=embed"></iframe><br /><small><a href="http://maps.google.co.jp/maps?f=q&amp;source=embed&amp;hl=ja&amp;geocode=&amp;q=%E6%A8%AA%E6%B5%9C&amp;aq=&amp;sll=35.485834,139.66095&amp;sspn=0.428276,0.617294&amp;brcurrent=3,0x60185d2db5c8ae09:0xc208776b5141af0a,0&amp;ie=UTF8&amp;hq=&amp;hnear=%E7%A5%9E%E5%A5%88%E5%B7%9D%E7%9C%8C%E6%A8%AA%E6%B5%9C%E5%B8%82&amp;t=m&amp;ll=35.44368,139.638033&amp;spn=0.020978,0.025749&amp;z=14&amp;iwloc=A" style="color:#0000FF;text-align:left">大きな地図で見る</a></small>

これに、</iframe>タグの直前に &amp;iwloc=B を追加します。

<iframe width="300" height="300" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="http://maps.google.co.jp/maps?f=q&amp;source=s_q&amp;hl=ja&amp;geocode=&amp;q=%E6%A8%AA%E6%B5%9C&amp;aq=&amp;sll=35.485834,139.66095&amp;sspn=0.428276,0.617294&amp;brcurrent=3,0x60185d2db5c8ae09:0xc208776b5141af0a,0&amp;ie=UTF8&amp;hq=&amp;hnear=%E7%A5%9E%E5%A5%88%E5%B7%9D%E7%9C%8C%E6%A8%AA%E6%B5%9C%E5%B8%82&amp;t=m&amp;ll=35.44368,139.638033&amp;spn=0.020978,0.025749&amp;z=14&amp;iwloc=A&amp;output=embed&amp;iwloc=B"></iframe><br /><small><a href="http://maps.google.co.jp/maps?f=q&amp;source=embed&amp;hl=ja&amp;geocode=&amp;q=%E6%A8%AA%E6%B5%9C&amp;aq=&amp;sll=35.485834,139.66095&amp;sspn=0.428276,0.617294&amp;brcurrent=3,0x60185d2db5c8ae09:0xc208776b5141af0a,0&amp;ie=UTF8&amp;hq=&amp;hnear=%E7%A5%9E%E5%A5%88%E5%B7%9D%E7%9C%8C%E6%A8%AA%E6%B5%9C%E5%B8%82&amp;t=m&amp;ll=35.44368,139.638033&amp;spn=0.020978,0.025749&amp;z=14&amp;iwloc=A" style="color:#0000FF;text-align:left">大きな地図で見る</a></small>



大きな地図で見る

と、こうなります。
吹き出しは消えましたね。

意外と使用頻度は高いネタですが、忘れない為の覚書です。