4017B
フォーラムへの返信
-
フォーラム: 使い方全般
返信が含まれるトピック: ブログページだけが3重に表示されている。＞http://okameinkonosu.com/blog/?page_id=956
吐き出されているHTMLソースを見た所…何というか普通に「同じページを3回分」吐き出されてますね。ですので挙動というか、表示のされ方としては全く正常です。この情報だけだと自分には根本原因は分りかねますが、推測でも良いのなら当てずっぽうでお答えしますが…恐らくはサイドバーに貼り付けているウィジェットの「タグクラウド」がおかしいみたいです？？最後のタグ（鳴き声）の末尾辺りから、また先頭にループする様な形でHTMLコードが書き出されていますので。
試しにこのウィジェットの使用を停止してみて、表示がどうなるか確認して見て下さい。
フォーラム: 使い方全般
返信が含まれるトピック: テーブルタグの色が無視されスタイルシートで指定した定義が反映されな＞
<table bgcolor="#ffff00">～が無視される
昨今の代表的なブラウザの仕様では、CSS（スタイルシート）が設定されている場合は、基本的にそちらの設定が優先されます。ですのでHTMLタグ内にいくら色設定とかを書き込んでも無視されます。どうしても背景色を設定したいのであれば、
<table style="background-color:#ffff00;">
～と書き直してみて下さい。＞スタイルシートのフォントサイズが反映されない
この場合はCaseByCaseですが、CSS（スタイルシート）の書き方が悪いというか最適でないというか…。div.post-headline h1 { font-size: 55px; color: green; }～としてみて下さい。この場合、テーマが元から持っているCSSの設定におそらく
h1に対するフォント設定がなされており、それが優先されているためです（一番内側に位置するh1タグの設定が最優先）。自前のCSS（スタイルシート）が反映されない原因のほとんどは、知らない部分に設定されているWordPress本体かテーマなどが元から持っているCSSの設定の方が優先されているからです。人によっては前述の様な例の場合、CSSの記述の末尾に
!importantを付記する様に指導する人も多いかもしれませんが。自分は最後の手段だと思っていますので、あまりお奨めしません（その人がCSSを良く理解してからならOKです）。フォーラム: 使い方全般
返信が含まれるトピック: 自作ショートコードの実行されるタイミングがおかしいすいません。自己解決しました！
先のコードを
function my_shortCodeTest() { $myOutput = "<p>イイイイイ</p>\n"; return $myOutput; }～と言う風に直したら、ちゃんと本文に書き込んだ通りの順番で実行されました。
どうやら
printf()とかは呼び出された瞬間に、直ちに実行され結果が出力されるみたいですね。自分が非常に初歩的な勘違いをしていたみたいです…。フォーラム: 使い方全般
返信が含まれるトピック: ホームを固定ページとしてフロントページにしたいとりあえず
＞WordPressのトップページを変更 – textdrop
この記事が少し参考になるんじゃないかな？フォーラム: 使い方全般
返信が含まれるトピック: 3.0.1にしたら nextpage （ページ分割）が動かなくなった＞テーマ自体が3.0.1非対応
WordPressのテーマはデザインだけを変えてる訳じゃないので、ままそういう事もあります。その辺の特性がMovableType派の人に嫌われる理由でしょうか…？とりあえず原因特定が先決です。が…原因が特定出来ても、必ずしも不具合の改善が約束される訳では無いので、その辺はご理解と、それに最終的にはWordPress本体自体のver.をダウングレードする必要があるかもと言う事を肝に銘じて置いて下さい。
フォーラム: 使い方全般
返信が含まれるトピック: 3.0.1にしたら nextpage （ページ分割）が動かなくなったサイト運用中とのことですが、それは何か商用サイトの様な物ですか？だとしたらいきなり停止させるのは難しいかもしれませんが…個人サイトなら、1～2日程度のサイト停止は問題にならないと思います。とにかく今、問題が発生しており、それを速やかに解決する事を優先した方が良いと思います。
ただ…自分が1つ思い当たるのは、何か意図せずに「.htaccess」が新規に作成されてるのかも？？とりあえずFTPソフトなどでサイト全体を見回し、自分がUpした覚えのない「.htaccess」とか不審なファイルは無いか確認した方が良いかもです。その他に確認すべき点は、今現在、表示されているページを他のブラウザで動作確認。可能ならネット喫茶などの全く別の環境から見てみるとか。
とりあえず問題発生時の確認手順を書いてみましたので、参考にして調べてみて下さい。
＞STEP.1
WordPress本体は3.0.1のままで、
・全てのプラグインを停止
・テーマをDefaultに戻す
～以上の2つを必ず実行して、様子を見て下さい。
その結果、
・正常に動作 → STEP.2へ
・異常に動作 → WordPress本体がおかしい可能性！＞STEP.2
テーマを海外の物に変更。
その結果、
・正常に動作 → STEP.3へ
・異常に動作 → そのテーマがWordPress3.0.1に対応していない？＞STEP.3
一旦、テーマをDefaultに戻します。その後、プラグインを1個づつ有効化してみる。
尚、有効化は“1個づつ”が原則です！1個有効化して確認したら、それは停止して次のプラグインを有効化して様子を見ます。面倒ですが、必ずそうしないと原因が永久に分りません。
その結果、
・全て正常に動作 → STEP.4へ
・異常に動作 → そのプラグインがWordPress3.0.1に対応していない？＞STEP.4
テーマを海外の物に変更し、再度STEP.3の手順を始めから行い様子を見ます（あくまでも“1個づつ”有効化です）。
その結果、
・全て正常に動作 → STEP.5へ
・異常に動作 → そのプラグインとテーマに相性問題あり？＞STEP.5
テーマは海外の物のままで。再度STEP.3と同様の確認を行いますが、今度は1個づつ有効化していきながら、プラグインの有効化はそのままにして置きます。つまり最終的には全てのプラグインを有効化にします。
その結果、
・異常に動作 → そのプラグインとプラグインに競合問題あり？フォーラム: 使い方全般
返信が含まれるトピック: ページに挿入した表の大きさを調整したい使用しているテーマにもよりますが、WordPressの基本仕様だと表組みも含めて見た目のデザインは全てCSS（スタイルシート）で行う事が前提になってます。
とりあえずの解決策は、
<table style="width:25%; height:25%; border:2px solid #000080;"> ＊＊＊＊＊＊ </table>～みたいにHTMLを書き換えてみて下さい。
それで全く改善が見られないのなら、テーマのCSSファイルを直に編集しないと難しいです。CSSの事はチンプンカンプンというのであれば、さらに難しいです。P.S.
HTMLタグに直に書かれた設定よりも、CSS（スタイルシート）の設定の方が基本的には優先されます。HTMLの方にいくら「WIDTH=”25%”」とか書いても変化無いのはそのためです。フォーラム: 使い方全般
返信が含まれるトピック: 投稿記事の自動置換処理をカスタマイズしたい＞データベース
実際にDBを確認した訳ではありませんが。バックアップでXMLを書き出したら、中身の文書がテキストエリアに入力したまま（多段改行含む）の状態で保存されてましたので、そう思いました。まあ確かに仰る通り、キャッシュがあるので必ずしも毎回負担が掛かってる訳では無いと思いますが…何となく気持ちが悪かったので(笑)。どっちが良いのかは、最終的には各人の好みなんでしょうね。とりあえずWordPressがDefaultでそうなっているのなら、自分としてはそれに従うつもりです。
＞コメント欄に置換処理
自分もまだWordPressを触り始めて2ヶ月少々ですので、まだまだ基本的な事でも分ってない部分が多いと感じました。最初からピーキーなカスタマイズにあれこれ手を出すべきじゃないかなと最近は少し自省してます。今後、もう暫くはWordPressの基本性能をもっと使い倒してから、より高度なカスタマイズに挑戦していこうと思います。コメント欄の置換処理に関しては、もう少し自分でTry＆Errorを繰り返してから、もっと問題点を自分の中で明確化出来たら改めて質問し直しますね。
nobitaさんには色々とご助言、ありがとうございました。
フォーラム: 使い方全般
返信が含まれるトピック: サイト全体の最終更新日のタイムゾーン設定について＞タイムゾーン自体は「UTC」に固定
正しい方法かどうかは分りませんが、
date( 'Y/m/d. H:i', strtotime(get_lastpostmodified('blog')) );
～の日付フォーマットの部分を ‘Y/m/d. H:i T‘ とすればタイムゾーンが表示されます。＞date_default_timezone_setがなければUTC固定
前述の通り、自分はサーバやWordPress本体の設定の方は、個別のBlog（webサイト）の事情で弄るべきではないと考えますので。WordPress本体がUTC固定と考えているのなら、その考え方に従います。フォーラム: 使い方全般
返信が含まれるトピック: 投稿記事の自動置換処理をカスタマイズしたいサンプルコードを例にして自前の関数を作って適用してみましたが、結果は芳しくありません。
<!--more-->や<!--nextpage-->などのWordPress専用のショートコードが可笑しくなってしまいました（何故かNextGenGalleryのショートコードは影響を受けない）。きちんと自分が思い描く置換処理を適用させようと思ったら、かなり大がかりな関数を作らないと行けない様な気がして来ました。もう少しWordPress関数とPHPの勉強をしないと難しいみたいです。解決ではありませんが、一旦、この件に関して凍結したいと思います。
P.S.
で…今初めて思ったんですが。WordPressってDBに書き込まれる本文データとかとは、特に置換処理とかせずに平のテキストのままで書き込まれてるんですか？the_content()と言うのはDBから記事本文を呼び出す関数ですよね？自分としてはそうじゃなくて、DBに書き込まれる前に置換処理を施したいんですが、そういう考え方自体が間違ってるんでしょうか？読み込みよりも、書き込みの方が圧倒的に回数的には少ないので、書き込み時により複雑な処理を施し、回数の多い読み込み時には出来るだけ最小限度の処理で済ませる～と言うのは異端なのでしょうか？それにコメント欄に上手い具合に置換処理を適用させる方法も分りません。
コメント欄の表示には
get_comment_text()やcomment_text()～辺りが関わっているんじゃないかと推測して弄ってみましたが…。基本的には無反応、時たま変な￥が表示される？？また吐き出されたHTMLソースを見たら、記事本文中に含まれるHTMLタグと思しき箇所が全部抜き出されて、属性値を持ってる場合は「”」が一旦、「￥”」へ置換されてるみたいです？？
どこかにWordPressの書き込まれたデータが、どういう経路（関数）を辿ってDBに書き込まれ、また呼び出されてくるのか解説したwebサイトなど無いものでしょうか？
フォーラム: 使い方全般
返信が含まれるトピック: サイト全体の最終更新日のタイムゾーン設定についてbonoさん、わざわざ追加回答ありがとうございます。
＞
get_lastpostmodified('blog')
確かに引数に'blog'を渡しても大丈夫みたいですね。前述のソースのstrtotime('+9 hour '. get_lastpostmodified())の部分を、strtotime(get_lastpostmodified('blog'))～と改変してみて実験してみました所、全く同じ結果になりました。少しでもコードは短く簡潔な方が好みなので、コレで行こうと思います。
P.S.
しかし相変わらずタイムゾーン自体は「UTC」に固定されたままです。WordPressの管理画面で変更したタイムゾーンはあくまでも表向きの結果表示のみで。実質、WordPress内ではUTCで統一管理されてるんですかね？フォーラム: 使い方全般
返信が含まれるトピック: サイト全体の最終更新日のタイムゾーン設定について色々とありがとうございます。
自分がnobitaさん提示のサンプルコードを実験した結果ですが…function my_lastPostModified() { $lastModTime = mysql2date('Y/m/d. H:i T', get_lastpostmodified(), false); printf( $lastModTime ); } echo my_lastPostModified(); echo date("Ymd h:i:s",strtotime(get_lastpostmodified())); echo date("Ymd h:i:s",strtotime('+9 hour '.get_lastpostmodified())); echo date("Ymd h:i:s",strtotime(get_lastpostmodified())); echo date_i18n( "Y m d G i",strtotime(get_lastpostmodified())); echo get_option( 'gmt_offset' ); ＞date_default_timezone_set('Asia/Tokyo'); 有り 2010/08/28. 21:09 JST 20100828 09:09:43 20100829 06:09:43 20100828 09:09:43 2010 08 28 21 09 9 ＞date_default_timezone_set('Asia/Tokyo'); 無し 2010/08/28. 21:09 UTC 20100828 09:09:43 20100829 06:09:43 20100828 09:09:43 2010 08 28 21 09 9～以上の様になりました。
自分が得たい結果は
strtotime('+9 hour '.get_lastpostmodified())でしか得られないみたいです。またdate_default_timezone_set('Asia/Tokyo')をセットしても、結果に表示されるタイムゾーン自体は「JST」となっているのに、実際に表示されてる時間はUTCなのも謎です？以上の事を踏まえまして…
function my_lastPostModified() { $lastModTime = date( 'Y/m/d. H:i', strtotime('+9 hour '. get_lastpostmodified()) ); printf( $lastModTime ); }～というコードに書き直しました。自分的には行数も減ってスマートになったんじゃないかと思っています。また
date_default_timezone_set()は、あんまりローカル側からタイムゾーンを弄るのは如何な物かという判断から使わない方針にしました（というか結果が同じだし…）。とりあえずコードの量を減らして見た目も簡素にするという目的は達成出来ましたので、これでスレッドを締めさせて貰います。タイムゾーンや時間設定に関するスレは多数有りますが、意外と
get_lastpostmodified()に関する記述は少ない様だったので。ここでの議論が少しでも誰かの役に立てば幸いです。皆様もお付き合いありがとうございました。フォーラム: 使い方全般
返信が含まれるトピック: サイト全体の最終更新日のタイムゾーン設定について早速の回答、ありがとうございます。
kvexさんの方法だと、単純にUTC（GMT）の時間に「+09:00」という文字列が付加されて表示されます。
nobitaさん提示の方法も既に実験済みでして。結果はやはりUTC（GMT）の時間が表示されます。お二方の環境ではどの様な結果が得られているのでしょうか？
結果芳しくないのは、もしかしてサーバ環境に依存しているのでしょうか？？何故か自分の環境だと、
date_default_timezone_set()とdate_default_timezone_get()がうまく働いてない感じです。P.S.
get_lastpostmodified()自体にタイムゾーンのオプションが元々、2つしか無かったとは盲点でした…！
しかし自分がタイムゾーンに'server'を指定した時にはUTCで表示されました。
サーバ自体のタイムゾーンは、ErrorLog等で吐き出されている分で確認する限りには日本時間の様なのですが…？？引き続き何か代替方法などがありましたら、手法も
get_lastpostmodified()には拘りませんので、ご教授願います。フォーラム: 使い方全般
返信が含まれるトピック: 画像に強制的に表示される枠線を消したい解決しました！
自分はFireFoxは持ってないのでChromeのデベロッパーツールで調べてみたら。
該当するとおぼしき部分のCSSが「inline stylesheet」となっており。確かに吐き出されているHTMLのソースを良く確認して見た所、どうやらWordPress側で自動的にドキュメント内にCSSを書き込んでいたみたいです。テーマ内にあった「header.php」というファイルを見てみたら、
<?php $options = get_option(‘pb_options’); if($options[‘image_style’]) { ?>
<style type=”text/css”>
.post img, .post a img { border:1px solid #222; padding:5px; margin:0; background:#555; }
.post a:hover img { border:1px solid #849ca0; background:#59847d; }
.post img.wp-smiley { border:0px; padding:0px; margin:0px; background:none; }
</style>
<?php }; ?>～という記述が<head>～</head>内にあります。これによって記事内の全ての画像（imgタグ）に強制的に枠線の様な物が表示されていたみたいです。しかし指定が画像より一回り大きい背景色で擬似的に表現していたため、CSSによる「border:none;」とかの書き換えで消す事が出来てなかった様です。
一番最初に全くのDefaultのままの時に初めて設定画面などを開いた時には。確かどこかに「画像に枠線を表示する」という項目が有った様に思っていたのですが。その後、別のテーマをインストール適用した後ではそういった設定項目自体が一切見当たらないので、単に今まで自分の記憶違いだと思っていました。
しかし先ほどまた別のテーマ「wp.Vicuna 2.0.3」を適用し。再度、元のテーマ「PianoBlack 2.3」に戻したところ。急にテーマ固有のオプション設定項目の中に「投稿画像に枠線を表示する」という設定が出て来る様になりました。このチェックを外したら、無事に枠線無しの画像に戻りました。
以上の事から特定のテーマ（PianoBlack、monochrome）を適用した事に於ける不具合だと思われます。
再現性があるかどうか分りませんが。どの様な順番でテーマを適用し、設定を弄れば不具合が発生するのか検証して、レポートを製作者に報告して終わりにしたいと思います。