【最新記事】⇒仮公開開始(2019/02/07)

色々手間取った

今日やった事は2つ。1つは検索する前に件数をカウントして、実際に行を選択してくるかどうかの制御を行う事と、絞込み条件エリアの新設。

件数のカウントは簡単にできた。知恵だなーと思ったのは、

SELECT COUNT(col) FROM ... 

としただけだと、PHP側で値を取って来るのがやや面倒なのが、

SELECT COUNT(col) AS cnt FROM … 

とする事で、$row->cntでアクセスできるようになるというあたり。普通にSELECTする時はAS使ってたけど、カウントで使うってのはなるほどなと。

しかし、手間取ったのはこの後で、検索結果がある一定数を越えたら検索しないという制御を行うにあたり、「一定数」を定数化して、プログラムに手を加えなくとも可変にできるようにしようと思った部分。ショートコードを画面の上方においておき、そこでグローバル変数にデータをセット(今は固定値だけど、将来的にDBから持ってくるようにしたい)し、Ajaxで呼び出されるコールバック関数内でその値を参照しようとしたのだが、全然参照できなかった。

よーく考えてみると、ショートコードとAjaxで動くPHPプログラムは、同じfunctions.phpに記述されてはいるものの、恐らく別プロセスで動いているのだろう。そんなのいくらグローバル変数宣言したところで参照できるはずもない。恐らくもう少し上のレベルで共有するような仕組みがあると思われる($wp_dbのような)のだけど、ちょっとそこまで辿りつけなかったので今回はグローバル化はやめて、今は固定値を入れたままにしている。将来的にはここはDBから持ってくるにしても、管理用テーブルも設計しないといけないし、後の課題にしようかと思う。

Ajaxで呼び出される度に、管理用テーブルを検索しに行くのが、どの程度のオーバーヘッドなのかは、今後の検証で明らかにして行く事にする。

そして、次が絞り込み条件エリアの新設。まぁ手間取ったのはあまりPHPに慣れていないからであり、時間はかかったけどある程度はできた。しかしデザイン的にこれじゃ使えないw

検索条件エリアは、スタイルシートのdisplay属性にnoneを指定して消しておき、チェックボックスの選択で表示しようとしたのだけど、余り綺麗に並んでくれない。inlineとかinline-blockとか色々あるけど、親に「inline-block」子に「flex」を指定したら、まぁまぁ想定に近い形にはなった。だけど正直酷いw

幅や折り返しなど、まだまだ調整しないといけないだろうし、style属性直書きってのもみっともない。ここはclassを子テーマのstyle.cssに定義し、HTMLやPHPではそのclassを使うような記述にしないといけないだろうな。ただ、こういうHTMLの作り方は実は今までやってきていないので、すんごく不安。でもこれができるとHTMLはかなりスッキリできるはず。

今日はここまでにして、明日は絞込み条件をAjax側に渡して実際にWHERE句を動的に作る部分の実装をしてみようかと思う。データの入力とどっちが先の方がいいかな…。このあたりは明日の状況次第という事にしよう。

今日の進捗は少なめ

今日は他にやりたい事もあったので、あまり多くは作業できなかった。取りあえず表示項目の追加をやってみた。

テーブルには、いくつかのデータを数値で保持している。いわゆるコード的なものであれば、別テーブルを作ってそこに文字列データを格納して、JOINしていくのだろうけれど、今回追加した項目は、ほぼ固定の文字列なのでプログラム側で対応する事にした。

最大でも10個程だし、PHPのarrayで文字列配列を作成し、そこへ格納しておき、SELECT結果の数値をインデックスにして取り出した文字列を表示するという目論み。

まぁ大した処理では無いのであっさりとできたけれど、こういう文字列配列をいくつも持つ場合、関数内で個々に持つのではなく、共通に作ってグローバル変数化した方がいいのだろうか。と言っても、検索用のコールバックは多くて二つだし、その為にグローバル変数化するのもどうだろう。(メンテナンス製という意味では価値はあるか)

C言語で言うところの、#include <mystr.h>みたいな感じにするのがいいのかな?でもあんまり独自ファイル増やすのもどうなんだろう。まだJSファイルも作ってなくて、固定ページの中にJavaScriptを直書きしちゃってるし、そこいらへんも含めてファイル構成も考えないといけないのかもしれない。

取りあえず、今日はいくつかの情報を検索結果に追加したという事でよしとしよう。明日はもうちょっとやりたい事を進めたいな。

子テーマ成功したぜ!

style.cssは間違ってない、functions.phpのファイル名も間違っていない。JSでエラーもでておらず、ではPHP側でエラーなり出ているのだろうと想像してログを見てみたけれど、結局確実なエラーのようなものはでていなかった。

親テーマと子テーマ、それぞれのソース(HTML)を保存してDIFFとって見た所、違う箇所は2箇所のみ。一箇所はどうやら自動生成されているであろう、検索フォーム。

もう一箇所はstyle.cssを読み込むlinkタグの部分。style.cssのURIのテーマフォルダ名が異なるだけ。そこが逆に違和感。

となると、CSSの読み込みがうまく言ってないという事。functions.phpの名前が間違っていないのであれば、中身が違うとしか思えない。

<?php
add_action( ‘wp_enqueue_scripts’, ‘theme_enqueue_styles’ ) ;
function theme_enqueue_styles() {
wp_enqueue_style( ‘parent-style’, get_template_directory_uri() . ‘/style.css’ ) ;  wp_enqueue_style( ‘child-style’, get_stylesheet_directory_uri() . ‘/style.css’, array( ‘parent-style’ ) ) ;
}?>

参考元からコピペしたfunctions.php

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' ) ;
function theme_enqueue_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' ) ;  wp_enqueue_style( 'child-style', get_stylesheet_directory_uri() . '/style.css', array( 'parent-style' ) ) ;
}
?>

正しいfunctions.php

違いがおわかりだろうか?w実は、「引用符」がマルチバイトになっていたー!。これは本当に気付けないっすよw参照元サイトで「このソースをそのままペーストしてくれたら動きます」をそのまま信用したわけですが、むしろこれをエディタ(Notepad++)で開いた時に、引用符で囲った部分(文字列)の「parent」部分が何故か色が変わっていたのには気付いていたのに、それを深く考えずにそのままにしてしまっていたのが原因だった。

「parent」は恐らく色々な言語で予約語になっているのでハイライト表示されていたんだろう。だけど文字列の中であればハイライト表示されるはずが無い。そこに気付けずに丸一日を無駄にしてしまった。勿体無いことをしてしまった。

さて、これでようやく子テーマができて、検索画面で必要なショートコードや、Ajaxから呼び出すコールバック関数を子テーマ側に移す事ができたので、親テーマの更新に左右されない開発ができるようになった。

んだけど、ひとつ気になってるのがあって、$wp_dbというインスタンスから自作のテーブルを参照するにあたり、wp_db.phpというソース中に、使うテーブルを登録する必要があるとのことなので、追加しているんだけど、WordPress自体の更新で上書きされてしまうだろうからこの後気をつけないといけない。けど、子テーマのようにこのあたりのカスタマイズも実は更新に左右されないようになっていたりしないのだろうか?

おいおいこの辺りは調べないといけないな。さて目的は達せられたので次にやる事を決めないといけない。けど、それは明日にしようかな。

子テーマがうまくいかない

1時間以上格闘したけれど、子テーマを運用しようとしても、画面が正しく表示されない。

うまく反映されないので検索すると「functions.php」の名前が間違っているというのが圧倒的に多いんだけど、何度見ても間違えていない。パーミッションの関係かもしれないと思って直接747とかにしてみたりしたが関係なかった。

zip形式でのアップロードではなく、直接ftpツールでファイルとか作ったのがまずいのかと思って、zip作ってインストールとかしてみたがやはり変わらず。

というか、CSS自体が読み込めていないのではなくって、単に表示が崩れる(20-17のような画面にならない)だけなので、もっと別に原因があるのかもしれない。このまま続けても埒が明かないので、取りあえずもとの状態に戻して、子テーマは使わない状態に戻した。

しかし、このままではテーマ含め色々と更新も怖くてできないし、早急になんとかしないとならないのは間違いない。JSでエラーがでている様子は無いし、テーマのライブプレビューとかやろうとすると、500でエラーになっていたりするので、PHP側で何らかのエラーがでているのではないだろうか。

取りあえず、現状までのログを保存してエラーがでているかどうか、確認してみようか。

外観などなど

取りあえず、訳もわからずに貼っていたヘッダ画像などは全て取っ払ったwとは言え、トップ画面だけは何かないとサマにならないので、グラブルの運営さんが「ご自由に」と言ってくださったルナール画伯の画像を設定させて頂いた。

つーても、早い内にもうちょっとまともなトップ画面を調達(作るにしろ探すにしろ)しなければならないだろうな。

今使っている20-17というテーマは、きっとシンプルなテーマなんだろう。思ったより設定ができないし、トップ画面は小さめなものを用意してもPCだと拡大されておったまげたりする。でもスマホで見ると丁度良かったりして、結構いいのかもしれない。

現在、ホームページからスクロールしていくと、ブログを含めたいくつかの固定ページが表示されるようになっていて、実験中の「検索画面」も含まれているけれど、検索画面へはメニューから遷移して、ホームページとしては、サイトの説明や問い合わせ、ブログのみにした方がいいのかもしれない。

ひとまず、これで外観については終了でいいか。引き続き、子テーマについて調べてみよう。特に検索画面についてはその方が良さそうだ。

ひとまずプログラム完成

プログラム的にやりたかった事が、ひとまずこれで全部検証できた事になる。

1. 検索項目をDBから取り出してプルダウン表示(MySQL)
2. 二つのプルダウンを連動させる(DynamicHTML)
3. 検索条件に合致したデータを画面遷移させずに表示(Ajax)
4. 複数のテーブルの情報から1回のSELECTで全て取り出す(JOIN)

検索条件を増やすのかこのままなのか、取り出す情報の追加、さらに検索結果からの詳細表示など、機能全体としてはまだまだやるべき事はあるのだけれど、基本はここまで検証してきた結果を組み合わせていけばできるはず。
今後はDBに格納するデータを増やして、画面の体裁などを検証していく感じになるだろう。

という事で、現状残っている懸案事項について解決していく必要がある。
1. そもそもWordPressまだ良くわかってない
2. 仮で設定してる画像とか置き換えが必要
3. 子テーマってなんぞ?

そもそも、WordPressで作ってていいのか?って懸念事態はあるんだけど、MySQLやらPHPやらjQueryやら考えると、確かにこれ開発するのには相当便利なんだよね。
将来恒久的に維持していく事を考えた場合、サーバーの維持費とかも考えないといけないだろうけど、WordPress自体なら自前のLinuxサーバーでも導入できるだろうし、色々な可能性に対応できるのがいいな。

ひとまず、今日はWordPress(テーマ)の設定を色々見直して、(まだしないけど)公開に値するような体裁にする事を目標にしよう。

検索結果の表示が完成

プルダウンから項目を選択し、ボタン押下でDBを検索してテーブル表示するという一連の流れがようやく形になった。

検索項目はPOSTパラメータとしてPHP側へ渡し、PHP側でJSON形式にencodeしたデータをWordPress側へ返すという形になっている。
JavaScriptでJSON.parse()でjson形式に戻した上で、結果をテーブルに表示している。
まだまだ手探りな部分もあるので、色々と決め打ちにした作りになっている部分が多い。
例えば、結果表示のテーブルにはtbodyタグが1個という前提になってしまっている。もうちょっと勉強してBodiesとかで制御すればいいのだろうけど、現状はこのままでしばらくいいか。(タグ指定でtbodyを取得しておき、新しく作ったtbodyに検索結果を行追加して、最後に取得してあったtbodyを削除して、新しく作ったtbodyを追加するという方法を取っているが…、もうちょっとスマートなやり方がありそうな気はする。)

現時点では、IDなどがそのまま検索結果として表示されているが、本来は別テーブルにある名称などを表示させたい。その場合プログラムでやるのではなく、複合SQLでやるつもりなのだが…、この辺りの知識が疎いので手間取りそう。
最悪、プログラムでやる事も考えないといけないが、その場合SQLが何回もでてしまう事になりかねないので避けたい。テーブルの項目二重持ちもないでは無いが、それはやはり避けたいのでひとまず複合SQLに挑戦しよう。

複合SQLの目処がたったところでテーマの調整に入ろうかと思う。使ってる画像があまりに酷いし、もう少し見易い画面にしないとダメだろう。
検索画面自体もどうにも野暮ったいし…。

ブログとかはとりあえず我慢して、検索結果画面だけ別テーマにするとかが良いのだろうか。その場合はいわゆる子テーマとかになるのかな?
そういう辺りを含め、色々やってみたいと思う。

とりあえず、今日やりたかった部分はある程度形になったので、今日は満足w

非同期通信成功!

Ajaxによる、非同期通信ようやく成功!

変数名の間違いをしている事に全然気づけず、数時間無駄にしてしまった…。
JavaScriptの場合この手のミスはやってしまいがちだけど、中々難しいな。
まぁ、そういうミスが起こり易いという認識ができたからよしとしようか。

とりあえず、ボタンを押下して、サーバー側(PHP)関数を呼び出して、結果を表示するという一連の非同期通信処理ができた。

よし、次は条件をサーバー側に渡して、その条件で検索するという所までを目指そう。
暗号化とか色々お作法はあると思うけど、まずは単にPOSTでパラメータを渡して、それをWHERE句に指定して検索をかけ、結果を得る事を目指す。

うまく行けば、今日中にそこまではいけるぞ。

検索機能はどう作る?

検索ボタンを押した後、画面遷移させずにDBから検索させて結果を表示させる。
表示させる部分はDOM操作でOK。表示させるデータはJSONでやり取りする…のかな?

検索機能の本体はSQLで処理するだけだし、PHPでやるんだろう。
だとすると、function.php内に実装して、それを呼び出すという形になるのだろうか。
初期表示では無いので、ショートコードでは無い。

結論から言うと、あらかじめ用意されているWordPress用の関数を使ってやり取りするらしい。表示時に呼び出すもの、随時呼び出すものとあるが、それらはfunction.php内に宣言しておき、必要なフック、ハンドラに渡すような感じらしい。

とりあえず、習うより慣れろ。

まずボタン押下でAjaxでDOM変更する一連の流れを書いてみよう。

よーしよーし連動してる

色々と手間取った(単に変数名の取り違い)けれど、どうにかこうにか形になった。

プルダウン1で選択したものを元に、プルダウン2を絞り込み表示する。先頭を選んだ場合には全てを表示…という処理が、PCブラウザでもスマホブラウザでも正しく動くようになった。

想定通り、固定ページ内の最後で、現状のプルダウン2のクローンを保持しておき、プルダウン1のonChangeフック関数の内部で、一旦プルダウン2を初期化(pulldown2.length = 0;)してから、該当するオプションオブジェクトを、保持しておいたクローンから抜き出して追加。速度的にも問題ないように思える。想定では間に通信入らないはずだし、これでいいはず。

PCとスマホ両方動くとはいっても、どちらもChromだから当然と言えば当然なので、又別ブラウザでも確認は必要だとは思うけど、今はそこまで厳密な確認は必要ないだろう。

とりあえず、当初目標だった二つのプルダウンの連動というものは達成できたので、次のステップに進もうかな。

次は指定された条件でDBを検索し、その候補を表示するという部分か。

大雑把には次のような感じか。

  • 結果はリスト表示
  • 表示されたリストを選択してさらに詳細表示が可能
  • 検索条件とは同じ画面に表示

まずはここまでを目標にしよう。