Forum Replies Created

Viewing 14 replies - 1 through 14 (of 14 total)
  • Thread Starter windorz

    (@windorz)

    修正頂きありがとうございました。

    問題なく動作することを確認できました。

    素晴らしいプラグインをリリースして頂き感謝いたします。

    Thread Starter windorz

    (@windorz)

    元のコードを以下のように修正すると、問題なく動作します。

    public function site_url( $url, $path, $scheme, $blog_id ) {
    if ( isset( $this->options['login_page_name'] ) ) {
    $loginfile = $this->options['login_page_name'] . '.php';
    $formated_path = '/' . ltrim( $path, '/' );

    // シンプルな正規表現で ?action と &action の両方にマッチ
    $pattern = '#/wp-login\.php.*(\?|&)action=\w+#';

    if ( '/wp-login.php' === $formated_path || preg_match( $pattern, $formated_path ) ) {
    $url = $this->get_login_url( $url, $loginfile );
    } elseif ( is_multisite() && ! is_subdomain_install() ) {
    $blog = get_site( $blog_id );
    $multisite_pattern = '#' . preg_quote( $blog->path, '#' ) . 'wp-login\.php.*(\?|&)action=\w+#';
    if ( $blog->path . 'wp-login.php' === $formated_path || preg_match( $multisite_pattern, $formated_path ) ) {
    $url = $this->get_login_url( $url, $loginfile );
    }
    }
    }
    return $url;
    }
    Thread Starter windorz

    (@windorz)

    修正ありがとうございます。

    正規表現を見ると、相変わらず?action前提となっているようでした。残念ながら、&actionとなるときはログインURLの置換は処理されずにwp-login.phpメールに記載されたままでした。

    元のコードがwp-login.php単独の場合と、actionパラメータがある場合の2つを対象にしているようですので、正規表現を使わずにstroposなどで文字列検出した方がシンプルな感じがします。

    Thread Starter windorz

    (@windorz)

    こちらコードの正規表現の不具合だと思っていますが、最新バージョン3.10.5でも修正されていないようです。

      ?action=だけでなく、&action=にもマッチするように対応して頂けないでしょうか?

      Thread Starter windorz

      (@windorz)

      パスワードリセットのリンクは、

      /wp-login.php?login=admin&key=xxxxx&action=rp

      というURLになりますが、if文のpreg_match( '#/wp-login\.php\?action=\w+#', $formated_path )にマッチしないので、URLの置き換えが行われず、そのまま出力されているようです。

              public function site_url( $url, $path, $scheme, $blog_id ) {
      if ( isset( $this->options['login_page_name'] ) ) {
      $loginfile = $this->options['login_page_name'] . '.php';
      $formated_path = '/' . ltrim( $path, '/' );
      if ( '/wp-login.php' === $formated_path || preg_match( '#/wp-login\.php\?action=\w+#', $formated_path ) ) {
      $url = $this->get_login_url( $url, $loginfile );
      } elseif ( is_multisite() && ! is_subdomain_install() ) {
      $blog = get_site( $blog_id );
      if ( $blog->path . 'wp-login.php' === $formated_path || preg_match( '#' . $blog->path . 'wp-login\.php\?action=\w+#', $formated_path ) ) {
      $url = $this->get_login_url( $url, $loginfile );
      }
      }
      }
      return $url;
      }
      Thread Starter windorz

      (@windorz)

      My site is running on WP5.8

      Any Thanks for your answer.

      Thread Starter windorz

      (@windorz)

      There was an extra space and it wasn’t enclosed in double quotes.

      width = 729
      width="729"

      It had nothing to do with webp, it works now.

      Thread Starter windorz

      (@windorz)

      The img tag has width=”719″ and height=”1024″, but when the image is in WebP format, the placeholder does not match those dimensions.

      • Rendered size:877 × 585 px
      • Rendered aspect ratio:877∶585
      • Intrinsic size:225 × 150 px
      • Intrinsic aspect ratio:3∶2
      • File size:68 B
      • Current source:data:image/svg+xml,%3Csvg%20xmlns=%22http://www.w3…22%20viewBox=%220%200%20210%20140%22%3E%3C/svg%3E
      <img class="wp-image-259775 ls-is-cached lazyload" src="data:image/svg+xml,%3Csvg%20xmlns=%22http://www.w3.org/2000/svg%22%20viewBox=%220%200%20210%20140%22%3E%3C/svg%3E" data-src="https://sample.com/wp-content/uploads/2025/01/content_image_6-719x1024.webp" width="719" height="1024" data-srcset="https://sample.com/wp-content/uploads/2025/01/content_image_6.webp 926w, https://sample.com/wp-content/uploads/2025/01/content_image_6-211x300.webp 211w, https://sample.com/wp-content/uploads/2025/01/content_image_6-719x1024.webp 719w, https://sample.com/wp-content/uploads/2025/01/content_image_6-768x1093.webp 768w" srcset="https://sample.com/wp-content/uploads/2025/01/content_image_6.webp 926w, https://sample.com/wp-content/uploads/2025/01/content_image_6-211x300.webp 211w, https://sample.com/wp-content/uploads/2025/01/content_image_6-719x1024.webp 719w, https://sample.com/wp-content/uploads/2025/01/content_image_6-768x1093.webp 768w">
      • This reply was modified 1 year, 4 months ago by windorz.
      Thread Starter windorz

      (@windorz)

      found the cause.

      Even after logging out of my site, the following cookies remained:

      • wordpress_logged_in_
      • wordpress_sec_

      After deleting these cookies, the cache changed from DYNAMIC to HIT, regardless of the Edge TTL settings.

      Thread Starter windorz

      (@windorz)

      After trying various things, I found that when the cf-cache-status is DYNAMIC and the cache is not being stored, changing the Edge TTL option and saving it makes the cache start hitting. Even after reverting the Edge TTL option back, it does not return to DYNAMIC.

      I believe this is likely not a problem with the plugin, but rather an issue on the Cloudflare side.

      Thread Starter windorz

      (@windorz)

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

      楽しみに待っております。

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

      Thread Starter windorz

      (@windorz)

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

      そうなのですね。

      私のように誤解されている利用者も多そうですので、設定画面に注意書きをしておいた方がよいかもしれません。

      Thread Starter windorz

      (@windorz)

      アップデートにより問題が解消しました。

      ありがとうございます。

      Thread Starter windorz

      (@windorz)

      ありがとうございます。

      ご返信いただいた内容で対応できました。

    Viewing 14 replies - 1 through 14 (of 14 total)