フォーラムへの返信

15件の返信を表示中 - 1 - 15件目 (全30件中)
  • なるほど。
    アドバイス、ありがとうございます。
    以下のテストをしてみました。

    RewriteCond %{REQUEST_URI} /test/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule . /test/css/main.css [L]

    にすると、きちんとCSSの内容が表示されました。
    index.phpにした場合だけ、リダイレクトループしました。

    引き続き、何かヒントをお持ちの方がいらっしゃいましたら、よろしくお願いいたします。

    gbism様

    アドバイスありがとうございます。

    ただ、今回のコンセプトとしては同じフォルダに入れたい。のです。
    これはテンプレート上の便宜性だけでなく、知識的にも知っておきたく思っています。

    サーバーの仕様ですが、どこを確認すればよいか。
    ご存知でしたらご教示いただきましたら幸いです。

    gbism様

    返信ありがとうございます。

    「アーカイブページと同じURL以下に、/css/などを置いて、」の目的はなんですか?(今のところアドバイスなどはないのですが)

    理論的ではないですが、
    testアーカイブページで使うものは、同じフォルダに格納てキレイに見せたい。
    別の方が管理するので、同じフォルダで分かりやすくしておきたい。
    だけです。

    「同じ処理・記述を別サーバで行いましたが、そちらは動作しました。」も WordPress でしょうか(ヒントになるかもしれないので)。

    はいWordPressです。
    同じように、アーカイブページ中に/css/を入れて動作を試みました。
    先述のhtaccess表記で、無事動作できました。
    サーバ会社は別です。

    nobita様

    参考になるコード、ありがとうございます。
    まだ試しておりませんが、まずは御礼申し上げますm(_ _)m
    参考にしながら、検証してみます。

    nobita様

    こんにちは。
    なるほど、サムネイルがなかったら原盤を表示すると考え方ですね。
    素晴らしい・・・

    どう実装すればよいかまだ想像できませんが、
    一度チャレンジしてみます。

    もう少し他の意見を頂戴したいので、スレッドは公開のままにします。
    ありがとうございました。

    gbism様

    アドバイス、ありがとうございます。
    やはりメタデータに格納されているのですね。

    全記事をインポートした際は、メディアのメタデータもインポートされるとありましたので、サムネイルを再生成してくれるなら、それに合わせてメタデータ(ファイル名)も変更されるかと思っておりました。

    こういう訳ですので対策は、このメタデータの中身を今のファイル名で上書きしてあげるのが良さそうです。うろ覚えなんですが、サムネイルを再生成するプラグインがあったような。

    おっしゃるとおりなのですが、ファイル名が300×248 など、末尾が画像サイズによってまちまちになります。
    リンク切れが50を超えているので、なかなか手動では・・・という状況です。

    ダメなとき戻せるようにデータベースとファイル全部のバックアップをとってから試してみては。
    Regenerate Thumbnails

    こちらも試してみました。
    サムネイルを再生成してくれるだけで、メタデータは変わりませんでした。
    アドバイスありがとうございます。

    サムネイルのファイル名は、「画像名-large.jpg」などであれば便利だなと思いました。
    以上、ありがとうございました。

    gbism 様

    返信、本当にありがとうございます。
    こういう経緯があったのですね。
    おっしゃるとおり、2015年9月あたりのファイルでした。

    インポート後のサムネイルのサイズは仕方ないにしろ、
    テーマから呼び出した時のファイル名が、旧ブログのファイルサイズになるのはどうしてでしょうか。

    wp_get_attachment_image_src(get_post_thumbnail_id($post->ID), 'thumbnail');

    これなら、現プログでインポートした後のサムネイルサイズが呼び出されそうですが。。。

    フォーラム: 使い方全般
    返信が含まれるトピック: wysiwygエディタでHTMLタグがエンティティ化される

    Daisuke様

    アドバイス、ありがとうございます。
    ただ前述しました、同じサーバ内の3.8Xあたりのwordpressでは正常動作している点
    がすごく気にかかります。
    なぜ今回の4.1のwordpressが不具合があるのか。。。
    新しいwordpressだから、バージョンが引っかかっているのかなと思っております。

    確かに製作者側から分からない点だと思います。
    サーバー管理者に問い合わせてみます。
    ありがとうございました。

    フォーラム: 使い方全般
    返信が含まれるトピック: wysiwygエディタでHTMLタグがエンティティ化される

    追記です。

    BackWPupを実行すると、
    「MySQLi拡張モジュールがない」とのエラーもありました。

    フォーラム: 使い方全般
    返信が含まれるトピック: wysiwygエディタでHTMLタグがエンティティ化される

    Daisuke様

    管理者が契約しているので、サーバー情報の詳細は不明です。
    セキュリティが高いか、
    何か不足があるのでしょうか。
    過去に、一部動かないプラグインもありました(Admin menu editorなど)
    インポートも白ページになったまま止まりました。

    PHPは5.3.28、MySQLはClient APIが4.1.24とあります。

    よろしくお願い致します。

    フォーラム: 使い方全般
    返信が含まれるトピック: wysiwygエディタでHTMLタグがエンティティ化される

    ああ、「<」に変換されました・・・

    「&lt;」の半角です。

    フォーラム: 使い方全般
    返信が含まれるトピック: wysiwygエディタでHTMLタグがエンティティ化される

    Daisuke様

    アドバイスありがとうございます。
    ブラウザキャッシュはクリアし、また別PCでも確認致しました。
    また全プラグインもOFFにしましたが、事象は同じでした。
    functions.phpも、pre_get_port関係の記述だけになっております。

    同じデータを別サーバで確認しましたら、正常動作しております。
    また、同じサーバ内の3.8Xあたりのwordpressでは、正常動作しております。
    本日、4.1(最新)にアップデートしても変わりませんでした。

    更新前まではきちんとエディタ内で下線や色変更されていますが、
    保存すると、

    <span style=”text-decoration: underline;”> この本文はテストです。</span>

    と変換されて、
    <span style=”text-decoration: underline;”> この本文はテストです。</span>
    という文字列になります。
    太字は<b>あああ</b>となり、正常に装飾されます。

    フォーラム: その他
    返信が含まれるトピック: XAMPP データベースがおかしくなります

    Daisuke様

    承知致しました。
    同じトラブルの方がいるかと思い、聞いてしまいました。
    あちらで聞いてみます。

    ありがとうございました。

    jim912様

    ご指導、ありがとうございます。
    いただいたコードを参照し、まずは実装してみたところ動作致しました。
    ただ、該当者の記事だけが「編集できない」ようになっていたので、
    下記のように逆に致しました。
    また、「もしエリアマネージャーなら」の分岐も追加しております。

    function filter_edit_post_cap( $capabilities, $caps, $args ) {
    
    	// edit_post のチェックの時のみ動作
    	if ( 'edit_post' == $args[0] ) {
    		if(current_user_can('area_manager')){
    		$user = wp_get_current_user();
    		$manageArea = get_field( 'manageArea', $args[2] );
    		// manageArea カスタムフィールドが設定されていて、ユーザーのIDが同値であれば
    		if ( !$manageArea ){
    			$capabilities[$caps[0]] = false;
    		}else if ( isset( $manageArea['ID'] ) && $manageArea['ID'] != $user->ID ) {
    			// 必要な権限を無効化
    			$capabilities[$caps[0]] = false;
    		}
    		}
    	}
    	return $capabilities;
    }
    add_filter( 'user_has_cap', 'filter_edit_post_cap', 10, 3 );

    こちらで希望の動きになっております。
    これを元に、どういう仕組になっているか勉強致します。
    ありがとうございました。

    現状、エリアマネージャーの管理画面では、
    全記事がリストされ、編集権限がある記事だけリンクがあります。
    これを編集権限がある記事だけ表示にすることは可能でしょうか。
    トップで書いた、meta_queryを用い、複合的に処理するのでしょうか。

    もしお時間がありましたら、ご教示いただきますようよろしくお願い致します。
    ありがとうございます。

    jim912様

    アドバイスありがとうございます。
    ただ、かなり高度すぎてほとんど理解できておりません(^^

    お教えいただいたコードは、どこで実行するものなのでしょうか。
    $capabilitiesの値は、それぞれの記事が持っているものでしょうか。
    お聞きしてばかりですが、お導きいただきましたら幸いです。

    この対策ですと、記事の一覧には表示されなくなりますが、編集権限を制限しているわけではないので、記事の編集画面などで、URLのpostの数値を打ち替えることにより、簡単に範囲外の記事を編集することができてしまいます。

    そのとおりなのですが、上記のとおり、高度な処理が理解できておりませんので、
    編集者たちは身内ですのでそのあたりの制限よりも、まずは実装できればというレベルでございます。

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