[jQuery]$(document).readyと$(window).loadの違い[自分メモ]

今までずっとjqueryの実行タイミングをデフォで$(document).readyで書いてました。
今更こんな事書いたら、いろんなお客さんから怒られそうですが、今まで作ってきたjsアニメーションの実行のタイミングは何かをクリックしたら動かすといったような、必ずトリガーが何かしらあるものでした。

で、ちょうど今ページ読み込みと同時に動くアニメーション作っているのですが、PC環境だと問題なくてもスマホで問題があるんすよ。
wifiならまだしも、3G環境でただでさえ読み込みに時間がかかる状態で実行のタイミングが$(document).readyだと、スマホでデータの読み込みが終わった時点でアニメーションが終了しているという本末転倒な事態になる事が判明。

$(document).readyってなんぞ

DOMが読み込まれた時点で実行します。
htmlの構造が読まれた時って事だもんで、画像ファイルの読み込みを待たずにスクリプトの処理を開始します。

じゃあ$(window).loadってなにさ

DOM内に含まれる全ての要素の読み込みが完了した時点で実行します。
なので、今回の懸念である「3G回線」で画像の読み込み待ってる間にアニメーション終わっとるがな、という事態を解消するにはうってつけだったわけで。

ただ、調べている間に見つけたサイトには$(document).readyの方が良い的な事書いてあったので、$(window).loadはあまり推奨はされていないみたいですね。
うーん、もうちょっと勉強が必要だなぁ。

今気づいたけどもう2ヶ月もconcrete5に関する記事書いてないや…。

次世代インターフェース LEAP MOTIONが届いたよ!そして使ってみた


1年と2ヶ月前から待ちました。
もう、今年に入ってからは存在自体忘れていま…いえ、そんなことないです。
ずっと待ってたんです。

えぇと、お値段は…いくらだっけな…。
確か80ドルくらいでした。
[追記]
ごめんなさい、今調べたら日本円で8200円+配送料1800円+消費税で10500円でした。

で、発送元は花のサンフランシスコ…じゃなくてシンガポールでした。生産がシンガポールなのかな。
「発送したでー」メールが届いてから、わずか8時間でヤマトのにーちゃんが持ってきました。
Fedexのトラッキングしたら、3日前くらいに発送してたので、単にメール来るのが遅れただけっぽいですね。

そしてついに、LEAP MOTIONが私の手元に!!イヤッホーーーゥ!!

はい箱ドーン

箱の質感がなんか安っぽいと感じるのは、普段アップル製品ばっかり買ってアノ箱に慣れてしまったからだと思いたい。

そもそもLEAP MOTIONってなによ?

という方は、まず下記の動画をご覧ください。

手をかざして、PCを操作するインターフェース

今までのPCのインターフェースって、マウスだったりキーボードだったりして物理的なものを押すなり動かすなりして、PCの操作を行ってきましたが、LEAP MOTIONはモーションセンサーで手の動きを読み取り、それをPCに反映します。
僕は良く知らないけど、似たようなインターフェースはマイクロソフトのキネクトとかがそうらしいですよ。

Welcome to a whole new world.

大きさは100円ライターを2つ重ねたくらいの厚みで、デザインはアルミと黒の組み合わせなので、非常にMacに合いますね!

さっそくつなげてみよう!

USBでつなぐだけ!早い!簡単!!
ってわけにもいかず、前項の写真に記載されているように、https://leapmotion.com/setupへアクセスして、専用のソフトのダウンロード・インストールが必要です。

Airspace


Airspaceアプリ画面

LEAP MOTION専用のアプリケーションを提供するプラットフォーム「Airspace store」が2013/07/23にオープンしました。
現状アプリのAirspaceをクリックするとブラウザ開いて普通のウェブサイトが表示されるんだけど、これそのうちAirspaceに統合されるのかな。iTunes storeみたいに。

Airspace storeでは、やっぱりiTunes storeみたいに、LEAP MOTION専用のアプリを購入する事ができます。
ただ、iTunes storeと違って、まだ始まったばかりのサービスなので、アプリの数は非常に少ないです。まだ100個くらいしかありません。

とりあえず動かしてみた

デフォルトで「Visualizer」という機能が付いているので、それを動かしてみました。

こんな感じで、手の動きをキャプチャして画面の操作に反映します。
例えば、「Touchless」というアプリを使用して、従来であれば、マウスで行っているカーソルの動きを、LEAP MOTIONの操作で行う事も可能になります。
ただ、奥行きや高さの情報も含まれる為、カーソル操作をLEAPで置き換えて使用するのは、今まで平面の画面に対してマウスを使用して平面の操作を行っていたものを、3次元的に操作する必要性は全く感じません()
例えば、カーソルを画面右上に持って行きたいときに、腕を右上に持ち上げないとカーソルは右上に行かず、また、クリック操作は指を前に出す操作になるので、前に出した瞬間に上下左右の位置がずれてしまう。

ごめんね。絵が描ければ図解できるんだけど…。

結論

つまり、どういう事が言いたいんだってばよってところで、個人的には、LEAP MOTIONを最大限に活用するには今までにない新しいOSが必要なんじゃないかなーって思います。
PC用のOSでも、タッチデバイスOSでもない、3Dを基本概念として設計された全く別のOS。
LEAP MOTIONがあれば、掴む動作や、はじく動作、あおぐ動作なんかも実装できるわけです。
テレビなんかもね、あんなたくさんのボタンをつけたリモコンを作るんじゃなくて、こういうインターフェースで手を叩いたら電源つけるとか、右に手を振ったらチャンネル切替とか、いろいろできるんじゃないかなって思って、夢がどんどん広がっていくわけですよ。

Android用アプリアイコンテンプレート[PSDファイルもあるよ!]

Androidアプリのアイコン制作の依頼があったのですが、各サイズを毎回リサイズするのはめんどくさ…、いや大変なので、もうpsdでテンプレ作ってしまいました。
というかこのテンプレでweb用書き出しすれば5種類のサイズにスライスしてあるので、そのまま使えます。

使い方

スマートオブジェクトになっている「edit this」を編集します。

編集が終わったら「web用に保存」

以上!

ね、簡単でしょう?
スマートオブジェクト内のレイヤーグループに角丸マスクも入れてあるので、必要であればそれもご利用ください。

psdファイルをダウンロード

[Concrete5]オートナビにページの説明文を表示[メモ]

Concrete5、すごく便利です。
ただ一点、日本語のドキュメントというか、まだユーザが少ないのでwordpressみたいにググればすぐにヒットするような状況ではなくて、一つ一つ手探りでやるんですが、それでもダメでいつもSさんに頼っている次第でございます。

ページリストでやれば説明文は簡単に出せる、でも。

ページリストブロック

Concrete5のページリストブロックには、デフォルトで個別のページの説明文を表示する記述がされているので、ブロック設置時点で表示非表示はワンクリックで出来てしまいます。すげー。

そう、ページリストを使えば全く問題なくページのリンクリストと説明文を表示出来てしまうのですが、ページリストはデフォルトでは階層構造が出せないんです。

↓こんなマークアップがしたいのに。

<ul>
  <li><a href="oya">親ページ</a>
    <ul>
      <li><a href="ko">子ページ</a>
      <ul>
        <li><a href="mago">孫ページ</a>
      </ul></li>
    </ul></li>
</ul>

ページリストだと「親ページ > 子ページ > 孫ページ」と言った階層順に上記のようにマークアップしつつ一覧にする事ができない。
実際に出てくるマークアップは、↓のようになってしまいます。
<ul>
<li><a href="oya">親ページ</a></li>
<li><a href="ko">子ページ</a></li>
<li><a href="mago">孫ページ</a></li>
</ul>

全部並列になってしまう。
ページリストで階層を出したい場合は、カスタムテンプレートをいじる必要があります。

じゃあ、オートナビを使いましょう

オートナビ

階層構造をマークアップしたいのであれば、ページリストのカスタマイズをするより、オートナビを使用すれば何も考えなくても勝手に階層順にしてくれます。

うほっ!超らくちん!

と最初わたしは思いましたが、今回の案件で、お客さんの要望としては、「最下層にあるページの説明をリストに追加したい。」ということですので、上記のマークアップの例で言うと、下記の3点が大きな要件でした。

  1. 孫ページに説明文を表示
  2. 孫ページに説明文が入力されていない場合は非表示
  3. 親と子ページには説明文を表示しない

オートナビに説明文を表示する機能はデフォルトでついていないので、どうにかしてデータを引っ張ってこないといけないのです。

さて、どうしたもんか。

やっぱりカスタムテンプレートは使わないといけないのであった。

オートナビのデフォルトテンプレートは以下のような記述になっています。

echo '<ul class="nav">'; //opens the top-level menu
foreach ($navItems as $ni) {
	echo '<li class="' . $ni->classes . '">'; //opens a nav item
	echo '<a href="' . $ni->url . '" target="' . $ni->target . '" class="' . $ni->classes . '">' . $ni->name . '</a>';
	if ($ni->hasSubmenu) {
		echo '<ul>'; //opens a dropdown sub-menu
	} else {
		echo '</li>'; //closes a nav item
		echo str_repeat('</ul></li>', $ni->subDepth); //closes dropdown sub-menu(s) and their top-level nav item(s)
	}
}
echo '</ul>'; //closes the top-level menu

階層に応じて、ifがあって、表示する階層分だけ繰り返すように書かれています。
concrete5のブロックというか、テンプレのファイルには結構な量のコメントが書かれていて、それを読めばどうやってデータを取得出来るかがわかりやすいです。
コメント内に、下記のようなインフォメーションが記載されているので、それを参照しつつ、テンプレートを書き換えます。

 * Each nav item object contains the following information:
 *	$navItem->url        : URL to the page
 *	$navItem->name       : page title (already escaped for html output)
 *	$navItem->target     : link target (e.g. "_self" or "_blank")
 *	$navItem->level      : number of levels deep the current menu item is from the top (top-level nav items are 1, their sub-items are 2, etc.)
 *	$navItem->subDepth   : number of levels deep the current menu item is *compared to the next item in the list* (useful for determining how many <ul>'s to close in a nested list)
 *	$navItem->hasSubmenu : true/false -- if this item has one or more sub-items (sometimes useful for CSS styling)
 *	$navItem->isFirst    : true/false -- if this is the first nav item *in its level* (for example, the first sub-item of a top-level item is TRUE)
 *	$navItem->isLast     : true/false -- if this is the last nav item *in its level* (for example, the last sub-item of a top-level item is TRUE)
 *	$navItem->isCurrent  : true/false -- if this nav item represents the page currently being viewed
 *	$navItem->inPath     : true/false -- if this nav item represents a parent page of the page currently being viewed (also true for the page currently being viewed)
 *	$navItem->attrClass  : Value of the 'nav_item_class' custom page attribute (if it exists and is set)
 *	$navItem->isHome     : true/false -- if this nav item represents the home page
 *	$navItem->cID        : collection id of the page this nav item represents
 *	$navItem->cObj       : collection object of the page this nav item represents (use this if you need to access page properties and attributes that aren't already available in the $navItem object)

今回使用するのは、最後の行の「$navItem->cObj」で、英語がよくわからないながらも読んでみると、どうやら「
ナビアイテムに該当するページのコレクションオブジェクト(既に用意されている$navItemオブジェクト以外でページプロパティとか属性が必要だったらこれを使え)」って書いてあるっぽいです。なんとなく雰囲気で和訳してるので多少の間違いは勘弁してください。

で、コードを追加しますた↓

echo '<ul class="nav">'; //opens the top-level menu
foreach ($navItems as $ni) {
	echo '<li class="' . $ni->classes . '">'; //opens a nav item
	echo '<a href="' . $ni->url . '" target="' . $ni->target . '" class="' . $ni->classes . '">' . $ni->name . '</a>';
	if ($ni->hasSubmenu) {
		echo '<ul>'; //opens a dropdown sub-menu
	} else {
			$cobj = $ni->cObj; // ← $navItems->cObjを$cobjに入れる
			if($ni->level == 2 && $cobj->getCollectionDescription()) { //後述
			echo '<p>' . $cobj->getCollectionDescription() . '</p>';
		}
		echo '</li>'; //closes a nav item
		echo str_repeat('</ul></li>', $ni->subDepth); //closes dropdown sub-menu(s) and their top-level nav item(s)
	}
}
echo '</ul>'; //closes the top-level menu

順を追って説明すると、該当箇所は「$cobj = $ni->cObj;」から始まる4行です。

「$cobj = $ni->cObj;」で、インフォメーションにあった$navItems->cObjを変数にしました。

さらに、次の行のifの条件ですが、「$ni->level」を使用すると階層の深さが0から順に取得できますので、「$ni->level == 2」とすることで、「孫ページのみ」の条件指定ができます。汎用性持たせるなら、levelの値を数値じゃなくて、「一番大きい値」とか「最後の値」とか変数にしておいた方がいいかもですね。

さらに先ほど変数にした$cobjから「$cobj->getCollectionDescription()」を記述する事で、説明文が存在するかどうかの判別をしています。なので条件が「if($ni->level == 2 && $cobj->getCollectionDescription())」となっています。

で、最後にechoするだけ。なんということでしょう。今になって考えればこんなに簡単な事を、全然わからなくて2日くらいずっとやってました。アホです。

最終的に上記のカスタムテンプレートで、↓のようなマークアップになります。

<ul>
  <li><a href="oya">親ページ</a>
    <ul>
      <li><a href="ko">子ページ</a>
      <ul>
        <li><a href="mago">孫ページ</a>
     <p>説明文テキスト説明文テキスト説明文テキスト説明文テキスト説明文テキスト</p>
      </ul></li>
    </ul></li>
</ul>

以上。

iMac(2007 Mid)のHDDを交換しました。

実家で約3年ほど放置していた2007MidのiMacを久しぶりに起動した所、HDDから異音と共に動作しなくなってしまったので、さらに放置しておりましたが、ドライブやその他のパーツに関しては全く問題が無いので、なんとか復活させようと画策いたしました。

いろいろ調べた結果、手順と必要なものもわかりました。

最低限必要なもの

  • プラスドライバー
  • トルクスドライバー(ヘックスローブ) T-8
  • 大きめの吸盤(2個くらい)

あったら良いなーなもの

  • エアダスター
  • 拭き後が残らない液晶クリーナー
  • 毛布
  • 高さ20センチくらいの台
  • 掃除機
  • エタノール
  • 綿棒

では行った手順をどぞー。

1.メモリスロットパネルを外す

iMacには、画面下にあるリンゴのさらに下の面にメモリ増設用のスロットがありまして、そこを塞いでいるパネルがプラスのネジで留められています。

後の手順で、アルミの被さっている部分をごそっと外すのですが、このメモリスロットのパネルが外れていない状態ですと、下部が曲がったりしてしまうそうです(事前に知っていないとパネル外さないよねこれ)。

外しました。きったねー!!!!

掃除機でホコリを吸い取りました。

2.画面のガラスを外す

iMac2007というか、近年のiMacは大福iMacの後の液晶の大型化に伴い、画面にガラスが貼られています。
まずはガラスを取らないと話が始まらないという事で、吸盤を使って、ガラスをとっぱらいます。実際吸盤は何でも良いと思います。前述で大きめでって書いてるのは、安定感があるから。
iMacのガラスは磁石で張り付いてるので、吸盤をくっつけてちょっと引っ張れば簡単にはずれます。ぐいっとね。
吸盤を貼付けて持ち上げると、ガラスが外れます。

ガラスはどこかに置いておきましょう。

3.周りのアルミパネルを外す

液晶のガラスを外すと、写真のような、液晶がむき出しの状態になります。
ここで、トルクスドライバー(ヘックスローズ)を使用してアルミ部分に付いているネジを外していきます。ネジは全部で上辺4つ下辺4つ左右にそれぞれ2つずつで合計12個ありました。
無くさないように注意。

なお、ネジの種類は下辺の中央2つのネジだけ長く、それ以外は全て同じものでした。

アルミパネルは、裏側を抱え込むようにして上辺から外し、少し手前に持ち上げた後に下辺方向へスライドすると上手く外れました。

外れたー\(^o^)/やっぱりここもきったねー!!!

多分HDDが壊れた原因って、ホコリの所為で温度が上がりすぎて壊れたんじゃないかと思うくらいホコリが酷かった…。
ホコリは掃除機で一通り吸い取ったあと、細かい部分はエタノールを付けた綿棒でクルクルするときれいに取れます。きれいになった後の写真撮りわすれた。

上部に赤外線のセンサーのケーブル(多分)があって、セロハンテープが巻いてありました。
これも一旦外します。

4.液晶パネルを外す

液晶パネルの辺縁にもトルクスドライバーを使用する星形のネジが左右にそれぞれ4つずつありました。
これも外します。というか、HDDは液晶の裏中央にあるので、外さないと交換出来ません。
直接液晶部分を触ってしまうと、皮脂がついて汚れてしまうので気をつけましょう。
ネジを外したら、左右の金属部分を持ち上げて液晶パネルを外します。

液晶パネルを剥がして内部を見ると、僕の2007Midでは、左側の接続、右側の接続、中央下部の接続の3本のコネクタがありました。
それらを外したかったのですが、どうにも上手く外せなかったので、高さ20センチくらいの台の上に液晶パネルを乗せ、中を確認しました。


片手で撮ったからブレてら…。

中央の緑の基盤が見えているのが目的のHDDです。
右の黄色のシールが貼ってあるのは光学ドライブです。

5.HDDを外す

まず、HDD中央にあるコードを外します。温感センサーらしいです。テープかなんかで貼ってあるので剥がします。

HDDを止めているネジをトルクスドライバーで外します。
ここで外すネジは上部の2つだけです。
僕は下にある2つのネジも外そうとして、一つネジを外した時点で、外さなくて良い事を理解しました。え、だってググったサイトに書いてなかったんだもん…。

上部2つのネジを外すと、ドライブを止めている黒いプラスチックの部品が横にずらして外れるようになります。この後にHDD本体を上に持ち上げるとスイッと取り出す事ができます。

外れました。

6.新しいHDDに付け替える

元々入っていたHDDの下部にトルクスネジが2つ付いているのでこれを外し、新しいHDDに取り付けます。
外した時と同様に、新しいHDDを設置し、黒いプラスチックのHDD止め(?)をスライドして設置し、ネジを締めます。


右が純正のHDD。リンゴロゴが確認できます。western digital製でした。


新しいHDDを取り付けました。

7.外したものを全て取り付けて行く

同じ手順で外していたものを戻していきます。ネジの付け忘れに注意。

8.OSインストール

OS10.7以降はHDDやSSDと別の領域にOSがあるのでストレージを交換しても普通に起動するとOSインストール画面が起動した覚えがあるのですが、元々のマシンが10.5だったりするとインストーラーディスクが必要になるみたい。持っててよかったSnowLeopard!!

インストールディスクをドライブに突っ込んで、option(alt)キーを押しながら起動→「インストールディスク」をクリックすれば、必要事項の入力とかあるけど大体40分くらいでOSインストール完了!

320GBから2TBになってよみがえったiMac!!

多分SSDもマウンタ買えば出来るはず。興味がある人はやってみるといいよ、でも壊れても自己責任だよ、僕の所為にしちゃいけないよ。

メモ:concrete5のページ属性で指定した画像を、カスタムテンプレートから表示する方法

ページリストで、記事ページのサムネイルブロックを表示する方法もあるのですが、ケースバイケースで属性から画像入れた方が良い場合もございまして、
以前テーマファイルに属性の画像を表示する方法を書きました。
メモ:concrete5のページ属性で指定した画像を表示する方法

以前の記事の内容ではちょっと問題がございました。
↓以前の書き方

<img src="<?php echo ($c->getAttribute('ハンドル')->getVersion()->getRelativePath());?>" alt="" />

これ、カスタム属性に画像ファイルが入ってないとエラーが出てしまいます。

↓なので、個人的には画像があるときだけ表示するという方法を取るのが望ましいのかと思いますね。

<?php
  $変数 = $c->getAttribute('ハンドル');
  if($変数) {
    echo '<img src="' . $変数->getVersion()->getRelativePath() . '" alt="" />';
  }
?>

そしてカスタムテンプレートで表示する場合は、

$c->getAttribute('ハンドル')

を↓

$cobj->getAttribute('ハンドル')

に書き換えると対応できました。

[concrete5]悲劇的!Designer Contentの落とし穴

結論

いきなり結論です。

Designer contentを使用してブロックを作成し、間違えて作成したブロックを削除する際には、
「FTP上のblock/”Dir”」と、「データベース内のblocktypeにある”Dir”」の両方を削除してください。
※”Dir”はブロックタイプ作成時の任意です。

実ファイルとデータベースのテーブルを削除しないと思わぬエラーの原因となります。

なお、以下は今日起こった現象の振り返りなので、あまり意味がありませんのであしからず。

ブロックが追加出来ないよ!?

本日、concrete5をご利用のクライアントのサーバー移行作業を行っていた所、「ブロック追加」が一切機能しなくなりました。
「あれれー、おかしいなぁー」と思い、管理画面からブロックタイプを開こうとした所、Internal Server Error 500との事。

はてさて、一体何なんでしょうか。
何はなくともエラーログを見る習慣付けは必要だと思いました。全く関係のないアドオンを消したりしてまた入れ直したり、とても面倒な事をしてしまいました。
エラーログを拝見いたしました所、2つのエラーの記録がございました。

エラーの内容

[code]
[error] [client xxx.x.x.x] PHP Warning: require_once(/home/httpd/public_html/updates/concrete5.6.0.2.ja/concrete/blocks/links/controller.php): failed to open stream: No such file or directory in /home/httpd/public_html/updates/concrete5.6.0.2.ja/concrete/core/libraries/loader.php on line 205, referer: https://xxx.xxx.xxx.xx/index.php/dashboard/

[error] [client 219.8.4.64] PHP Fatal error: require_once(): Failed opening required ‘/home/httpd/public_html/updates/concrete5.6.0.2.ja/concrete/blocks/links/controller.php’ (include_path=’/home/httpd/public_html/libraries/3rdparty:/home/httpd/public_html/updates/concrete5.6.0.2.ja/concrete/libraries/3rdparty:.:/usr/share/pear:/usr/share/php’) in /home/httpd/public_html/updates/concrete5.6.0.2.ja/concrete/core/libraries/loader.php on line 205, referer: https://xxx.xxx.xxx.xx/index.php/dashboard/
[/code]

サーバー移行と同時にconcreteのアップデートも行ったのですが、アップデート前は問題なく利用出来てたというところがポイントです。

で。

エラーの内容は、「そもそも/home/httpd/public_html/updates/concrete5.6.0.2.ja/concrete/blocks/links/controller.phpってファイルがおかしいじゃんか、無いじゃんかー。」って仰るわけです。
私としましても、「うーん、そんなブロックは使ってないよなぁー。」と頭を抱えるしかございませんでした。

救世主は移行前のサイトでした

Designer contentは非常に便利なアドオンで、ブロックの内容を自由に組み立てる事ができます。
ただ、弱点が一つあって、Designer contentでブロック作成をする際に、内容を間違えて登録してしまった時です。
間違えて登録してしまった後に、管理画面から修正を行おうとしても出来ないという弱点があって、簡単に順番の入れ替えや、静的タグの追加くらいなら、直接生成されたphpファイルをいじれば直せるのですが、テキストフィールドの追加を忘れてしまった場合は別のブロックタイプをDesigner contentで新たに作成し直すしかないのです(一応方法はあるのでしょうが、私はphpに詳しくないので作り直した方が速い。)

そう、過去の負の遺産が残っておりました。

間違えて作成してしまったブロックタイプを、FTPからディレクトリごと削除していました。
移行前の方では、ディレクトリが存在していないにも関わらず、動作していました。

でも、データベースには作成したブロックタイプは残っているので、concreteのcoreにある「/concrete/core/libraries/loader.php」は居なくなってしまった「/block/links」を探し続けてしまいます。

ここからは推測ですが、管理画面からアップデートをかけた際に、concreteのcoreファイルのパスが変わる関係で、アップデート前ではディレクトリが無くてもごまかして動いていたものが、動かなくなってしまったと考えています。

Designer contentを使用してブロックを作成し、間違えて作成したブロックを削除する際には、
「FTP上のblock/”Dir”」と、「データベース内のblocktypeにある”Dir”」の両方を削除してください。
※”Dir”はブロックタイプ作成時の任意です。

[メモ]Concrete5のマルチアップロードでError: 401

どないなっとんねん!怒るでしかし!!

という冗談はさておき、Concrete5のファイルマネージャーは非常に便利です。
強力なファイルの検索はもちろんの事、複数のファイルをセットにまとめて、スライドショーで利用したり、一度に複数のファイルをアップロードしたり…etc

で。

特定の条件でマルチアップロードが動かなくなります。

こんなふうに。

理由としては下記の様にいくつか考えられますが、どれも該当しなかったので。

  • /filesとそれ以下のすべてのディレクトリの権限が755になってない
  • /filesとそれ以下のすべてのディレクトリの所有者がapache以外になってる
  • ファイルサイズがphp.iniに書かれているサイズよりも大きい

じゃー、なんなのさって話で。

リリース前の段階って事で、普段納品前は、サイトの閲覧権限を「管理者」のみに設定してクライアントに確認してもらってるんだけど、諸事情で基本認証かけたんですよ。

そう!
聡明な皆様ならもう、お気づきですね!「この先は、言わなくてもわかりますよね?」とは言いませんが。

基本認証がどうやら邪魔しているらしく。
つまり、concrete5ではベーシック認証なんかかけなくても、管理画面から簡単に公開非公開選べるんだから、それでやれ、という事だと受け取っておきます。

[Concrete5]メールフォーム送信時にページの先頭に移動してしまう問題

前回の記事同様、Concrete5についているフォームブロックには結構不満があってですね。

送信ボタン押した時に、ページの先頭に行っちゃうんですよ。

例えば「お問い合わせ」っていうお問い合わせ専門のページを作って、コンテンツ部分はフォームのみしか存在しないっていう場合は、ページの先頭に戻ってもウインドウ上にはフォームのエリアが見えているから、エラーがあった場合や、確認画面、完了画面も見えるから言う程問題じゃないんですが、
縦1000pxくらいの紹介コンテンツがあって、「申し込みは以下のフォームから」みたいなフォームを含むページの場合、送信ボタンをクリックした後にページの先頭に戻ってしまうと「あれ?これ送信できたのかな?」って思って改めてそこまでスクロールして見てもらわなきゃいけないという、ユーザに負担をかけるユーザビリティ的に非常に粗悪なものになってしまう訳です。

で、どうしたもんかなーと考えたあげく、フォームブロックのカスタムテンプレートではどうにもなりませんでした。
というのも、submitボタンクリックした時点で、フォームのID取得のためにURL内に「#」が使われてて、フォーム部分へスクロールするためのhtml側の「#」が重複して使用出来ないっていうのがあって、もう私諦めようと思いました。
お客さんには説明して、「フォームだけは別ページにしてもらえませんか」って懇願して、許してもらおうと思ったんですが、
今をときめくjavascriptちゃんなら!javascriptちゃんならきっとなんとかしてくれるッ!と思い、試してみました。

[javascript]
$(function(){
var getURL = location.href; //URLを取得
var contactScroll = $(‘#contact’).offset().top; //#contactの位置を取得
if ( getURL.indexOf( "submit_form#" ) != -1 ) { //indexOfでURL内に含まれる文字列"submit_form#"を検索して、存在した場合の処理
window.scrollBy(0, contactScroll); //ウインドウを#contactの位置までスクロール
}
});
[/javascript]

前述の様に、フォームブロックでフォームIDを取得してURLに#が使われてるなら、URLに入ってるフォームIDを逆手にとってやろうと。

↓フォームの送信ボタンをクリックしたら、URLにクッソ長いパラメータが付くのですが、共通して「cID」とか「stackID」とかが存在します。
https://www.xxxxxx.xcom/index.php?cID=1&stackID=169&bID=69&btask=passthru_stack&ccm_token=1363257182:45a7934ae05865ab764c648a45552a6b&method=submit_form#1363252323&listbeginp=

フォームのブロックに必ずつくのは「submit_form#」なので、javascriptでURL内を検索して「submit_form#」があったら「#contact」の場所までウインドウをスクロールしてやれば良いと気づいたんです!

あぁ、解決できてホント良かった!!

[concrete5]拡張フォームブロックでエラーがでる。

送信ボタンを押すとページの先頭へ行っちゃったり、確認画面→完了画面がなかったり、concrete5のフォームだけはどうにもイマイチ感が拭えない。
他の機能が優秀すぎるだけに、それだけがとても残念です。

で、上記の問題があるから、tomoacさんの拡張フォームブロックを使わせていただいてるんですが、ブロックを追加してから改めて編集しようとすると必ず編集タブとプレビューでエラーがでる…。

「write のパーミッションキーの取得に失敗しました。」
どこのパーミッションが書き込み禁止になってるかが全くわからぬ。
/packeges/form_tomoac/は全て777になってるし、つーかそもそも/packeges/form_tomoac/のパーミッションはこのエラーが出る様な問題ではない気がするし。

いったいなんなんでしょうね。