石川@Vektor,Inc.
フォーラムへの返信
-
投稿者投稿
-
石川@Vektor,Inc.キーマスター手動でカラムを作らずに画像ギャラリーのブロックを利用してはどうでしょう?
石川@Vektor,Inc.キーマスターそうですねぇ…Gutenberg自体がpタグで一つのブロックという考え方なので、QAの中でpタグを使いたい場合はHTMLブロックを利用して手打ちするしか回避策は難しいかなと思います ><
石川@Vektor,Inc.キーマスターもう一度画像選択ボタンを押して、画像を選択しないまま「選択」ボタンを押してください。
石川@Vektor,Inc.キーマスターGutenbergは新しいブロックエディタを開発・テストに使用されているプラグインで、5.0移行はまず基本機能は本体に入っているので、停止してかまいません。
しかし、WordPressのブロックに関する機能変更は継続して続いており、その先行開発がGutenbergで続けられています。
Gutenbergで開発して仕様が固まって安定してきたらWordPress本体に取り込まれていくというような流れになっていますので、一般ユーザーとしてっはGutenbergは停止してもかまいません。
石川@Vektor,Inc.キーマスタープラグイン「Gutenberg」が有効化されているなら停止(WordPress本体のブロックエディタになる)して試してみてください。
ダメならクラッシックエディタモードにして一度保存して、またブロックエディタで試してみてください。
石川@Vektor,Inc.キーマスターまだまだ仕様調整中ではありますが、一応使えるように公開しました。
石川@Vektor,Inc.キーマスターUser role editor は権限を変更処理するためのプラグインなので、一度変更・保存したらデータベースの権限情報は書き換わるので、プラグインを停止しても、変更した権限は戻らないという形になります。
権限の状態確認・書き換えは User role editor で出来るのですが、
そもそも実際どういう経緯で編集者権限に edit_plugins がついていたのか謎な状態です。もしかしたら他のプラグインがっ編集者権限に edit_plugins を付与したのかもしれません。
何にせよもし編集者ユーザーに OBUnitのメニューが見えてしまったら、そのユーザーに edit_plugins 権限が付与されてしまっている状態なので、今回同様の処理で edit_plugins 権限を外してください。
以上よろしくお願いいたします。
石川@Vektor,Inc.キーマスターOuterブロックの中に入れた要素の左右に余白がなくて横長になってしまう という意味であれば、
Outerブロックを選択した状態で表示される右側のパネルの レイアウト設定 の コンテンツエリアの余白(左右) で、余白を使用する方のラジオボタンを選択してください。
石川@Vektor,Inc.キーマスター必要なページだけブロックエディタを使うという対応でも良いとは思いますよ。
表示上は問題ありませんので。
ご参考まで。
石川@Vektor,Inc.キーマスターご指摘ありがとうございます。
2.0.5にて修正いたしました。
ご迷惑おかけして申し訳ありません。
アップデートしてご確認くださいませ。
石川@Vektor,Inc.キーマスター確認いたしました。
まず、通常のWordPressの編集者権限には edit_plugins ありません。
しかしながら該当サイトの編集者権限を確認させていただいたところ、編集者に edit_plugins 権限が付与されていました。
Lightning Original Brand Unit のメニューは edit_plugins 権限を持っているユーザーに表示されるようになっているため、表示されたという状態です。
プラグイン「User role editor」がインストールされていましたが、
こちらを有効化して、プルダウンの項目で「編集者」に切り替えていただくと、edit_plugins にチェックが入っている事が確認できます。
このチェックを外して保存してください。そうすれば編集者には Lightning Original Barnd Unit のメニューは表示されなくなります。
石川@Vektor,Inc.キーマスター1. 該当の記事を予備として複製、非公開にしておく
2. 該当の記事をクラッシックエディタの状態で開いて本文欄を全て選択・コピー、管理画面の記事一覧画面に戻る
3. 該当の記事をブロックエディタモードで開いて、貼り付け
4. もともとあったクラッシックエディタブロックを削除の手順でいけるかと思います。
石川@Vektor,Inc.キーマスター
石川@Vektor,Inc.キーマスター確認したところ、該当の件についてはアイキャッチ画像が別の画像(一覧で表示される画像)が登録された状態でした。
※編集画面右上の表示オプションタブから、アイキャッチ画像のチェックを外して再びつけるとアイキャッチ画像に登録されているものが確認できます。Works Unit の 2.0.3 までは Works Unit のアーカイブページでの表示する画像は、アイキャッチ画像が登録されていたら、アイキャッチ画像を表示し、アイキャッチ画像の登録がなければカスタムフィールドに保存している「メイン画像」を表示するようになっています(厳密にはもう少し複雑ですが)。
しかしながら、「アイキャッチ画像」と「メイン画像」は通常同じになるので、2つ登録するのはユーザーにとって手間だろうという事で、記事投稿画面において、アイキャッチ画像の登録欄は初期状態では非表示になる処理となっています。
そして、メイン画像に登録された投稿が一度保存されるタイミングで、メイン画像がアイキャッチ画像に登録されるという処理が入っています。
2回目の保存で正常になるのはこのためです。
原因不明なのは、該当の投稿がどうして初期投稿時に違う画像がアイキャッチ画像として登録されていた状態なのかという点なのですが、他の記事を複製して作成したのかと思いきや複製系のプラグインも入っていなかったので…
とは言え、「メイン画像」に登録した画像がアイキャッチに自動保存される仕様になっている以上、
アイキャッチ画像が登録されていたら、アイキャッチ画像を表示し、
という処理自体が今回のような不具合を引き起こす原因となる事が判明しましたので、
プラグイン側で修正いたしました(2.0.4)。2.0.4 にアップデートいただくと問題なく動作するかと思います。
ご確認よろしくお願いいたします。
> RICKさん
すみません、WorksUnitの仕様に問題がった事が原因でした。
お手数おかけしました。いつもありがとうございます。
石川@Vektor,Inc.キーマスター -
投稿者投稿