フォーラムへの返信

14件の返信を表示中 - 1 - 14件目 (全14件中)
  • フォーラム: プラグイン
    返信が含まれるトピック: WP over networkの新着日付について

    あああ。もしや WordPress のオプションの日付形式に関わらずに、’Y年m月d日’ としたいのかな? であれば…

    $the_date = mysql2date( 'Y年m月d日', $post->post_date );

    として、

    <span class="post-date wponw-post-date"><?php echo apply_filters( 'get_the_date', $the_date ) ?></span>

    ですね。

    フォーラム: プラグイン
    返信が含まれるトピック: WP over networkの新着日付について

    cnoise さんフォローありがとうございます。
    次でも良いかも知れません(ちょっとブランクがあって…はっきりしませんが。 (; ^ω^))

    <span class=”post-date wponw-post-date”><?php echo apply_filters( ‘get_the_date’, $the_date ) ?></span>

    フォーラム: プラグイン
    返信が含まれるトピック: WP over networkの新着日付について

    プラグインのコードを貼られてるように見えますが、これらはおそらく関係ないですね。
    その問題になっている箇所のテンプレートの部分を貼っていただけたら、何かアドバイスできるかも知れません。

    フォーラム: 使い方全般
    返信が含まれるトピック: functions.phpをアップロードすると

    なるほどー。BOM かー。考え及びませんでした。

    <?php の前に本当に一切なにも無いのであれば、Hinaloe さんご指摘の BOM の可能性高いですね。次の過去ログは参考になりませんでしょうか。

    http://ja.forums.wordpress.org/topic/1111?replies=3

    フォーラム: 使い方全般
    返信が含まれるトピック: functions.phpをアップロードすると

    > 自分で調べてみて、空白の改行が…という記事も読み実行してみたのですがダメでした。

    着目したポイントは正解ですが、たぶん何かを見過ごしたのだと思います。

    エラーメッセージにあるように、

    /home/usuge9life/usuge9life.wp.xdomain.jp/public_html/wp-content/themes/usuge_site/functions.php:1

    functions.php の最初の1行目に何かありませんかね?
    もし分からないようであれば、最初の何行かで良いので、ここにコードを貼ってみてください。

    「$cat_now がオブジェクトではない」といわれていますが、85行目、86 行目を見ると明らかに 87 行目の $cat_now は null になっているようです。

    意図どおりの意味のコードになっているか、83 〜 86 行目について見直しみてみてください。

    フォーラム: 使い方全般
    返信が含まれるトピック: WordPressを移行したいhtml,cakephp…etc

    まず技術的な観点から結論を言うと、致命的な問題はないでしょう。出来ます。
    このレベルの移行に対応できるエンジニアさんであれば、画像ファイルの件も全く問題にはならないでしょう(もしかして多少大きな問題が出る可能性があるとしたら、データベースに保存されたユーザーさんのパスワードですが、まぁ、これはどんな場合でもある程度は致し方ないですね)

    ただ、もちろん移行にはコストが掛かります。そのコストが dkknmr さんの、あるいはそのサイトの関係者の皆さんの考えてらっしゃる範囲かどうかは、もしかしたら微妙かも知れませんので、この点には留意しておいた方が良いかとは思いますよ!

    §

    あと、少し観点は違いますが、「大規模なサイトに成長した」あとでも、WordPress での運用は可能かも知れません。色々なケースがあるので、一概には言えません。WordPress の基本的な仕組みは確かに高性能ではありませんが、補う手法もたくさんあります。また、CakePHP で制作されたアプリケーションが常に高速とも限りません。それはエンジニアの力量によります。

    要は、求められる性能に対して、システムのライフサイクルを考慮した上で、最小のコストで対応できることが求められるはずです。この観点においては、端的に WordPress < CakePHP という図式は成り立ちませんので、それが必要になった時に、周りの信頼できるエンジニアさんに相談されるのが良いかと思いますー。

    端的に製品で比較できないこと、覚えておいてもらえたらと思います。

    こんばんわー。
    WordPress には色んなプラグインがありますねー (*’-‘*)。面白そうだったのでプラグインをインストールして調べてみました。関数1個だけの男前なプラグインですね。フックなどもなかったので、自力で、ちょっぴり力技で、なんとかするしか無さそうですね。

    元の images 関数の第5引数で echo せず値を取れるようです。これを利用してラッパー関数を用意してみました。functions.php などに次のコードを書いてください。

    function get_images_as_array($num=1, $width=null, $height=null, $class='alignleft', $permalink=true) {
    	$images = images($num, $width, $height, $class, $permalink, false);
    	if ($permalink) {
    		return preg_split('#(?<=</a>)(?!$)#', $images);
    	} else {
    		return preg_split('#(?<=/>)(?!$)#', $images);
    	}
    }

    この関数は、images 関数で得られる画像のリストを配列として取得する関数です。
    第5引数が無い以外は、images 関数と同じ引数リストを取ります。
    プラグインの images 関数から得られた HTML の文字列を、正規表現で分割しています。あまり凝った正規表現ではありませんが、今の要件は満たせると思います。

    配列が返るので、そのままではお望みの動作ではありませんが、テンプレートの中では、次のようにして利用できると思います。

    <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
    <article><?php echo implode("</article>\n<article>", get_images_as_array($num='all')); ?></article>
    <?php
    endwhile;
    endif;
    ?>

    上手くいったら幸いです!

    フォーラム: 使い方全般
    返信が含まれるトピック: 一般サイトの分岐

    少し補足しておきます。

    ■管理画面での設定

    1)WP では、トップページとして、固定ページを指定でき、指定した固定ページの内容が、トップページとして表示される。

    2)WPでは、投稿ページ(いわゆるブログの一覧ぺージ)として、固定ページを指定できます。ただし、指定した固定ページの内容が表示されるわけではなく、指定した固定ページに設定されているパーマリンクが、投稿ページ(ブログ一覧)の URL になるだけです。固定ページの内容は通常無視されます。「投稿ページのURLを決める為に、固定ページを指定する」ぐらいの理解が簡単で良いかと思います。

    ※ここまで、テンプレートファイル(*.php)は出てきませんね。このように、管理画面からの設定だけで、トップページとして任意の内容(固定ページの内容)を表示させて、またトップページで投稿の一覧が表示できなくなった代わりとして、別のURLを指定することができます。

    ※テンプレートファイルは、あくまでも、決められたルールに基づいて、特定のページの外観をカスタマイズする為に用いるものです。サイトの構成を、テンプレートファイルが変更できるわけではありません。

    ■テンプレートファイルでは何をする?

    テンプレートファイルはあくまでも特定のページの外観を変更するために用いるものです。上記のようにしてサイトのトップページの構成を設定した後で、もし、個別のページの外観をカスタマイズしたい時には、テンプレートファイルを準備することになります。

    font-page.php は、トップページ用のテンプレートです。mogetan さんは、トップページの外観を変更されたいと推察できますので、home.php ではなく、front-page.php を作成して編集する必要があります。

    home.php は、投稿ページ(ブログ一覧)用のテンプレートです。ここまでの mogetan さんの説明を読む限り、投稿ページの表示には、index.php を使いたいということのように読めましたので、home.php があるとそちらが表示されるので、意図通りになりません。そこで、home.php をテーマに含めないようにと、上では説明してみました。

    フォーラム: 使い方全般
    返信が含まれるトピック: 一般サイトの分岐

    ちょっとまだまだ手探り感が強いのですが、返信させていただきます。
    はっきりと状況読めていないので、外していたらすみません。

    §

    > TOPページをhome.phpで作成しているため、フロントページの選択に
    > 入っておりませんでした。TOPページも固定ページで作成して、
    > テンプレートをつけてあげるほうがよいのでしょうか?

    おそらく…ですが、WordPress のトップページ(front-page)に関する設定と、テンプレートファイルの位置づけが、ごっちゃになってしまっているように感じます。

    home.php など、テンプレートファイルのことは一旦忘れて、とりあえず次の手順をやってみてください(後で元に戻せるように、適当にバックアップなどしてくださいね)。

    1)管理画面で、2つの「固定ページ」を新規作成してください。
     ・1つ目は、「トップページ」という名前にしましょう。
     ・2つ目は、「ブログ」というという名前にしましょう。

    2)管理画面で、[設定] > [表示設定] を開きます。

    3)[フロントページの表示] のラジオボタンで「固定ページ (以下を選択)」を選択します。

    4)その下の2つのドロップダウンを設定します。
     ・[フロントページ] には、先ほど作成した「トップページ」を選びます
     ・[投稿ページ] には、先ほど作成した「ブログ」を選びます

    ↑ここまでは php のテンプレートファイルは関係無いので、考えが混ざらないように注意してください。
    ただ、↓次はテンプレートファイルが登場します。良く読んで対応してみてください。
    なお、「home.php」を、トップページ用のテンプレートファイルとして準備しているだろう、という前提で回答しています。

    5)テンプレートのフォルダを開き、「home.php」のファイル名を「front-page.php」としてください。home.php はテーマフォルダに存在しないようにしてください。(注1)

    (注1)トップページ用のテンプレートは、「front-page.php」が正解です。「home.php」は投稿記事の一覧用のテンプレートファイルになります。詳しくは http://wpdocs.sourceforge.jp/テンプレート階層 を参照ください。

    フォーラム: 使い方全般
    返信が含まれるトピック: 一般サイトの分岐

    よくわからないながらなんですが、返信してみます。
    外していたらスルーしてください。

    §

    テンプレートの php ファイルを準備されたご説明をされていますが、まず管理画面で設定はされましたでしょうか?

    もしまだの場合、管理画面に管理者でログインし、[設定] > [表示設定] > [フロントページの表示] の設定を行います。
    ここで、「固定ページ」を選択し、「フロントページ」「投稿ページ」それぞれに適用したい固定ページを指定します。
    「フロントページ」に指定した固定ページの内容が、トップページに表示されます。
    「投稿ページ」に指定した固定ページのパーマリンクが、ブログ一覧ページの URL になります。

    テンプレートの php ファイルや、カスタムテンプレートの指定は、この設定の後、それぞれのページが実際に表示に利用するテンプレートに影響するものですので、まずは上の設定をご確認ください。

    §

    その他の質問については、一度に話すとややこしくなりそうなので、順番にまいりましょう。
    トピック間違いについては、次から気をつけたら良いかと僕は思ってしまうのですが、どなたかフォロー頂けたらと思います。

    もにんぐですー。
    主に2つ理由があります。

    1つは、qtransextra::save_original_data で行う処理は、the_posts フィルタで qtransrate が現在の言語以外のデータを整理してしまう前に、多言語混在のデータを保存しておくことです。
    しかし、ここで、qtransrate は管理画面において言語を整理しません。伴って管理画面で qtransextra::save_original_data は実行しなくても良いかな?と判断しました。

    もう1つは、要件を見てフロントサイトでの表示の為の要望だと想像しました。このことから、管理画面での実行は不要だろう、とも考えました。

    以上2点だったと思いますー。

    こんばんわです。

    手元に qtransrate のコードがちょうどあったので、勉強がてらに考えてみました。
    qTranslate が the_posts フィルタでどーんとデータ内の言語データを整理してしまうので、思いのほか大掛かりなコードになりました。長くなったので、そのまま記載しておきます。

    ただもっと良いやり方あるかも知れないので、他の方からフォローがあれば嬉しいです。

    以下のコードを、functions.php に書いてから、テンプレート中では、<?php qtransextra::the_title( 'en' ) ?> のように使ってください。

    add_action( 'init', 'qtransextra::init' );
    
    class qtransextra
    {
    	private static $original_posts_data = array();
    
    	public static function init() {
    		if ( is_admin() ) {
    			return;
    		}
    		add_filter( 'the_posts', 'qtransextra::save_original_data', 0 );
    	}
    
    	public static function save_original_data( $posts ) {
    		if ( is_array( $posts ) ) {
    			foreach ( $posts as $post ) {
    				self::$original_posts_data[$post->ID] = (object) array(
    					'post_title' => $post->post_title,
    				);
    			}
    		}
    		return $posts;
    	}
    
    	public static function get_the_title( $lang, $post = 0 ) {
    		global $q_config;
    
    		$post = get_post( $post );
    
    		$actual_lang = $q_config['language'];
    		$actual_post_title = $post->post_title;
    
    		$q_config['language'] = $lang;
    		$post->post_title = self::$original_posts_data[$post->ID]->post_title;
    
    		$title = get_the_title();
    
    		$q_config['language'] = $actual_lang;
    		$post->post_title = $actual_post_title;
    
    		return $title;
    	}
    
    	public static function the_title( $lang, $before = '', $after = '', $echo = true ) {
    
    		$title = self::get_the_title( $lang );
    
    		if ( strlen( $title ) == 0 )
    			return;
    		$title = $before . $title . $after;
    		if ( $echo )
    			echo $title;
    		else
    			return $title;
    	}
    }
    フォーラム: 使い方全般
    返信が含まれるトピック: wp_terms と wp_term_taxonomy が分かれている理由
    トピック投稿者 yuka2py

    (@yuka2py)

    jim912さん、nobita さん、

    ご回答をありがとうございました!!!!!
    いずれのご回答についても、その可能性があることは考えていました。
    ただ、その必然性が良く分からないでいます。
    つまり、それが実際に発生する状況、そしてそのメリットが想像できないでいます。

    jim912 wrote:
    > たとえば、リンクで未分類というリンクカテゴリーを作ると、termsの未分類を共有し、
    > term_taxonomyでは、categoryとlink_cateoryと異なるレコードとなります。

    ご呈示いただい↑の例ですが、実際にそうなりますよね。
    ただ、そうなるメリット … つまり、terms の1つのレコードを、異なる term_taxonomy で共用するメリット、あるいは必然性が感じられないでいます…。
    つまり、term_taxonomy が slug も name も持つ方が合理的ではないか?と思っています。

    僕なんかの想像では、その理由としては name や slug の正規化目的ぐらいしか思いつきませんでした。
    ただ、terms において一般に想像される範囲のレコード数と name/slug のデータ量、そして terms と term_taxonomy の join コスト、またそれに伴うソフトウェアの複雑性の増加などを考え合わせると、この場面で正規化を目的とするには少々バランスが悪いような…つまり、あまり僕には合理性が感じられないなぁー、という印象でいます。

    ただ、この「正規化目的には合理性を感じにくい」というのはあくまでも僕の感想なので「いやこれは正規化目的ですよ」と言われればそれはそれで納得できます。

    しかしもっと別の観点や、ユースケースが想定されていたのかな?とも思います。それは例えば、「terms を共有することで、なにがしかの検索の際に便利である」とか、「そういうスキーマになっていないと●●の機能が実現できないなど」何か理由があるのかな?、と。ということで、今回の質問をさせて頂いた次第です。

    めんどくさい質問になっているような気がしますが、よろしくお願いいたします!

14件の返信を表示中 - 1 - 14件目 (全14件中)