フォーラムへの返信

15件の返信を表示中 - 16 - 30件目 (全293件中)
  • フォーラム: 使い方全般
    返信が含まれるトピック: アップロードできる画像サイズが規定より小さい

    php_value を .htaccess で利用できるのは、Apache の設定ファイルで、該当のディレクトリに、最低限、AllowOverride Option が指定されていて、かつ、PHP が、Apache のモジュールとして動作している場合だけです。お使いのサーバは、この要件をみたしていますか?

    Request exceeded the limit…

    は、Apache が出しています (だから、Apache のエラーログに残ります)。.htaccess の記述が無限ループになっていて、閾値を越えたということです。これについては、.htaccess の内容を確認してください。

    php_value memory_limitを128Mまで上げました

    これ、有効になってないみたいですよ。

    フォーラム: 使い方全般
    返信が含まれるトピック: ajaxで未ログイン時の「wp_ajax_nopriv~」が動かない

    もう、手遅れですかね…

    もちろん関数自体はログイン時と同じものです…

    フロントエンドでは、is_admin() は true になりますが、グローバル変数 ajaxurl は定義されていません。ドキュメント的には、

    url: admin_url('admin-ajax.php')

    のように自分で直書きするか、wp_localize_script() を使うかしてくれ、ってことになってます。

    AJAX in Plugins

    の Ajax on the Viewer-Facing Side あたりをご参考に。

    WordPress の Ajax 関連ドキュメントは、基本的に Plugin 作者向けなので、一般のユーザがそれで学習できるようにはなってません。関数によっては、何を言いたいのかわからないような英文になっていたりして、ちょっと使いにくいです。AJAX in Plugins も、どりあえずこれだけわかれば、使うのはできるよね、というくらいのノリになってます。日本語訳は、かなり古いもののようで、もはや翻訳にはなってません。そのうち、時間ができたら、日本語版の Codex を書きたいとは思っているのですが、貧乏暇なしで…

    gien さんが参考にしたページには書いてないですけど、check_ajax_referer() とか使えるので、WordPress を通したほうが安全だと思います。

    @kuroara さん

    WordPress も、静的ページも、同一ドメインですよね? ということは、データベースも同一でしょうか?

    …とても私にはできそうもありません…

    ということなら、無理して REST API や RSS を使わなくてもできますが、残念ながら、いずれにしても、プログラムを書かなければ実現はできないと思います。サムネール・イメージの条件を考えたら、直接データベースに問い合わせるのが簡単なような気がしますが、とりあえず、「WP JSON API」で検索したら、最上位にきた「WP REST API」を使った場合の雛形をつけます。マークアップは適当なので、お好きにどうぞ。

    「サムネール」は「投稿本文の中で最初に現れる <img src="..."> の…をそのまま使ってます。何も考えずに投稿にイメージを挿入すれば、リサイズされたイメージがここにきているはずなので。しかし、条件によってはオリジナルサイズのイメージが来てしまうかもしれません。

    この場合には、jQuery.getJSON() のコールバック関数が受け取るデータに投稿 ID が含まれているので、それを使って再び問い合わせをしなければなりません。完全な照合のためにはメタデータが必要で、このときは、認証が必要になります。あるいは、imgUrl 変数に入っているファイル名を決め打ちで書き換えるという手もありますが、テーマを変えただけで整合性を失いますので、お勧めではありません。

    プラグインを書き換えるのはどうか? 基本的に WordPress ですから、データを作るのに、WP_Query、WP_JSON_Response クラスを使っています。ということは、pre_get_posts フックを途中で実行するはずなので、メタクエリを追加すれば目的のデータを飛ばすことができます。この場合、フックだけではなくて、JavaScript も変更しなければなりません。外部に公開している API だというのと、プラグインをアップデートしたときに変更が消えるというのがいまいちなので、やってません。

    <script>
      (function($) {
          var items = [];
          $.when (
              $.getJSON("http://example.com/wp01/wp-json/posts", function(data) {
                  $.each(data, function(key, value) {
                      if ((/<img(.|\s)*?>/i).test(value.content)) {
                          var imgTag = value.content.match(/<img(.|\s)*?>/i)[0];
                          var imgUrl = imgTag.match(/src=["'](.*?)["']/i)[1];
                      }
                      items.push({title: value.title, link: value.link, img: imgUrl, date: value.date});
                  });
              }),
              $.getJSON("http://example.com/wp02/wp-json/posts", function(data) {
                  同じ繰り返し;
              })
          ).done(function() {
              items.sort(function(a, b) {
                  return a.date - b.date;
              });
              var container = $("<div>", {
                  "class": "post-container"
              });
              $.each(items, function(key, value) {
                  var subContainer = $("<div>", {
                      "class": "sub-container"
                  });
                  var titleTag = $("<h2>", {
                      "class": "post-title"
                  });
                  var linkTag = $("<a>", {
                      href: val.link,
                      text: val.title
                  });
                  titleTag.append(linkTag);
                  subContainer.append(titleTag);
                  if (val.img !== 'undefined') {
                      var imgTag = $("<img>", {
                          src: val.img
                      });
                      subContainer.append(img);
                  }
                  container.append(subContainer);
              });
              $("body").append(container);
          });
      })(jQuery);
    </script>
    フォーラム: 使い方全般
    返信が含まれるトピック: 管理画面が読み込みの途中で止まる

    同じさくらの別サーバで試してみました。結果、IE 11 での動作は問題ありませんでした。Smart Security その他、類似のソフトウェアは使っていません。念のため、互換モードでも試しましたが、アップデートしろと言われますが、動作は問題ありませんでした。

    手元にある別のサーバも確認しましたが、今のところ、同じ不具合は fish-net.sakura.ne.jp だけです。実は、OS の違いもあるのですが、今、FreeBSD が用意できないので、試してません。

    telnet で80番ポートに HEAD リクエストを出したときの違いは、PHP のバージョンだけです。

    fish-net:

    Server: Apache/2.2.29
    X-Powered-By: PHP/5.2.17

    さくらの別サーバ (Apache + fastcgi):

    Server: Apache/2.2.29
    X-Powered-By: PHP/5.4.35

    Linux (Apache + suphp):

    Server: Apache/2.4.10 (Ubuntu)
    X-Powered-By: PHP/5.5.12-2ubuntu4.3

    Win32 (Apache + mod_php):

    Server: Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.6.3
    X-Powered-By: PHP/5.6.3

    PHP のバージョンはサポート範囲内なので、それが原因とは考えにくいのですが、試しにバージョンを上げてみるとどうでしょうか。別の選択肢があるのに、わざわざ古いものを使う理由もありませんし、PHP をデフォルトで用意することはあまりないと思いますので、モジュールの出し入れでちょっと違いがあるかもしれません。

    本当に何となく程度ですが理解出来ます。

    半分くらいは Google とかで検索してくる人のための情報ですので、わからないとことがあっても問題ありませんです。試しに warning をそのまま入力して検索すると、Yahoo 知恵袋とここが検索上位2つですからね。そちらも fujimon さんかもしれませんが、答えてるのは私じゃありませんので、あしからず。お説教はするのもされるのも好みではありませんので。

    ところで、「ファーストサーバ」というのは、http://www.fsv.jp/ のことですか? 契約形態はどれでしょうか? localhost ということは、専用サーバでしょうか?

    このウェブページでは、MySQL 5.x (x のところは教えてくれないみたいだけど、たぶん0が入る)、PHP 5.3.x って書いてありますけど、5.2.17p3 というのは、どうやって知ったのですか? こちらは、検索すると、OpenBSD のパッケージが引っかかりますが、EC-CUBE のフォーラムへの投稿で、どうやら OS が Linux で、PHP は Apache のモジュールで動いているらいしというところまでわかりました。

    ついでに、

    本サイトの方のDBは正常に稼働しています

    というのは、別アカウントですか? それとも、同じドメインでディレクトリが違うだけですか? 稼働している方の wp-config.php は同じホストを指定していますか?

    とりあえずはこのまま待機で宜しいでしょうか?

    No problem.

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

    この warning でわかることが2つありますので、最初にそれを説明しておきます。

    1. PHP に mysqli ライブラリがないので、かわりに WordPress は mysql ライブラリを使っている
    2. PHP は、Unix ソケットを使って MySQL サーバと通信しようとしているけれども、それを見つけられていない

    1は、WordPress が古い PHP 用でも動作する仕組みを作動させているということを示しますが、これ自体はエラーではありませんし、warning の原因でもありません。load.php の途中までは正常動作をしているとも言えます。wp-config.php を削除した場合の動作とも一致しています。

    2は、そもそも MySQL と通信できていないことを示しているので、WordPress にとっては致命的なエラーです。PHP の構文エラーなどではないので、PHP にとっては「警告」で済んでいますが、WordPress は動きません。動作をシステムに任せたときに、ここでソケットへのパスが間違うというのは通常ありえないので、写し間違えではないかどうかを確認しました。wp-config.php では、たぶん、

    define('DB_HOST', 'localhost:3306');

    となっているのではないかと思いますが (番号は違う可能性もあります)、これを、PHP の mysql ライブラリが、

    localhost:/var/run/mysql/mysql.sock

    と書き換えています。このため、出力では、/var… 以下のパスが出てくるわけです。MySQL サーバが動いていない場合、この mysql.sock は存在しません。あるいは、パスが間違っている場合、mysql.sock が存在しないということで、mysql_connect() 関数が false を返します (エラーにはなりません)。

    サーバの OS が何かわからないので、何とも言えませんが、FreeBSD なら、デフォルトでは、

    /tmp/mysql.sock

    Linux 系統ならば、デフォルトは、

    /var/run/mysqld/mysqld.sock

    となることが多いようです。これらは、設定ファイルの書き換えでどこにでも移動できますし、ファイル名も変更ができますから、サーバ管理者の方針次第でどうとでもなります。

    さて、対策ですが、これだけの情報では何も確実なことは言えないというのが正直なところです。とりあえず…

    1. MySQL サーバを再起動する。
    2. 自前のサーバでないなら、サーバ管理会社に warning を示して、正しいパスを教えてもらう。あるいは、指示を仰ぐ。
    3. 自前のサーバなら、php.ini、my.cnf の設定を確認して、必要なら、修正する。
    4. TCP/IP での接続を試す。

    くらいでしょうか。1は、mysql.sock が何らかの事情で削除されてしまった場合、有効な手段ですが、MySQL デーモンを自分で操作できない場合は無理です。2は、サーバにアクセスできない場合、唯一の手段です。また、最も確実で推奨です。3の場合は、その設定を教えてください。4は WordPress のドキュメントでは触れられていませんが、

    define('DB_HOST', '127.0.0.1:3306');

    とすると、localhost でも TCP/IP で接続を試みます。このポートを LISTEN していなければつながりませんので、サーバの状態が判明するまではお勧めしません。

    ひとつ確認させてください。

    Warning: mysql_connect() [function.mysql-connect]: Can’t connect to local MySQL server through socket ‘/var/run/mysql/mysql.sock’ (2) in /virtual/www/eccube/html/blog/wp-includes/wp-db.php on line 1416

    これは、画面に出力されたものをコピーしたものですか、それともご自分で打ち込んだものですか?

    wp-config.php の、DB_HOST の値は、どのようになっていますか?

    バグリポートのやり取りを見る限り、リポーターはテーブルが作成されているかどうかを確認していないように見えるんですが、プラグインの挙動から考えて、確実にテーブルが存在しないということでしょうか? エラーメッセージを追加したバージョンにアップデートしたときに、”No change” と言ってますが、メッセージが出たとは言っていませんので… admin notice が出ていないのかもしれません。何より、プラグインを有効化したときに、テーブル作成でエラーになっていると、その時点で WordPress が admin notice を出すような気がします。

    ユーザに質問するときは、ひとつずつ、できれば Yes/No で答えられる問いを投げて、問題を絞っていくといいです。目の前に見ているものを言語化するのは、以外と難しいものですから。今回の場合は、プラグインが出しているエラーメッセージを見たか、見なかったか、からでしょう。それがなければ、テーブルは OK ってことですよね。

    また、プラグイン自体は動作していて、ログだけが取れていない、とも読めます。ログデータを INSERT や UPDATE するときのエラー・チェックはありますか? こちらがうまく動作していない可能性はありませんか? テーブルが存在しない場合に INSERT/UPDATE 文を投げると、MySQL はテーブルが存在しない旨のエラーを返しますが、スクリプト自体が return すれば何も表示されません。デバッグモードのときには、ここでチェックを入れるというのも考えられます。

    サーバの phpMyAdmin のチュートリアルを見ると、Server version 4.1.22、ENGINE=MYISAM とか書いてあって、ぎょっとなりますが、昔のものをそのまま使っているのでしょう。おっしゃるとおり、WordPress 本体が動いているので、PHP のバージョンが原因とは考えにくいですが、肝心の WordPress のバージョンもわからないので、プラグインなども含めて確認し、疑念を振り払っておいたほうが健康のためにはいいです。

    CREATE クエリについては、お示しのコードで、普通なら、テーブルが作成できると思います。ただ、プラグインがテーブルを作るときは、dbDelta() 関数を使った方が、後々のメンテナンスが楽なので、お勧めではありますが。

    テーブルが存在するかどうかは、

    SHOW TABLES LIKE table_name;

    で確認ができているはずなので、admin notice の有無を聞けばよいと思います。でも、これだけでは、テーブルの整合性まではチェックしてくれないので、

    DESCRIBE table_name;

    を使うと、テーブル内のカラムの状況を把握することができます (dbDelta() 関数は内部でこれを使っていて、よきに計らってくれます)。また、

    SHOW CREATE TABLE table_name;

    を使うと、テーブルを作成したときに使ったクエリをチェックすることができます (どちらもテーブルが存在することが必要条件です)。ユーザが phpMyAdmin をうまく使えそうもないときは、デバッグ用のコードを入れたものを作り、公開版とは別のタグを打って、コミットし、それと差し替えてもらうという手もあります。FTP なら何とか使えるという場合ですね。

    フォーラム: 使い方全般
    返信が含まれるトピック: 管理画面が読み込みの途中で止まる

    @harazaki さん

    さくらのテストサイトにアクセスさせていただきました。ありがとうございます。

    IE と Fiddler でサーバとのやり取りをモニタして、

    新規投稿画面から「メディアの追加」やタグの追加がまったくできません

    を再現することができました。iframe を描画するところで JavaScript が止まっています。ダッシュボードのコンポーネントは描画を終わっているので、見た目では同じように見えますが、ボタンクリックをキャッチするスクリプトがありませんので、無反応となります。tinymce を描画しているところと、customizer の部分でそうなっているようです。ダッシュボードの描画は、いわば2段階になっていて、ブラウザが読み込みを終えたように見えても、まだサーバでは仕事をしていて、あとからさらにデータが追加されます。このデータを IE では処理できなくなっています。

    このとき、サーバプログラムは全て200を返しているので、エラーはありません (さくらのサポートは正しいことを述べています)。だから、デバッグモードでは何も補足できないし、Apache のエラーログにも残りません。もちろん、エラーを出さないプログラムが不正なデータを送ることだってありますから、まったくの白とは断言できないのですが…

    わかったのはここまでで、なぜそうなるのかがまったくわかりません。現象を再現することもできていません。さくらの WAF は、mod_security ではないので、同じものを試すわけにはいかないのですが、前段階の不具合も再現できません。

    リロードすると、描画できたりできなかったりすること、バッファリングをする WAF を有効にしたときに、正常動作するブラウザが出てくること (Firefox は正常動作のようでした)、を考えると、ある種のタイミングのずれによって、うまく動作しないところがあるのかもしれません (あくまで推論です)。

    報告だけで申し訳ありませんが、とりあえず、ここまでです。

    追記: JavaScript 関連のデバッグをするときには、define('SCRIPT_DEBUG', true) を wp-config.php に書き込むと出力が少しだけ読みやすくなります。

    追記2: takeru0.0 さんの場合は、また違う状況かもしれません。「リロードすると…」というのが再現しませんでした。

    こんなので、いかが?

    /**
     * Google 風抜粋表示関数
     *
     * ループ以外の場所で使われたら、何もしない。search.php 以外では、通常の抜粋表示
     * を使う。検索文字列が複数の場合は、最初に出現した文字列を中心に計算をする。
     * mb_string モジュール必須。
     *
     * @param 表示する文字数を表す整数: デフォルト150文字
     */
    function the_googlean_excerpt( $num_chars = 150 ) {
        if (!in_the_loop()) return;
        if (!is_search()) return the_excerpt();
        mb_internal_encoding('UTF-8');
        $median = $num_chars >> 1;
        $search_words = get_query_var('s');
        $key_words = explode(' ', $search_words);
        $content = strip_tags(get_the_content());
        if (($content_len = $anchor = mb_strlen($content)) > $num_chars) {
            for ($i = 0, $len = count($key_words); $i < $len; $i++) {
                $position = mb_stripos($content, $key_words[$i]);
                if ($anchor > $position) $anchor = $position;
            }
            if ($anchor + $median > $content_len) $start = $content_len - $num_chars;
            else if ($anchor - $median < 0) $start = 0;
            else $start = $anchor - $median;
            $content = mb_substr($content, $start, $num_chars);
        }
        $key_words = array_map(function($str) { return '/'.$str.'/i'; }, $key_words);
        $content = preg_replace_callback($key_words, function($matches) {
                return '<strong>' . $matches[0] . '</strong>';
            }, $content);
        echo $content . '...';
    }

    テンプレートの抜粋を表示したいところに、

    the_googlean_excerpt();

    と書いてくだされ。引数に文字数を指定すると、その文字で表示するはず。マークアップはお好きにどうぞ。

    kjmtsh

    (@kjmtsh)

    is_customize_preview() というのがありますが、どうでしょう? 自分で試してないので、どうかわかりませんが。

    フォーラム: 使い方全般
    返信が含まれるトピック: javascriptとカスタムフィールドの連携
    kjmtsh

    (@kjmtsh)

    JavaScript と PHP を同時に使うことで、可能になります。

    フォーラム: テーマ
    返信が含まれるトピック: テーマの編集 について
    kjmtsh

    (@kjmtsh)

    @kirig さん

    FTP (クライアント・ソフトウェアは何をお使いでしょう?) 以外に、サーバにアクセスする他の手段がありませんか (「ファイルマネージャ」のような名称でユーティリティを用意しているサーバ会社が多いです)、また、ssh でアクセスできるサーバですか? サーバ会社のマニュアルを読んでみてください。

    サーバがどうなっているのかまったくわからないので、WordPress の関数群、定数群がどうなているかを調べるといいかもです。下の内容を、変更が反映されるテンプレートの中 (ループの外に) 書いて、ブラウザでアクセスしてみてください。WordPress がどこを見ているかがわかります。

    免責: 構文エラーがあると、PHP の fatal error で、ホワイトスクリーンになります。本当に FTP でアクセスできないとすると、また、代替の手段がないとすると、サーバ会社に削除をお願いする以外の回復手段がなくなります。責任は持ちません。

    if (function_exists('get_theme_roor'))
        echo 'テーマの置き場所 => ' . get_theme_root() . '<br/>';
    if (function_exists('get_template'))
        echo '使っているテーマのディレクトリ => ' . get_template() . '<br/>';
    if (function_exists('get_stylesheet'))
        echo 'スタイルシートを読む場所 => ' . get_stylesheet() . '<br/><br/>';
    
    echo 'このファイルのありか => ' . __FILE__ . '<br/>';
    echo 'このディレクトリにあるファイル...' . '<br/>';
    $dir = dirname(__FILE__);
    if ($dir_handle = @opendir($dir)) {
        while (false !== ($file_name = readdir($dir_handle))) {
            if ($file_name == '.' || $file_name == '..') continue;
            echo $file_name . '<br/>';
        }
        closedir($dir_handle);
    }
    echo 'ファイルチェック終了' . '<br/><br/>';
    
    echo '定数チェック...' . '<br/>';
    if (defined('WP_CONTENT_DIR')) echo 'WP_CONTENT_DIR => ' . WP_CONTENT_DIR . '<br/>';
    if (defined('WP_CONTENT_URL')) echo 'WP_CONTENT_URL => ' . WP_CONTENT_URL . '<br/>';
    if (defined('TEMPLATEPATH')) echo 'TEMPLATEPATH => ' . TEMPLATEPATH . '<br/>';
    if (defined('STYLESHEETPATH')) echo 'STYLESHEETPATH' . STYLESHEETPATH . '<br/>';
    echo '定数チェック終了' . '<br/><br/>';
    
    echo '関数チェック...' . '<br/>';
    if (function_exists('get_template_directory')) echo 'get_template_directory => ' . get_template_directory() . '<br/>';
    if (function_exists('get_template_directory_uri')) echo 'get_template_directory_uri => ' . get_template_directory_uri() . '<br/>';
    if (function_exists('get_stylesheet_directory')) echo 'get_stylesheet_directory => ' . get_stylesheet_directory() . '<br/>';
    if (function_exists('get_stylesheet_directory_uri')) echo 'get_stylesheet_directory_uri => ' . get_stylesheet_directory_uri() . '<br/>';
    echo '関数チェック終了' . '<br/>';
    kjmtsh

    (@kjmtsh)

    結論から言うと、可能です。ただ、条件がどんなものかによるかもしれません。Blog と Art Work の関係がどうなっているか、また、1ページで終わるのか、複数ページになるのか (「ページング」と呼びます) によって、2種類の投稿の関係は、次のどれかになると思います。

    1. Blog、Art Work ともに特定の数が表示できればよい (つまり、ページングをしない)
    2. Blog は複数ページだが、Art Work は2ページ目以降も同じ表示でよい
    3. Blog は同じ表示でよいが、Art Work は複数ページになる
    4. Blog、Art Work ともに2ページ目以降内容が変わっていく (両者ともページングをする)

    1は、お考えのとおり、固定ページで可能です (アーカイブ系のページでもできます)。また、最も容易に実現できる形式です。2および3は、固定ページを使わない方がよいと思います。ページングの処理でつまずく可能性が高いからです。アーカイブ系のページを使うのがお勧めです。4が、最も難しいと思います (可能ではあると思いますが)。

    QweR95 さんは、「ウィジェット」を扱ったことがありますか? ページングをしない場合、複数の投稿をページに表示するというのは、「ウィジェット」の見せ方を変えているということと同じです。どちらか一方を複数ページにするということは、そちらが主で、他方が「ウィジェット」ということになります。4も結果としては同じ考え方になると思いますが、片方はページ毎に内容を変える「ウィジェット」ということになりそうです。ある程度トリッキーなことをしないと実現できないでしょう。

    もっと他のアイディアをお持ちの方がいらっしゃるかもしれませんし、これがすべてでだと主張するつもりもありません。フォーラムでの質問の量を見ると、ページングの処理をしたくなったときにうまくいかなくなるケースが多いようです。それだけに、ケース・スタディは多いともいえますが、すんなり解決するのは少ないように思います。

    最後に、2つの投稿の区別ですが、同時に扱われることがないなら、「カスタム投稿タイプ」(Custom Post Type) を使った方がいいかもしれません。分類 (タクソノミー) 系の関数は豊富に用意されていますが、その分、ちょっと変則なことをしようとすると、データベースの扱いが格段に難しくなってしまうからです。

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