このブログはサンプルも兼ねています。
ここでは「カスタム投稿タイプ」の一つの例として
トップページに表示する「お知らせ」としての使い方を挙げています。
インフォメーションの１と２は一つの記事を異なったフォーマットで表示させています。
インフォメーション１の方はタイトルとコメントが、
インフォメーション２の方はタイトルと日付がそれぞれフロントページだけに表示されるように設定しています。
また、２の方はタイトルをクリックすれば、その記事の詳細のところにジャンプするようにしています。
その際、テーマのファイルを操作すれば、この例のようにブログ本体とは違ったデザインにもできます。
詳しくはメニューのEXTRA→NOTEBOOK→MEMO-1をご覧ください。
１件毎の個別ページを開くよりも
全件を１ページにまとめて表示します。
インフォメーション２のタイトルをクリックすると
記事がループ表示されるように設定しています。
その際、投稿（記事）IDを取得して
直接個々の詳細へとジャンプするように設定します。
カスタムフィールドを使う方法もありますが、
記事を追加する際には設定を忘れがちになりますので
お勧めはできません。
ここの例ではブラウザのサイズを小さくしないと、
目的のところにジャンプしているかの確認はできません。
インフォメーションというタイトルでサイドバーの下の方（「アーカイブ」の直ぐ下）にも見出しだけ表示させています。
これも一つのカスタム投稿タイプを違った形で表示するというサンプルです。
導入にはやはり”Custom Post Type List Widget”というプラグインを使用しています。
現在のWP最新バージョン6.4.1には対応できていません。
PCで見る限りでは何の問題もないので、気付いていない人が多いかもしれません。
モバイル用のコードの一部が読み込まれないため、表示が著しく乱れます。
サポートフォーラムを見ると、開発者も問題点は把握されているようです。
修正されるまでにはかなり時間がかかるかもしれません。
今のところ問題の解決策としては、バージョンダウンしかないようです。
フォーラムには6.3と書かれています。
方法はプラグインを使うのが簡単かと思います。
－ 追記 11/16 －
その後、フォーラムを詳しく読んでみたところ、
“WP 6.4 Theme path fixer”というプラグインを導入すれば
最新バージョンでも“Multi Device Switcher”は正常に動作することが判明。
このサイトでも試したところ、問題ないようです。
トラブルの原因は子テーマへのパスが通らず、親テーマのパスを優先するためらしいです。
したがって、マルチデバイスの方の修正は必要ないと思われます。
内容は、お知らせがあるので至急カスタマーサービスに連絡をしてほしいというもの。
これは紛れもなく詐欺メールです。
連絡先には03から始まる固定電話番号を使って真面な会社を装っていますが、
何しろ初めに会社名の記載がありません。
まったく間抜けな奴らですね。
調べてみると、身に覚えのないサービス利用の未払い金請求が多いようです。
直接電話がかかってきたら、先ずどんなご立派なサイトを用意しているのか
URLを聞いてやろうと思います。
どうせ、どこかのサイトのソースを流用しているでしょうね。
もちろんアクセスする前に詐欺サイトの検索をしなければなりません。
次に、真面な会社ならユーザー専用ページを用意しているでしょうから、
IDとパスワードを忘れたと言って教えてもらいます。
断っておきますが、当方プライベートのIDとパスワードは使い分けていますし、
与えられたものは大体直ぐに変更するようにしていますので、
にわかに先方が作ったであろうものは信用しません。
ついでに登録しているであろうメールアドレスも尋ねます。
こちらもプライベートなものでないようなら、詐欺と判断します。
普通ちゃんとした会社なら、利用料金は未払い金が発生しないように
カード払いになっていて、利用者にカード番号を登録してもらうでしょうから、
登録されているカード番号を尋ねても良いのではないでしょうか。
先方はカードの有効期限切れを主張するでしょうが、カード番号は残っているはずです。
ここまでのやり取りで相当時間がかかるでしょうが、これもこちらの作戦です。
まあ、日本語がちゃんと話せる相手なら手短に終わるでしょうが、
恐らくそうは行かないと容易に想像できます。
以前から気付いてはいたのだが、Ktai Entryとういうプラグインはバージョンの新しいphpやWordPressではNGだ。
新しいWPであっても古いphpを使えば投稿できていた時期もあったが、
最新のバージョンではそれもNGとなってしまった。
理由は明白で、かなり前から更新がなされておらず
WPのバージョンアップに対応できていないのだ。
となると代替のプラグインを使うしかないのだが、
今のところ”Postie”が一番のお勧めではないかと思っている。
ただ、絵文字入力を希望している人は、データベース側で文字変換コードが
対応していないと、投稿できないので注意が必要だ。
対応のさせ方については簡単で、たった一か所変更するだけでOKのようだ。
方法については www.kfk-kikaku.com/sample1 の方に書いているので参考にしていただきたい。
今まで何の問題もなく動いていたのに、
ページを開くと”Internal Server Error”という見出しのあとに
数行の英文が表示されるのみ。
こんな経験はありませんか？
まったくの個人的な解決法ではありますが、
先ず確認すべきことは
.plファイルのパスが適切に指定されているかどうかです。
メインのCGIファイルと同一フォルダにある必要があると書いている人がいますが、
パスが正しく書かれていれば親フォルダでも問題ないようです。
ただし、同一フォルダに置く場合はファイル名だけを書くのではなく”./xxx.pl”とします。
サーバー運営側の説明によると、
スクリプトに「print “Content-type: text/html\n\n”;」の一文が抜けている可能性がある
ということですが、これは基本的なことなので、
プログラムを書く人も忘れないと思うのですが如何でしょうか。
しかし、前述の解決策で問題が解消されないときは確認してみるべきでしょう。
ファイルの属性を疑えという意見もありますが、今まで動いていたのであれば
属性に問題があるとは考えにくいと思います。
ここまで説明した方法でも直らない場合、次に試してみるべきことは
「jcode.pl」を「jacode.pl」に変えてみる。
「jacode.pl」は自分で調べてダウンロードしてください。
これでもダメならあとはシンタックスエラーを疑っても良いのではないでしょうか。
エラーのチェックは、Kent Webさんが公開している「Perl Checker」を使うと簡単にできます。
以上、実際これらの方法で動くようになったので、やってみる価値はあると思います。
↓2022/05/16 加筆
“Internal Server Error”とならずにページが表示されたとしても
CGIが機能していない場合があります。
原因のひとつとして考えられるのは、Perlのパスです。
!#usr/local/bin/perl となっていなければならないところが、
!#usr/bin/perl となっていないか確認してください。
例え文法的に合っていたとしても、ちゃんと動かない場合があるようです。
このような場合は一度コメント一覧を表示して、
「返信先」の列に「添付ファイルのページを表示」というリンクがないか確認します。
ある場合は、この「添付ファイルのページ」のコメント欄からコメントしているのです。
記事に画像を貼り付けないのなら、この手のスパムは受けないとも言えます。
対策としては、添付ファイルのページにコメント欄を表示させないようにすることや
添付ファイルのページにアクセスさせないようにすることなどが挙げられます。
Windows 10からWindows 11へアップデートできるか調べるアプリを実行すると、
問題ない場合は「このPCはWindows 11の要件を満たしています。」というタイトルの下に
表示される最初のメッセージです。
問題ありの場合はその理由を教えてくれるのだが、具体的な解決策が提示されていないように思う。
筆者のPCはセキュアブートが有効になっていないのがNGで、
ただ単にBIOSを弄ってそれを有効にすれば良いという訳にはいかなかった。
色々と調べて最終的に問題解決に至った方策は、BIOSのモードをレガシィからUEFIに変換するというものであった。
これらを変換するコマンドは最初からWindows 10には備わっていて、やり方もそんなに敷居が高くない。
変換にかかる時間も驚くほど短い。
セキュアブートを有効にできなくて困っている方は、この方法を一度試してみては如何でしょうか。
OSそのものやアプリケーションソフトおよびそれら関連のデータを保ちつつ作業ができます。
これからWebデザインをする場合はfont-familyの指定はより注意が必要です。
どうしてかというと、CSSで普通にフォントを指定してもそれが反映されない場合があるからです。
同じfont-sizeでもフォントによって微妙に大きさが違うため、
ページ全体のレイアウトに影響してくる場合があります。
このことを知っていないと、Chrome以外のブラウザで正常に見えていたとしても
Chromeで見たときにレイアウトが崩れていて愕然とすることになります。
これからはChrome主体でデザインしていかなければならないと言えるかもしれません。
Googleとしては自社のWebフォントを使わせたいのでしょう。
しかしながら、どうしてもWebフォントにはないものを使いたいときは
サーバーにフォントのファイルをアップして、それを読み込ませるという方法があります。
事実、このブログでもその方法を採用しています。
デメリットとしては、読み込みに少し時間がかかること。
それ以外にサイズが微妙に違うのと文字自体の質が少し荒い気がします。
これらの原因は恐らくサイズを圧縮しているからではないかと思われます。
W3Cで策定したものを効かなくするGoogleのやり方はデザイナー泣かせですね。
2020年と2021年のスポーツの日は移動しているので、
10月の第2月曜日となっていたら
それは間違いです。
dayChecker.jsの10月のところを
条件分岐で2020年と2021年を除外する必要があります。
祝日が変更になると、こんなにも大変なことになるとは・・・。
まあ、その分勉強になるんですけどね。
“dayChecker.js”を変更して正しく表示されていたのは先月までで、
今月になって確認したら「山の日」が11日になっていました。
理由は明らかにスクリプトにミスがあったからです。
“dayChecker.js”をここから持っていった方がいらっしゃたら、
即正しいと思われるもの（ここのは当てにならなりません）に変更してください。
というか、元来”dayChecker.js”に関する記事は書くべきではありませんでした。
他所からスクリプトを持ってきて、必要と思われる個所を書き加えて
表示させていたわけだから、自慢げに記事を書いたことを反省しています。
来年からは「海の日」「スポーツの日」「山の日」はまた元に戻るので、
その辺もスクリプトは正確でないといけません。
くれぐれもご注意なさってください。
小粋空間さんのところで配布されているリアルタイムカレンダーというプラグインを使っておられる方は“dayChecker.js”を変更する必要があります。
どうしてかというと、天皇誕生日やオリンピックイヤーに伴う休日の設定などが適切ではないためです。事実、変更していない場合は、今月の23日は平日表示になっているはずです。逆に去年の12月のカレンダーを表示してみると、23日が休日になっています。
五輪が延期になったせいで、今年のカレンダーは誤表記のものが結構あるようです。勘違いして平日なのに欠勤しないように注意しなければなりません。
まさかワードプレスのカレンダーを見て出勤するかどうかを決めている人はいないと思いますが、あとで恨まれることにならないようにしておきましょう。
来年になったら、スポーツの日などはまた元に戻るのでしょうか。もしそうなら、またデータを変更する必要があるんですね。