ちなみにですが、一度変数に入れてから var で適用しているのはなぜでしょう？直接 env や constant 当てると問題があるのでしょうか？
「変数に入れているのは、携帯端末の回転中に再計算するのを防止する為」と海外サイトでは記載されていました。
その為、そうしています。
（※ 再発動を変数に代入する事で防げるのかデバッグ確認でも出来ませんでしたので、本当は直接入れても大丈夫かも…）
なんかいっそ viewport-fit なくしちゃったほうが良い気がしてきました…。
それも一度考えたのですが、将来的なことを考えると解決にならないので悩んでました。
ほとんどのウェブサイトではviewport-fitが無かったり、対策されていなかったり、
横向きでウェブページを見るユーザー数が低いとも言われていたりしますので、私の方で難しく考えすぎなのでしょうか…
情報共有ありがとうございます！ iOS だけに影響があるのかと思ってたのですが、Android や IE にも影響あるんですね…。
ちなみにですが、一度変数に入れてから var で適用しているのはなぜでしょう？直接 env や constant 当てると問題があるのでしょうか？
なんかいっそ viewport-fit なくしちゃったほうが良い気がしてきました…。
色々と私たちの制作チームでもお客さんに合わせて調整をしましたが、ややこしい問題でした。
- デバイスが、右に対して傾いているか、左に対して傾いているか、CSSだけでは取れない。
- 左右両方にpaddingを入れた場合は両方に適用されるのでpadding余白が大きく、中央にかなり寄ってしまう。
- envだけではAndroid等で一部対応されず、またIE時等にCSS解釈が正しく行われない。
3の項もある為に、@supportsで対応する形をとりました。
また、2の項から、通常の場合、メニューは左に出るので、padding-bottomと、padding-leftに対して対策をすれば良いようです。
1の項に関しては、leftとrightは縦表示の場合は、leftとrightは0で返却され、topに関しては、iPhoneの場合は0ですがAndroidの場合は機種によってノッチのピクセル分の数字が返される場合があるようです。これによりトグルメニューの一番上の項目がAndroidの場合めり込んでしまう機種も存在していますのでpadding-topで対応した方が良いようです。
しかし、padding分はメニュー幅が小さくなるので、ちょっと悩ましい問題です。
また、メニュー以外のコンテンツの場合、フル幅などの対応をどうしたら良いのかは悩み所です。
l-containerにpaddingを設けて対応するのが良いでしょうか？
メニューの対策については、その対策情報を勝手ながら下記に共有します。
ご参考になれば幸いです。よろしくお願いします。
/* 通常の場合はpaddingを0に設定しておきます。drawer-navに設定しているのはエリア全体に掛ける為です */
#drawer-nav {
padding-top: 0;
padding-left: 0;
padding-bottom: 0;
}
/* iOS11.0-11.2対応(旧Androidも） */
@supports (padding-left: constant(safe-area-inset-left)) {
#drawer-nav {
--safe-area-inset-left: constant(safe-area-inset-left);
padding-left: var(--safe-area-inset-left);
}
}
@supports (padding-top: constant(safe-area-inset-top)) {
#drawer-nav {
--safe-area-inset-top: constant(safe-area-inset-top);
padding-top: var(--safe-area-inset-top);
}
}
@supports (padding-bottom: constant(safe-area-inset-bottom)) {
#drawer-nav {
--safe-area-inset-bottom: constant(safe-area-inset-bottom);
padding-bottom: var(--safe-area-inset-bottom);
}
}
/* iOS11.2以降（Android 4系対応) */
@supports (padding-left: env(safe-area-inset-left)) {
#drawer-nav {
--safe-area-inset-left: env(safe-area-inset-left);
padding-left: var(--safe-area-inset-left);
}
}
@supports (padding-top: env(safe-area-inset-top)) {
#drawer-nav {
--safe-area-inset-top: env(safe-area-inset-top);
padding-top: var(--safe-area-inset-top);
}
}
@supports (padding-bottom: env(safe-area-inset-bottom)) {
#drawer-nav {
--safe-area-inset-bottom: env(safe-area-inset-bottom);
padding-bottom: var(--safe-area-inset-bottom);
}
}
ファイルパスだとこちらで確認できないので（そのパソコンの画面からしか見れない）、PDF でしたら Dropbox とかを使っていただくか、もしくは画像であれば返信欄から直接アップロードできます。
表示画面は下記よりご確認下さい。
よろしくお願いいたします。
file:///C:/Users/uekei/Documents/IE11%20表示崩れ.pdf
基本的なものだとこういう感じでしょうか。
register_post_type(
'news',
[
'public' => true,
'has_archive' => true,
'label' => 'ニュース',
'rewrite' => [
'with_front' => false,
]
]
);
とりあえずこれで news というカスタム投稿タイプが使えるようになるとは思いますが、どのようなレイアウトにしたいかでテンプレートを追加したりが必要になると思います。とりあえず投稿タイプが追加できたらトピック閉じていただいて、テンプレートの追加が必要そうならまた要件にあわせて別にトピック立てていただけたらと思います。
テーマ（functions.php）はプラグインは完全に読み込まれたあとに実行されますが、 My Snow Monkey はプラグインなので、 My Snow Monkey が読み込まれた段階では MW WP Form が読み込まれていない可能性があります。
全てのプラグインが読み込まれてから実行するには、 plugins_loaded にフックして処理を実行すると良いです。 mwform_validation_rules にフックさせている部分を下記のようにするとどうでしょうか？
add_action(
'plugins_loaded',
function() {
add_filter( 'mwform_validation_rules', 'mwform_validation_rule_requiredcheckbox' );
}
);
あ、上部下部あって、その下部ですね。とりあえず下部のウィジェットの上下余白を0にするのはこんな感じです。
.l-front-page-widget-area--bottom .l-front-page-widget-area__item {
margin-top: 0 !important;
}
.l-front-page-widget-area--bottom .l-front-page-widget-area__item .c-section {
padding-top: 0;
padding-bottom: 0;
}
ぴったり詰まるので、適当な数値を入れて良い感じにしてもらえば良いかもですね。
現在検証用に使っていた Windows 機が壊れてしまっていまして、新しい環境を準備中です。IE11、Edge については環境が整い後随時修正をおこなう予定でいます。
ちなみに、表示の崩れというのは、どの部分がどのようになっていますか？（もし可能ならスクリーンショットいただけるとわかりやすいです。可能ならで結構です！）
ちょっとよく意図がわからなかったので質問させてください。
「固定ページをひとつ」というのは普通の固定ページ、でしょうか？特に特殊なことがしたいわけでなく、普通の固定ページをつくりたいのであれば、ダッシュボード > 固定ページ > 新規追加から作成できます。
「投稿ページを2つ」というのは一覧表示されるページを作りたいということですよね？ Snow Monkey 公式サイトでいえば、
みたいな。思いつく方法は2つあって、
・「投稿」の中に「ブログ」「ニュース」という2つのカテゴリーをつくる。
・「投稿」をブログ、カスタム投稿タイプをつくってそれをニュースとして使う
前者の場合、カテゴリーアーカイブは自動的につくられますので特にコードを書く必要が無いというメリットがあります。ただ、ブログとニュースが混ざった一覧ページ（つまり標準の投稿ページ）ができてしまうこと、ブログとニュースで同じレイアウトになってしまう、というデメリットがあります。
後者の場合はブログ、ニュースを別の投稿タイプとして管理できる、それぞれ異なったレイアウトにしやすいというメリットがありますが、カスタム投稿タイプを追加するコードを書いたり、ニュース用のテンプレートをつくったりしないといけません。なのでコードを書くのが苦手な方の場合はハードルが高いです。
CSS で消すほうが簡単で安全なのでその方法を案内しますね。カスタマイザー > 追加 CSS に次の CSS を貼り付けみてください。
.c-entry-summary__meta {
display: none;
}
ドロワーメニューを開いたときに body を制御するというのがどうも疎になってない感じ
紐づいてもいない他の要素を制御をする違和感って、すごく解ります！
私も良く悩む問題です。
bootstrap4などで作られているメニューデザインを参考にしても、
スクロールの制御されているものはほとんどがbodyにoverflow:hiddenなどで対応されているようです。
他に解決方法が無いので仕方なくそうしているような感じなのか、難しく考えすぎなのかも悩みますね。
こちらでも良い解決方法を探してみます。
あぁ、iPhoneのWebビューア系のアプリ…。これ最初に実装したときから悩んでいる場所ではあるんです。スクロールしないほうが良いだろうなと思ってはいて。
スクロールさせないためには body に overflow: hidden すれば良いと思うんですけど、本来 ドロワーメニュー（ .c-drawer ）と body は独立したコンポーネント同士なので、ドロワーメニューを開いたときに body を制御するというのがどうも疎になってない感じで違和感があるんですよね。なにか良い解決方法があれば良いのですが、うーん、難しく考えすぎですかねぇ…。
【お使いの Snow Monkey のバージョン】v5.1.1
【お使いのブラウザ】iPhoneのWebViewアプリ
ドロワーメニューのメニューが多い時には、メニューをスクロール出来るのですが、
iPhoneのWebビューア系のアプリの場合は、メニューをスクロールするとメインコンテンツの方までスクロールされてしまっていたり、
スクロールされない場合でもフリックなどをしたらメインコンテンツがスクロールしてしまう場合があるみたいです。
ドロワーメニューがオープンされている際は、メインコンテンツのスクロールが出来ないように固定などは出来ないでしょうか？
直前、となると難しいかもしれませんが、head の中に入れるのは標準のフックで可能です。下記トピックを参考にしてください。
