フォーラムへの返信

15件の返信を表示中 - 1 - 15件目 (全75件中)
  • フォーラム: 使い方全般
    返信が含まれるトピック: author(著者)ページの月間アーカイブ

    URLが https://hoge.jp/author/ユーザー名/2019/05/ の場合はauthor.phpではなく、
    archive.phpで対応したいということでしょうか。

    テーマ内のテンプレートには優先度があり、arcive.phpよりもauthor.phpが高くなります。

    現状どのようなauthor.phpとarchive.phpがどのような内容になっているのかわかりませんが、
    author.phpを使用されているのであればauthor.php内で処理を切り分ける方が合理的だと思います。

    1.現状のarchive.phpで https://hoge.jp/author/ユーザー名/2019/05/ の際に
    コンテンツ部分を出力しているコードをauthor-date.phpに切り出す。
    2.現状のauthor.phpのコンテンツ部分を出力しているコードを author-common.php に
    切り出す。
    3.author.phpのコンテンツ部分出力部分は、次のようなコードで処理を振り分ける。

    if ( is_date() ) {
      get_template_part( 'author', 'date' );  // author-date.phpを読み込む
    } else {
      get_template_part( 'author', 'common' ); // author-common.phpを読み込む
    }
    フォーラム: 使い方全般
    返信が含まれるトピック: author(著者)ページの月間アーカイブ

    テーマのfunctions.phpに次のような記述を追加することでおおむね希望通りになるかと思います。

    function custom_rewrite_rules() {
        add_rewrite_rule( '^author/([^/]+)/([0-9]{4})/([0-9]{1,2})/?$',
            'index.php?author_name=$matches[1]&year=$matches[2]&monthnum=$matches[3]',
            'top' );
    }
    add_action( 'init', 'custom_rewrite_rules' );
    

    なおこのコードだけですとルールが保存されないので、「設定」-「パーマリンク」で
    「変更を保存」ボタンを押す必要があります。

    add_rewrite_rule関数の詳しい使い方はcodexなどでご確認ください。

    WordPressではリクエストURIに応じたページを表示する際に、まずリクエストURIの
    パターンを調べ、そのパターンに応じてカテゴリーやタグ、ページを検索しています。

    > http://example.com/category/hoge/foo/ → fooの記事一覧が表示される
    リクエストURIの先頭に’category’がある場合は、カスタム構造の「/%category%/%postname%/」
    のルールにマッチするか調べる前にカテゴリーアーカイブページのルールにマッチするので、
    記事一覧が表示されます。

    > http://example.com/hoge/foo/ → fooの記事が見つからない
    この理由は、リクエストされたURIがカスタム構造の「/%category%/%postname%/」のルールに
    マッチしてしまい、カテゴリーhogeがついている投稿記事のfooを検索して、該当する記事が
    見つからなかったということですね。

    カスタム構造が「/%category%/%postname%.html」の場合、リクエストURIのhttp://example.com/hoge/foo/ はそのルールにマッチせず、最終的にカテゴリーhoge/fooの
    投稿記事が検索され、アーカイブページが表示されるようです。

    > http://example.com/foo/ → fooの記事一覧が表示される
    これも上記のルールでカテゴリーfooの投稿記事が検索されますが、これについては過去の
    一部のバージョンにおいて正しく表示できなかった覚えがあります。

    tracに上がっていたのですね、失礼しました。
    カンマ区切りの問題はほかにもあるので、国際化対応の難しさを感じますね。

    とりあえず解決済みにしますね。

    フォーラム: 使い方全般
    返信が含まれるトピック: グーテンベルグ 公開済み記事のプレビュー

    私が確認できている範囲の話になることをあらかじめお断りしておきます。

    ブロックエディターにプラグインなどで何等かのメタボックス(ウィジェット)を追加している場合、同様の症状が発生しています。
    もし「Classic Editorプラグイン1.3」を使用しているのであればそれを無効化してみてください。これで解決できるようであれば「Classic Editorプラグイン」のメタボックスがきっかけといえるでしょう。
    そのほかのプラグインがきっかけとなっている可能性もあるので、メタボックスを表示しているプラグインを無効化してみてください。

    この不具合についてはすでにtracに投稿済みですが、今のところ進捗はありません。
    https://core.trac.wordpress.org/ticket/45768

    またほかにもプレビューの問題については投稿されているようです。

    フォーラム: 使い方全般
    返信が含まれるトピック: 投稿内のphpコードを削除する方法知りませんか?

    functions.phpに追加したフィルターのコールバック関数は変更した$contentをreturnすればいいんじゃないでしょうか。

    function sample($content) {
    return str_replace(‘<!–?php the_title(); ?–>’, ‘[thetitle]’, $content);
    }
    フォーラム: 使い方全般
    返信が含まれるトピック: 5.02でもGutenbergが使えない。

    5.0のブロックエディターはREST APIを使ってデータのやり取りを行います。
    REST APIを無効化している状態ですとデータのやり取りができないため、
    投稿画面が真っ白になります。

    4.9リリース時の脆弱性対応でテーマのfunctions.phpにてREST APIを無効化したり、
    関連するプラグインを使っていないか確認されてはいかがでしょうか。

    こんな感じの翻訳はむずいですね。
    ありがとうございました。

    コメントありがとうございます。
    こちら、どちらかに統一したほうがいいとは思うのですが、
    どちらがいいかは判断つかなかったんですよね。。。

    フォーラム: 使い方全般
    返信が含まれるトピック: ページ送り時のoffset使用について

    JkZombieさん、
    ソースコードを観る限りoffset指定がある場合はpaged指定が無視されているので、
    両方を共存させることはできないようです。

    フォーラム: 使い方全般
    返信が含まれるトピック: wp_queryでoffsetを使いたい

    'posts_per_page' => '-1'
    ソースコードを見る限り、この指定により「全件取得する」という意味になるので
    offsetの指定は無効になるようですね。

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿タイプのタイトル必須設定
    tmatsuur

    (@tmatsuur)

    こんにちは。

    次の行で投稿タイプを「投稿’post’」に限定しているから他の投稿タイプでは有効になっていないと思います。
    if('post' == $('#post_type').val()){

    カスタム投稿タイプということなので、’post’を変更してみてください。

    フォーラム: 使い方全般
    返信が含まれるトピック: 絵文字(スマイリー)の画像が勝手に変わった
    tmatsuur

    (@tmatsuur)

    おはようございます。

    自分のプラグインで恐縮ですが、これで対応はできると思います。
    https://wordpress.org/plugins/html-entities-button/

    プラグインを有効化したら、「設定」-「html entities button」を
    開いて、「以前の顔文字画像を使用する。」をチェックして「保存」。

    お試しください。

    tmatsuur

    (@tmatsuur)

    一応つたない英語でtracに投稿してみました。
    PHP、JavaScript、翻訳テキストの兼ね合いがあるので、提案した内容で対応されるかはわかりません。
    https://core.trac.wordpress.org/ticket/33579

    こちら進捗があったら、報告するようにしますね。

    tmatsuur

    (@tmatsuur)

    こちらについて、ちょっと調べてみました。

    1.まず前提として日付フォーマットは4.3.0と4.2.4で変更されていません。
    日時フォーマット:’%3$s年%1$s月%2$s日 @ %4$s:%5$s’
    これは__(‘%1$s %2$s, %3$s @ %4$s:%5$s’)の翻訳テキストで、
    /wp-includes/script-loader.phpの496行目(4.3.0の場合)で
    定義されています。

    2.投稿日時編集のoption要素は、/wp-admin/includes/template.phpの787~788行目
    (touch_time関数)で、次のように出力されています。

    $monthtext = $wp_locale->get_month_abbrev( $wp_locale->get_month( $i ) );
    $month .= "\t\t\t" . '<option value="' . $monthnum . '" data-text="' . $monthtext . '" ' . selected( $monthnum, $mm, false ) . '>';

    ここで$monthtextの値は’12月’のように’月’が付いたものとなり、それがdata-text属性値
    として出力されます。

    3.実際に投稿日時編集を更新する/wp-admin/js/post.js(post.min.js)の563行目
    (4.3.0)では、次のように記述されています。
    .replace( '%1$s', $( 'option[value="' + mm + '"]', '#mm' ).attr( 'data-text' ) )
    これは日付フォーマットの’%1$s’をユーザが選択したoption要素のdata-text属性の値に
    書き換えることになり、例えば’%1$s’が’12月’になります。その箇所のみを抜粋すると
    ‘%1$s月’は’12月月’となってしまうわけです。

    4.2.4以前ではdata-text属性値を使用せず、option要素のテキスト部分で’%1$s’を書き
    換えていたので問題はなかったのですが、4.3.0で処理内容が変わったために発生して
    いる症状といえると思います。

    なおこの問題ですが投稿日時の編集のほか、コメント日時でも同様になっていました。

    この投稿時点で、tracの方は未確認です。対処方法も提案できるところまでは整理
    できていませんが、取り急ぎ情報共有まで。

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