【问题标题】:Strict Standards: Declaration of ' ' should be compatible with ' '严格标准:''的声明应与''兼容
【发布时间】:2013-06-18 12:38:49
【问题描述】:

我刚刚在 PHP 5.4 上安装了 woocommerce 2.0(在 Wordpress 上),我得到了这个:

严格标准:声明 WC_Gateway_BACS::process_payment() 应该与 WC_Payment_Gateway::process_payment() 兼容 D:\my\path\to\htdocs\wordpress\plugins\woocommerce\classes\gateways\bacs\class-wc-gateway-bacs.php 在线...

查看文件发现WC_Payment_Gateway没有process_payment()的方法。 我需要知道如何解决这个问题(不是通过设置error_reporting())。

什么是 PHP 中的严格标准
在什么情况下我们会得到这个错误?

【问题讨论】:

    标签: php wordpress woocommerce


    【解决方案1】:

    引用自 PHP 手册

    在 PHP 5 中提供了一个新的错误级别 E_STRICT。在 PHP 5.4.0 之前,E_STRICT 不包含在 E_ALL 中,因此您必须在 >PHP 提供有助于确保最佳互操作性和转发 > 代码兼容性的建议。这些消息可能包括诸如静态调用非静态 >methods、在兼容的类定义中定义属性,同时在 >a used trait 中定义的内容,以及在 PHP 5.3 之前,一些不推荐使用的特性会发出 E_STRICT 错误 >例如通过引用分配对象实例化。

    您收到此错误是因为 WC_Gateway_BACS::process_payment() 声明与 WC_Payment_Gateway::process_payment() 不同(可能参数数量不同等) .如果 WC_Payment_Gateway 没有方法 process_payment,请检查它的父类:)

    此外,如果您想禁用 STRICT 错误,请将 ^ E_STRICT 添加到您的错误报告配置中,例如:

    error_reporting(E_ALL ^ E_STRICT);
    

    【讨论】:

      【解决方案2】:

      WC_Payment_Gatewayabstract-wc-payment-gateway.php中定义并声明了一个方法

      function process_payment() {}
      

      WC_Gateway_BACS 将其定义为

      function process_payment( $order_id ) { ...
      

      (也许你混淆了 WC_Payment_Gateway 和 WC_Payment_Gateways)。

      因此,不同的签名(0 个参数与 1 个参数)-> 严格错误。
      由于它似乎*总是与一个参数一起使用,您可以更改

      function process_payment() {}
      

      function process_payment($order_id) {}
      

      (*) 请记住,我是在最后五分钟才知道 woocommerce,所以不要相信我的话。

      【讨论】:

      【解决方案3】:

      当您在父类和子类中使用相同的函数,但子类需要参数而父类不需要时,您将收到Strict Standards 错误。

      示例

      经理:

      public function getAtPosition($position)
      {
          foreach ($this->getList() as $obj)
          {
              if ($obj->getPosition() == $position)
                  return $obj;
          }
      
          return null;
      }
      

      MenuManager 扩展了 Manager:

      public function getAtPosition($position, $parent)
      {
          foreach ($this->getList() as $m)
          {
              if ($m->getParent() == $parent && $m->getPosition() == $position)
                  return $m;
          }
      
          return null;
      }
      

      这个例子会产生错误:

      严格的标准:MenuManager::getAtPosition() 的声明应该 兼容 Manager::getAtPosition($position)

      因为我们没有相同的函数参数,所以让我们欺骗这个并添加参数,即使我们没有使用它们!

      经理:

      public function getAtPosition($position, $dummy = 0) // Dummy to avoid Strict standards errors
      {
          foreach ($this->getList() as $obj)
          {
              if ($obj->getPosition() == $position)
                  return $obj;
          }
      
          return null;
      }
      

      MenuManager 扩展了 Manager:

      public function getAtPosition($position, $parent = 0)
      {
          foreach ($this->getList() as $m)
          {
              if ($m->getParent() == $parent && $m->getPosition() == $position)
                  return $m;
          }
      
          return null;
      }
      

      唯一需要注意的是,当使用 getAtPosition() from MenuManager.class.php 时,请确保您实际上发送了 2 个参数,因为我们必须声明 $parent = 0 以匹配父级的声明。

      每个扩展 Manager 且不包含 getAtPosition() 的类都将使用来自 Manager 的方法。

      如果在子类中声明,php 将使用子类的方法而不是父类的方法。 PHP 中没有overloading,所以我就是这样解决它的,直到它被正确实现。

      【讨论】:

        【解决方案4】:

        这是一个更好的答案 - https://stackoverflow.com/a/9243127/2165415

        例如,
        parentClass::customMethod($thing = false)
        childClass::customMethod($thing)
        所以,当你为类调用customMethod() 时,可能会触发错误,因为子方法的第一个参数没有定义默认值。

        【讨论】:

          【解决方案5】:

          如果您想在不关闭任何错误的情况下保持 OOP 表单,您还可以:

          class A
          {
              public function foo() {
                  ;
              }
          }
          class B extends A
          {
              /*instead of : 
              public function foo($a, $b, $c) {*/
              public function foo() {
                  list($a, $b, $c) = func_get_args();
                  // ...
          
              }
          }
          

          【讨论】:

          • 丑得要命,但有时需要。
          • 这永远不需要。
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2014-02-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多