이 새로운 업데이트 (1.9.4.1) 후에 Mage :: log ()가 작동하지 않습니다. 분명히 Zend_Validate_File_Extension
Mage.php의 819 라인 과 관련 이 있으며 파일 is_readable()
이 존재하기 전에 파일이 있는지 확인 합니다. 전체 log()
방법을 이전 버전으로 되돌리고 다시 작동합니다.
이 문제를보고하기 위해 Magento 팀에 연락 할 수있는 기본 채널은 무엇입니까?
이 새로운 업데이트 (1.9.4.1) 후에 Mage :: log ()가 작동하지 않습니다. 분명히 Zend_Validate_File_Extension
Mage.php의 819 라인 과 관련 이 있으며 파일 is_readable()
이 존재하기 전에 파일이 있는지 확인 합니다. 전체 log()
방법을 이전 버전으로 되돌리고 다시 작동합니다.
이 문제를보고하기 위해 Magento 팀에 연락 할 수있는 기본 채널은 무엇입니까?
답변:
공식 패치 수신 :) 여전히 공식 패치를 기다리는 중 ... :(
piotrekkaminski 님이 13 시간 전 댓글을 작성
이것은 이전 버전으로 포팅 될 현재 공식 패치입니다 (최신 버전에서 작동해야 함) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f
출처 : https://github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871
SUPEE-11086 패치와 관련하여 Magento와의 지원 및 Slack과의 연구 및 상호 작용을 기반으로 지금까지 찾은 모든 것을 요약합니다. 수행 할 수있는 작업 :
업데이트 2 :이 문제는 다음 패치 SUPEE-11155 ( https://magento.com/security/patches/supee-11155) 에서 해결되었습니다 . 패치를 적용하기 전에 항상 가능한 문제 스레드에 대한 점검- 보안 패치 SUPEE-11155-가능한 문제? Aad Mathijssen 에게 감사의 말을 전합니다.
업데이트 : 요청시 EE 버전에 대한 공식 패치가 제공됩니다. 기본적으로 Piotr Kaminski의 요지는 Magento 패치 파일로 싸여 있습니다.
app/Mage.php
패치 파일에서 변경 사항을 삭제 하십시오. 이것이 내가 지금까지 한 일입니다. Zend_Validate_File_Extension::isValid
파일 존재 검증을 편집 하고 제거하십시오. Magento LTS github- https: //github.com/OpenMage/magento-lts/pull/648에 대한 긴 토론이 있습니다 . 이 isValid
방법은 예상하지 못한 작업을 수행하므로 일부 회원은 수정을 제안합니다. 내 의견은 이것이 좋은 해결책은 아니며 예 코드는 나쁘지 만 영원히 존재했으며 사용자 정의 모듈 / 코드에서 사용될 수 있다는 것입니다. 반대로, 최악의 상황은 파일이 존재하지 않는지 확인하는 것입니다. local
코드 풀 에서 전체 클래스를 다시 작성하여 적용 할 수 있습니다 .패치를 편집하기로 선택했고 v1.1이 나오면 편집 한 패치를 되돌리고 원래 버전과 수정 후에 적용합니다. 이것은 우리의 빌드 프로세스와 내부 정책에 잘 맞으며, 여러분에게 다를 수 있습니다. 무엇을 선택하든 나중에이 패치를 빨리 적용하는 것이 좋습니다.
커뮤니티 입력에서 무언가. 새로운 Validator가 아래와 같이 Zend_Validate_File_Extension으로 사용되었습니다 :
"해결책은 패치를 편집하고 app / Mage.php에서 변경 사항을 제거하는 것입니다.이 방법을 강력히 권장하지는 않지만 상황은 매우 중요합니다."
내 임시 방편 복사하는 것이었다 lib/Zend/Validate/File/Extension.php
에 app/code/local/Zend/Validate/File/Extension.php
와 제거 의 코드의이 부분 isValid()
방법 :
// Is file readable ?
#require_once 'Zend/Loader.php';
if (!Zend_Loader::isReadable($value)) {
return $this->_throw($file, self::NOT_FOUND);
}
그것은 될 것입니다 ...
public function isValid($value, $file = null)
{
if ($file !== null) {
$info['extension'] = substr($file['name'], strrpos($file['name'], '.') + 1);
} else {
$info = pathinfo($value);
...
Magento 1.9.4.2가 릴리스되면 다시 확인합니다.
실제로 파일을 읽을 수 없거나 존재하지 않는다고해서 파일 이름이 유효하지 않은 것은 아닙니다.
핵심 코드를 변경하지 말고 다음과 같은 업데이트를 사용하는 것이 좋습니다 ( https://gist.github.com/mehdichaouch/99c67298b5a65f81219c9b69942b6fe7 )
$installer->run("
INSERT INTO `{$installer->getTable('core_config_data')}` (scope, scope_id, path, value)
VALUES ('default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv')
ON DUPLICATE KEY UPDATE value = 'log,txt,html,csv';
");
하위 폴더에 로그 파일을 작성할 수없는 또 다른 문제 (Magento 팀에서 의도적으로 발생할 수 있음)가 있습니다. 예를 들면 다음과 같습니다.
Mage::log('Some log information', Zend_Log::DEBUG, 'somefolder/anotherfolder/somelogfile.log', true);
이전 버전에서는 해당 호출이 위치에 파일을 작성했을 것입니다.
/your-magento-app-root-folder/var/log/somefolder/anotherfolder/somelogfile.log
그러나 메소드에 basename()
함수 호출 이 있기 때문에 Mage::log()
파일은 다음 위치에 작성됩니다.
/your-magento-app-root-folder/var/log/somelogfile.log
.
여기에 설명 된 코드가 있습니다 app/Mage.php
.
$file = empty($file) ?
(string) self::getConfig()->getNode('dev/log/file', Mage_Core_Model_Store::DEFAULT_CODE) : basename($file);
특히 1.9.4.1과 관련이없는 경우에도 문제는 최근에 (최신 1.9.3.x 버전 근처에서) 시작되었으며 많은 이름의 로그 파일을 처리해야 할 때 매우 성가시다. 처음에는 다른 하위 폴더에 있음).
그 코드 조각은 아마도 Magento 팀에서 의도적으로 만들어 졌기 때문에 추가 릴리스에서 수정 할 계획이 없다고 생각합니다. 초기 동작을 복원하기 위해 해킹해야합니다 ...