2018.05.24
hanaCMSにブログ機能を追加しました
hanaCMSにブログ機能を追加しました。
wordpressの投稿タイプに似てるかも。。。
wordpressにはカスタム投稿タイプというものがあります。あとタクソノミーとか。なぜそんなものが必要なのか。それはpostを保存するテーブルが同じでコンテンツとして一元管理するために必要だからです。
wordpressをCMSとした場合、記事の投稿だけではなくサイトのコンテンツを分けるとそのサイトの構造が感覚的に分かりやすい。
実績にもある、バイク屋さんのお仕事を今現在させてもらっている最中なわけですが、バイクの在庫状況、販売実績というのは見た目的にはページですが、できればエクセルの様なリストで管理されるべきデータですよね。
hanaCMSは言わば、パソコン上でhtmlファイルを作成していくような木構造のデータを扱うcmsなので、ブログの様な木構造をとらないタイプのデータ処理とは相反するのが難点です。
木構造でもやっぱり必要なアーカイブ管理
これまで、こういった依頼はプラグインとして、別テーブルを用意して、CMSのページに関連付けて出力していました。ですが、もうイチイチ管理画面のフォーム書いてロジック書いて～なんてやってられない。しかも、hanaCMSの売りは「見たままでHTMLを編集」できる機能。
これを別テーブルで作成したコンテンツのエディタに対応させるとなると…継承させたクラスを用意して非対応データの入力フォームを増やして…
そんな訳で、いっそのこと投稿タイプ的な何かを実装してしまえ！と「コンテンツタイプ」を実装し、色々と管理しやすく且つ「見たまま…」なんて事もできるようにバージョンアップしました。
また、ブログ機能はアーカイブインデックスや、記事をタイトル、日付、カテゴリ、タグを固定位置に表示させるテンプレート式。これ無しでは記事を書く度にあれこれ手を加え続けることになるので、ブログ記事タイプの見たまま編集に対応できるように少しエディタを改造。
課題山積みアーカイブ機能
木構造型のcmsにどうやってアーカイブ型を適用させるのか。これは本当に開発当初から悩んでいます。特に問題があるのは全文検索機能。1対多の拡張用データのテーブルが存在することになった。これをgroup_concatで結合して全文検索対象に。一応1万件のコンテンツで試験はしてみたが、200msクラスの悲しい結果に。
やはり、100万件オーダーに対応するには別テーブルを設ける必要があるのかないのかどうなのか。