SuiteCRM v7.10.29 自定义API v4.1访问报HTTP500无错误日志问题

在SuiteCRM v7.10.29环境开发自定义v4.1版本API，按照公开的遗留API扩展规则完成配置后，访问路径{CRM站点根地址}/custom/service/v4_1_custom时收到HTTP 500错误，且PHP层面的error_log、SuiteCRM自身的SuiteCRM.log文件均无对应报错记录。

已完成的自定义配置代码 #

1. 自定义服务目录下的registry.php内容

   <?php
   require_once('service/v4_1/registry.php');
   class registry_v4_1_custom extends registry_v4_1
   {
       protected function registerFunction()
       {
           parent::registerFunction();
           $this->serviceClass->registerFunction('test', array(), array());
       }
   }
   

2. 自定义服务目录下的SugarWebServiceImplv4_1_custom.php内容

   <?php
   if(!defined('sugarEntry')) define('sugarEntry', true);
   require_once('service/v4_1/SugarWebServiceImplv4_1.php');
   class SugarWebServiceImplv4_1_custom extends SugarWebServiceImplv4_1
   {
       /**
        * @return string
        */
       public function test()
       {
           LoggerManager::getLogger()->warn('SugerWebServiceImplv4_1_custom test()');
           return ("Test Worked");
       }
   }
   

常见触发500且无日志的原因及修复方案 #

• 自定义服务目录文件不全
  仅在目录下放置两个自定义类文件无法完成请求路由，需要从原生service/v4_1目录下将server.php、.htaccess入口文件完整复制到custom/service/v4_1_custom/目录下。这种目录缺失场景下，请求会在SuiteCRM初始化流程前触发PHP致命错误，此时应用日志模块还未完成加载，因此不会在SuiteCRM.log和error_log中留下任何记录。
• 服务注册参数不合法
  当前代码中空参数调用registerFunction()的写法不符合v4.1 SOAP服务的定义规则，该方法需要明确传入方法的入参、返回值的SOAP类型定义，缺省参数会导致服务初始化时直接抛出致命错误，同样因为日志模块未加载完成不会产生日志记录。正确的注册写法需要匹配方法的实际参数结构，示例为：

  $this->serviceClass->registerFunction(
      'test',
      array('session' => 'xsd:string'),
      array('return' => 'xsd:string')
  );
  

• 类文件路径与命名不匹配自动加载规则
  自定义实现类的文件名必须和类名完全一致，即严格命名为SugarWebServiceImplv4_1_custom.php，不能存在拼写偏差；同时要确保sugarEntry常量的定义语句在所有require逻辑之前，避免触发未授权访问类的致命错误。
• 临时开启PHP错误输出定位问题
  由于报错发生在SuiteCRM日志模块初始化完成前，可以临时在自定义目录下的server.php文件最顶部添加两行配置：

  ini_set('display_errors', 1);
  error_reporting(E_ALL);
  

  重新访问接口即可看到具体的500错误原因，定位修复完成后需删除这两行配置，避免生产环境泄露敏感信息。
• 目录权限配置异常
  custom/service/v4_1_custom/目录下所有文件的权限需要和原生service目录下的文件权限保持一致，确保web运行用户拥有目录及文件的读取权限，权限缺失触发的500错误同样不会被应用日志捕获。

内容的提问来源于stack exchange，提问作者David Hash