石川@Vektor,Inc.

フォーラムへの返信

15件の投稿を表示中 - 3,046 - 3,060件目 (全3,318件中)
  • 投稿者
    投稿
  • 返信先: Outerブロックの背景の削除方法 #15898

    もう一度画像選択ボタンを押して、画像を選択しないまま「選択」ボタンを押してください。

    Gutenbergは新しいブロックエディタを開発・テストに使用されているプラグインで、5.0移行はまず基本機能は本体に入っているので、停止してかまいません。

    しかし、WordPressのブロックに関する機能変更は継続して続いており、その先行開発がGutenbergで続けられています。

    Gutenbergで開発して仕様が固まって安定してきたらWordPress本体に取り込まれていくというような流れになっていますので、一般ユーザーとしてっはGutenbergは停止してもかまいません。

    プラグイン「Gutenberg」が有効化されているなら停止(WordPress本体のブロックエディタになる)して試してみてください。

    ダメならクラッシックエディタモードにして一度保存して、またブロックエディタで試してみてください。

    まだまだ仕様調整中ではありますが、一応使えるように公開しました。

    VK Google Job Posting Manager

    User role editor は権限を変更処理するためのプラグインなので、一度変更・保存したらデータベースの権限情報は書き換わるので、プラグインを停止しても、変更した権限は戻らないという形になります。

    権限の状態確認・書き換えは User role editor で出来るのですが、
    そもそも実際どういう経緯で編集者権限に edit_plugins がついていたのか謎な状態です。

    もしかしたら他のプラグインがっ編集者権限に edit_plugins を付与したのかもしれません。

    何にせよもし編集者ユーザーに OBUnitのメニューが見えてしまったら、そのユーザーに edit_plugins 権限が付与されてしまっている状態なので、今回同様の処理で edit_plugins 権限を外してください。

    以上よろしくお願いいたします。

    Outerブロックの中に入れた要素の左右に余白がなくて横長になってしまう という意味であれば、
    Outerブロックを選択した状態で表示される右側のパネルの レイアウト設定 の コンテンツエリアの余白(左右) で、余白を使用する方のラジオボタンを選択してください。

    必要なページだけブロックエディタを使うという対応でも良いとは思いますよ。
    表示上は問題ありませんので。
    ご参考まで。

    ご指摘ありがとうございます。
    2.0.5にて修正いたしました。
    ご迷惑おかけして申し訳ありません。
    アップデートしてご確認くださいませ。

    確認いたしました。

    まず、通常のWordPressの編集者権限には edit_plugins ありません。

    しかしながら該当サイトの編集者権限を確認させていただいたところ、編集者に edit_plugins 権限が付与されていました。

    Lightning Original Brand Unit のメニューは edit_plugins 権限を持っているユーザーに表示されるようになっているため、表示されたという状態です。

    プラグイン「User role editor」がインストールされていましたが、
    こちらを有効化して、プルダウンの項目で「編集者」に切り替えていただくと、edit_plugins にチェックが入っている事が確認できます。
    このチェックを外して保存してください。

    そうすれば編集者には Lightning Original Barnd Unit のメニューは表示されなくなります。

    1. 該当の記事を予備として複製、非公開にしておく
    2. 該当の記事をクラッシックエディタの状態で開いて本文欄を全て選択・コピー、管理画面の記事一覧画面に戻る
    3. 該当の記事をブロックエディタモードで開いて、貼り付け
    4. もともとあったクラッシックエディタブロックを削除

    の手順でいけるかと思います。

    DBのデータの保存状態を直接確認させていただきたいので、
    管理画面のログイン情報を教えていただく事は可能でしょうか?

    よろしければ下記よりご連絡ください。

    有償製品購入前の製品仕様などのお問い合わせ

    確認したところ、該当の件についてはアイキャッチ画像が別の画像(一覧で表示される画像)が登録された状態でした。
    ※編集画面右上の表示オプションタブから、アイキャッチ画像のチェックを外して再びつけるとアイキャッチ画像に登録されているものが確認できます。

    Works Unit の 2.0.3 までは Works Unit のアーカイブページでの表示する画像は、アイキャッチ画像が登録されていたら、アイキャッチ画像を表示し、アイキャッチ画像の登録がなければカスタムフィールドに保存している「メイン画像」を表示するようになっています(厳密にはもう少し複雑ですが)。

    しかしながら、「アイキャッチ画像」と「メイン画像」は通常同じになるので、2つ登録するのはユーザーにとって手間だろうという事で、記事投稿画面において、アイキャッチ画像の登録欄は初期状態では非表示になる処理となっています。

    そして、メイン画像に登録された投稿が一度保存されるタイミングで、メイン画像がアイキャッチ画像に登録されるという処理が入っています。

    2回目の保存で正常になるのはこのためです。

    原因不明なのは、該当の投稿がどうして初期投稿時に違う画像がアイキャッチ画像として登録されていた状態なのかという点なのですが、他の記事を複製して作成したのかと思いきや複製系のプラグインも入っていなかったので…

    とは言え、「メイン画像」に登録した画像がアイキャッチに自動保存される仕様になっている以上、

    アイキャッチ画像が登録されていたら、アイキャッチ画像を表示し、

    という処理自体が今回のような不具合を引き起こす原因となる事が判明しましたので、
    プラグイン側で修正いたしました(2.0.4)。

    2.0.4 にアップデートいただくと問題なく動作するかと思います。

    ご確認よろしくお願いいたします。

    > RICKさん

    すみません、WorksUnitの仕様に問題がった事が原因でした。
    お手数おかけしました。いつもありがとうございます。

    返信先: フォーラムに関する要望 #15813

    WorksUnitの 各実績の メイン画像 を登録して、その画像がアーカイブページに表示される画像と違うという事ですよね?

    詳細ページでは問題ない。

    再度登録すると問題なくなる。

    うーん、構造面でもブラウザなどのキャッシュ面でもちょっと原因が思いつかないですね…。

    こちらからご連絡いただいて管理画面のログイン情報などいただければ、
    弊社環境に複製して確認させていただきます。

    有償製品購入前の製品仕様などのお問い合わせ

    返信先: フォーラムに関する要望 #15804

    ご指摘ありがとうございます。
    リンクボタンのURLおかしいですね…。
    codeもおっしゃる通りだと思います。

    近日調整いたします。ご意見ありがとうございます。

15件の投稿を表示中 - 3,046 - 3,060件目 (全3,318件中)