> おっしゃってる事は理解できますが、内容は「WordPress」に限らず、すべてのCMS、ひいては動的サイト全般にいえる問題ばかりです。
WordPressに限らない内容は含んでいるとは思いますが、広く普及している分、カスタマイズ情報が世に出回り、内容の詳細を知らなくても比較的細かいカスタマイズが出来るソフトウェアとしてWordPressを取り上げています。

> DBが複雑という部分ですが、WordPressなんて単純なほうです。　テーブルが20個もないでしょう。　テーブルが少ないCMSのほうが、汎用性低そうで怖いです。
もちろん、もっと複雑な構成を持つCMSも存じておりますし、業務システムであればより複雑な構成を構築することもあると思います。
「汎用性」をどう捉えるか、という問題はありますが、汎用性が低そう、という印象は一概に言えることでも無いのではないでしょうか。

> WordPress（CMS）とスクラッチを比べ「違いない」とおっしゃるということは、恐らくどちらの開発もされたことはないのでしょう。
> あなた様の技術力不足をWordPressに責任転嫁してる以上、
> 「WordPressで構築されたサイトを批判、中傷するものではありません」
> は理解できますが、
> 「WordPressおよびCMS自体を中傷している」
> と捉えられても仕方のない内容です。
恐縮ですが、どちらの開発も経た上での意見を記しています。
また、「違いは一つもない」と断定した記述ではなく、そこにかかる稼働は結局のところ同程度なのではないか、どこに優位性があるのか？という問いを投げる意図での記述です。
ご意見頂けることは大変ありがたいのですが、推測からの断定をされてしまいますと意見の交換がしづらい状況になりますのでお控え頂けると幸いです。

また重ねて申し上げますが、今回の記事の意図は冒頭にも記述した通り、WordPressの批判／中傷ではありません。
その可能性や有用性を認めた上で、潜む危険性への指摘を意図しています。
ではどうすれば良いのか、という答えは各人に任されたことだと思いますし、私が最適解を持っているなどとも考えていません。
「こうしたほうが良い」という意見があれば、是非お伺いしたいですし、それについて議論することは記事を読んでいる誰かのために有用だと言えるのではないでしょうか？

DBが複雑という部分ですが、WordPressなんて単純なほうです。　テーブルが20個もないでしょう。　テーブルが少ないCMSのほうが、汎用性低そうで怖いです。

WordPress（CMS）とスクラッチを比べ「違いない」とおっしゃるということは、恐らくどちらの開発もされたことはないのでしょう。

あなた様の技術力不足をWordPressに責任転嫁してる以上、
「WordPressで構築されたサイトを批判、中傷するものではありません」
は理解できますが、
「WordPressおよびCMS自体を中傷している」
と捉えられても仕方のない内容です。

> ファイル名とファンクション名を一致させる
> あとはSmartyプラグインのフォルダ（Smarty/plugins）に設置すれば使えます。

これは、オートロードの対象になるための条件ということであって、そこに必ず設置する必要はないようです。

つまり、smartyを利用するプログラムが読み込むソース中のどこかに、関数定義(smarty_modifier_[オプション名])があれば、今のところ使えるみたいですね。

もっともこれは、(pluginへ設置しようとも)黒箱破りな方法だし、将来的に利用不可になるかもしれないですね。

本来は、register_modifier() を使うべきなのでしょう。しかし、引数にクロージャをサポートしないうちは、結局グローバルな関数定義が必要ということですから、個人的には気持ちが悪い。結局、smarty_modifier_[オプション名]　を定義してしまったほうがマシかな（？）

> 業者さんに怒られそうなのでフォローというわけじゃないけど、
> するどい業者さんはもう見据えていて、ベクトルを変えている感触があります。
> それこそおっしゃるように、「ソーシャル」な方向で。

そうですね、僕もそう思います。

> 本題に戻りますが、近所なので近々桃太郎寿司に行きますね。

焙り三種がおいしいので是非。