-
検索結果
-
その記事に紐づく任意のタクソノミーのタームを取得する関数
get_the_terms()を使う形になると思います。// テンプレートパーツのh3タグの後ろにdivタグを追加する $html = str_replace( '</h3>', $acf_property_info, $html ); // 記事に紐づいている post_tag の各タームのアーカイブページへのリンクを表示する ob_start(); $post_tag_terms = get_the_terms( get_the_ID(), 'post_tag' ); if ( is_array( $post_tag_terms ) ) { foreach ( $post_tag_terms as $post_tag_term ) { ?> <a href="<?php echo esc_url( get_term_link( $post_tag_term ) ); ?>"><?php echo esc_html( $post_tag_term->name ); ?></a> <?php } } $html = $html . ob_get_clean();Who liked:変更を入れたバージョン（v10.0.0 Beta1）を共有します！
内部のデータの持ち方を変えないといけなかったので、いきなりアップデートして互換性的に問題があるとまずいので、一旦こちらで共有させてください。1つ目のラジオボタンの UI で必須にしていて2つ目では必須にしていないというときに、2つ目の設定で上書きされて必須チェックが何も通らなくなるので、
一応、完全に上書きされるとやっぱりわかりにくいので、UI と実際のバリデーションが（できる範囲で）一致するように調整してみました（同じ name を持つ中で post された順で判定するようにしています）。
確認お願いします！
Who liked:バリデーションが同じになるのは良いと思うのですが、UI も共通化されるわけではないので、1つ目のラジオボタンの UI で必須にしていて2つ目では必須にしていないというときに、2つ目の設定で上書きされて必須チェックが何も通らなくなるので、よくわかっていない人は混乱するかなーみたいなのがありはするなと。
今回はラジオボタンでしたが、チェックボックスでも同じことがあるかと思いますので、
データの持ち方を変えて、「name に複数の入力項目が紐づいているとき」で出し方を調整しようと思うので、基本的にはどの入力項目でも同じような感じで設置できるようになると思います。
Who liked:これ確か入力以外の画面は name に紐づいてデータを管理しているのに、入力だけ違ってたので統一させた、という感じだったと思います。だから複雑さを減らしてわかりやすくしたりメンテナンスしやすくするという意味では正しい変更だと考えているのですが、まぁそういう配置にしたいという場合ってありますよね…うーん。
とりあえずなるべく今の実装を活かしたまま、同名の入力項目を設置できるようにできないか試してみたいと思います。
が、一点、バリデーションについては name に紐づくので、同名の入力項目を設置した場合、一番後の入力項目に設定したバリデーション設定で他の同名の入力項目のバリデーション設定は上書きされてしまう、という挙動にはなると思います（多分 6.2.0 段階でもそうだったはず）。
一応差分貼っときます。
Who liked:子テーマで普通にテンプレートパーツを上書きすることももちろん可能ですが、今後のメンテナンスを考えると My Snow Monkey プラグインか、子テーマを使っているなら子テーマの
functions.phpにコードを書くのが良いです。下記でどうでしょうか？
add_filter( 'snow_monkey_get_template_part_args_template-parts/header/site-branding', function( $args ) { $args['vars']['_title_tag'] = 'p'; return $args; } );Who liked:エックスサーバーで問い合わせフォームから送信できないという現象についてぐぐってみると、どれも REST API の制限解除で送信できるようになったと書いてありますね…。下記の例は Contact Form 7 ですが、内部的には Snow Monkey Forms と同じ WordPress 本体のメール送信関数を使っていると思うので、理屈としては同じだと思います。
例：
REST API アクセス制限を解除しても送れないとなるとちょっとわかりませんが、エラーが発生したときにサーバーのエラーログにもう少し詳細なログが残っているかもしれないので、エラーログを確認してみてください。
Who liked: No user購入者側でカスタマイズが全くされていない場合は、エラーを1つずつ修正していく必要はないということでしょうか？
全くされていない場合は必要ありません。
ただ、アップデートにバグが含まれている場合、かつ、そのバグを修正するアップデートも実行できない場合は、管理画面からのワンクリックアップデートではなく zip ファイルアップロードによるアップデートをお願いする、のような対応をお願いすることはあり得ます。
あと、ブロックについてはプラグインやテーマのアップデートだけでは HTML 構造をアップデートすることができない（WordPress の仕様）ため、ブロックの HTML 構造のアップデートが必要な場合は、プラグインやテーマのアップデートの後にページの編集画面を開き、更新ボタンを押してください（WordPress の仕様で、編集画面を開いた段階でそのページ上のブロック HTML 構造がアップデートされる）、とご案内することもあり得ます。
テーマのアップデートの際にファイルの更新が必要な個所を教えてください。
アップデートのたびに、どの箇所に変更や修正が入ったか、お知らせ記事を書いています。
例えば、v14.0.0 へのアップデートの場合、
Framework\Helper::has_category_thumbnail()が廃止されてFramework\Helper::has_term_thumbnail()に変わることを案内しています。なのでアップデート前に記事を確認して、独自に追加しているコードの中でFramework\Helper::has_category_thumbnail()を使用している場合はFramework\Helper::has_term_thumbnail()に書き換える必要があります。また、Snow Monkey テーマと Snow Monkey Blocks などのプラグインは全てのコードの変更履歴を GitHub で公開しています。お知らせ記事に全てのコードの変更履歴を書くのはわかりにくいので概要を書いていますが、独自のゴリゴリにカスタマイズしている場合は概要だけでは必要な全てがわからない場合がありえます。そういう場合は GitHub の変更履歴を見ると細かいところまで全て確認できます。
※右側の「745d533」などの英数字の羅列の部分をクリックすると、その時点のコードレベルでの変更履歴が確認できます。
Who liked: No userこちらの理解が不十分で大変失礼いたします。
前提として、Snow Monkey ChildはSnow Monkeyのテーマには不要なもので、Snow Monkey公式が作ったものではないので関与しません（ただし善意で相談には乗りますよ）ということなのでしょうか？
Snow Monkey Childの説明にはSnow Monkeyの子テーマとの記載があるため、子テーマと親テーマのアップデートには関連性があるものと認識しておりました。
もし関連性があり、古いバージョンから新しいバージョンへの変更の際に、購入者側でカスタマイズしたものを除く部分でも都度子テーマ内の記述の変更が必要なのであれば、必要個所を事前にお伺いすることでローカル環境にて子テーマを最新の親テーマに対応できるように修正できるかと思い、
そうであれば、親テーマのアップデートに伴い、子テーマで修正が必要な個所をすべて（購入者側でカスタマイズした部分を除く）教えていただくことは可能でしょうか？
と質問させていただきました。（### 本番環境への反映の4番の手順でエラーが出てサイトが表示できないことを防ぐため）
長々と恐縮ですが、いかがでしょうか？
Who liked: No user認識に違いがでないように細かく書きます。
### 本番環境の復元
バックアップデータを使い、エラーが発生する前の状態に戻す（WordPress 本体、各プラグイン、Snow Monkey、Snow Monkey Child）### テスト環境の構築と、Snow Monkey Child の最新版への対応
- ローカルにテスト環境を用意し、WordPress の最新版をインストールする（ローカル環境ではなくてサーバー上に用意しても可）
- 使用するプラグインの最新版をインストール・有効化する
- Snow Monkey の最新版をインストールする
- Snow Monkey Child から不要（= 上書きする必要がない）なファイルを削除する（Snow Monkey からコピーしてきたけど何も変更していないファイルは全て不要です）
- Snow Monkey Child をインストール・有効化する
- 恐らくここでエラーがでて表示されなくなる（このトピックを立てたときと同じ現象）
- でてきたエラーメッセージに応じた変更を加え、エラーを解消する。
- (7) をエラーが無くなるまで繰り返す
※本当はここで本番環境のデータベースをテスト環境にインポートして、ページの内容についても崩れが発生しないか確認したほうが良いですが、難しいのであれば、僕ならページの内容については本番で直していきます。
### 本番環境への反映
- 本番環境のテーマを Snow Monkey 以外のものに切り替える（Twenty◯◯が良いと思います）
- WordPress と各プラグインを最新版にアップデート
- Snow Monkey 最新版をインストール
- テスト環境で修正した Snow Monkey Child をインストール・有効化
※もしここでまたエラーメッセージがでるならエラーが出なくなるまで修正をおこなう - エラーが無くなったら、各ページの内容を確認し、レイアウト崩れが発生していないか確認
- レイアウトが崩れている部分があったら、そのページの編集画面を開く（ブロックを使ってページを作成している場合、ブロックの内容が古くなっている場合はページの編集画面を開くことで、そのページ上のブロックが最新のブロックに置き換わります）
- ページの編集画面を開いてエラーが発生するようなら修正をおこなう
- もし CSS を独自に追加している場合、WordPress 本体や Snow Monkey のアップデートで CSS が効かなくなっている場合があるので、必要に応じてその修正もおこなう
また、今までスノーモンキーの子テーマを使用していた人が最新版のスノーモンキーテーマを使用するためには、自分でスノーモンキー子テーマの記述を最新版に対応するように記述しなおす必要があるということで認識は合っていますか？
カスタマイザーやブロックの設定パネルで設定していたものが正しく動かなくなるのはこちらで修正してアップデートを日々おこなっていますが、各ユーザーごとのカスタマイズは何をどうカスタマイズするかはこちらで完全に把握することはできないため、基本的にはご自身で変更していただく必要があります。車や PC を購入してそれを自分でカスタムした場合、保証が効かなくなったり修理を断られたりすることがあると思います。自分でカスタマイズをおこなうというのはそういうことだと思います。
もちろんサポートはおこなっているので、状況を教えていただければできる範囲で調査してお答えしています。
そうであれば、親テーマのアップデートに伴い、子テーマで修正が必要な個所をすべて（購入者側でカスタマイズした部分を除く）教えていただくことは可能でしょうか？
「子テーマを作成する」ということ自体がカスタマイズになる（こちらで用意したファイルではない）ので、こちらで全てを調査・把握して修正作業をおこなうということは行っておりません。もちろん、前述したようにサポートはおこなっているので、状況を教えていただければできる範囲で調査してお答えしています。
購入者側でテスト環境を用意して確認していかなければならないものなのでしょうか？
「していかなければならない」と強制するものではありませんが、カスタマイズをおこなう場合はテスト環境を用意したほうが良いというのは一般的な認識だと思うので、僕もテスト環境を用意することを推奨しています。
—
Snow Monkey に精通している方を「Snow Monkey エキスパート」としてサイトに掲載しているので、どうしても難しい場合はエキスパートの方に相談するのも良いと思います。これまでもサポートフォーラムで Snow Monkey エキスパートの制度を紹介し、相談された方が何名かいらっしゃいます。
Who liked: No user
