문제

우리는 2년 넘게 운영해온 LEMP 서버에 Magento 웹사이트(1.6.2)를 가지고 있습니다.최근에 우리는 몇 가지 사항을 변경했습니다.

  • 전체 사이트를 HTTPS로 변경했습니다.
  • 새로운 카테고리를 모두 만들고 이전 카테고리를 제거했지만 동일한 제품을 유지했습니다.

  • 양식으로 서버 리디렉션이 생성되었습니다.

    location/this/old/category {rewrite ^(this/old/category)/? (.*) $ https://oursite.co.uk/new/category$2 영구;}

이는 카테고리 페이지와 그 안에 있는 모든 제품 모두에 적용되며 우리는 모두 훌륭하다고 생각했습니다!

그러나 Google WMT는 팔로우되지 않은 URL을 많이 표시하기 시작하여 조사한 결과 많은 제품이 이상하게 리디렉션되어 리디렉션 루프가 발생하는 것을 발견했습니다.

Chrome의 네트워크 탭에서 특정 제품의 이전 URL로 이동하면 서버 리디렉션이 시작되고 적절한 응답을 받는 것을 볼 수 있습니다.그러나 다음과 같은 형식을 취하는 (무한해 보이는) 리디렉션이 이어집니다.

무작위/오래된/카테고리/랜덤/오래된/카테고리/랜덤/오래된/카테고리/랜덤/오래된/카테고리/랜덤/오래된/카테고리/랜덤/오래된/카테고리/랜덤/오래된/카테고리/랜덤/오래된/카테고리/랜덤/ 이전/카테고리/제품 이름

기본적으로 각 요청에 대해 "무작위/오래된/카테고리"를 계속 추가합니다.우리 서버 호스트는 a) Magento(그래서 문제가 아님)와 b) 앞에 슬래시가 있어야 한다는 점을 단호하게 주장합니다.

이 문제를 일으키는 설정을 찾을 수 없습니다.

  • "웹 서버 리디렉션 사용"이 예로 설정되어 있습니다.
  • 나는 영향을 받은 URL 중 하나가 발생하는지 찾기 위해 데이터베이스의 텍스트 덤프에서 "grep"을 사용했습니다. (기쁨이 없었고 포인트 1로 인해 이것이 사실이 아닐 것이라고 확신합니다.)
  • 또한 미세한 칫솔을 사용하여 관리 영역을 수동으로 살펴봤지만 가능한 원인을 찾을 수 없습니다.

이것이 충분한 정보였기를 바랍니다.서버가 아닌 다른 곳에서 리디렉션이 발생할 수 있는 위치를 알려줄 수 있는 사람이 있나요?

업데이트:

Douglas가 지적했듯이 새 URL도 리디렉션되는 것처럼 보이지만 해당 사이트(및 기타)의 .conf 파일을 확인했는데 이를 유발하는 규칙은 없습니다.

업데이트 2:

나는 약간의 돌파구를 찾았습니다.Magento가 리디렉션된 카테고리에서 제품을 찾을 수 없는 경우 루프를 계속 돌게 되는 것 같습니다.단지 404가 아닌 왜 이런 일을 하는지는 나에게 미스터리이므로 그에 대한 도움도 좋을 것입니다!

업데이트3:

3년, 서버 이전, 많은 경험, 그리고 나중에 CE 1.9.3.8로의 업그레이드를 통해 획기적인 발전을 이루었다고 생각합니다!

이제 나는 이것이 Magento 라우팅 문제라는 것을 확실히 알고 있습니다. die(); index.php의 라인에서 리디렉션 루프가 발생하지 않습니다.

나는 이 로깅 코드(인터넷의 여러 위치에서 찾을 수 있음)를 Mage_Core_Controller_Varien_Front 수업:

Mage::log('----Matching routers------------------------------');
Mage::log('Total ' . count($this->_routers) . ': ' . implode(', ', 
array_keys($this->_routers)));
while (!$request->isDispatched() && $i++<100) {
    Mage::log('- Iteration ' . $i);
    $requestData = array(
        'path_info' => $request->getPathInfo(),
        'module' => $request->getModuleName(),
        'action' => $request->getActionName(),
        'controller' => $request->getControllerName(),
        'controller_module' => $request->getControllerModule(),
        'route' => $request->getRouteName()
    );

    $st = '';
    foreach ($requestData as $key => $val) {
        $st .= "[{$key}={$val}]";
    }
    Mage::log('Request: ' . $st);
    foreach ($this->_routers as $name => $router) {
        if ($router->match($this->getRequest())) {
            Mage::log('Matched by "' . $name . '" router, class ' . 
    get_class($router));
            break;
        }
    }
}

이 수업의 코드에 대한 약간의 조사와 이해를 통해;Magento는 다음 작업을 담당할 시스템(코어 또는 모듈)에서 라우터를 찾습니다. $request 일치하면 발송 신호를 보냅니다.

위의 로깅 코드를 사용하면 라우터 목록을 얻었지만 라우터 목록에는 정보가 없습니다. $requestData 라우터가 결코 디스패치되지 않았음을 암시하는 배열입니다.

나열된 각 라우터에서 나는 컨트롤러/Router.php 파일을 발견하고 match(Zend_Controller_Request_Http $request) 방법.이 메서드가 true(일치를 나타냄)를 반환하기 전 줄에 간단한 에코 줄(예: G)을 추가했습니다.

echo "matched in the xxx module"; die();

이로 인해 책임이 있는 라우터를 찾았고 저는 의심하다 이는 일치 후 요청을 전달하지 않으므로 계속 반복됩니다.담당 모듈은 MageWorx_SeoSuite, 온라인에서 이에 대한 참조를 찾을 수 없기 때문에 과거에 제3자에 의해 수정된 것으로 의심됩니다.추가 조사가 필요하며 가능한 한 빨리 조사하겠습니다.

도움이 되었습니까?

해결책

그것은 match(Zend_Controller_Request_Http $request) MageWorx_SeoSuite 라우터에는 해결된 스위치 문이 있었습니다. CMS, Rss, Category, Category_layer 그리고 다른 노선.

문제는 default (읽다:제품) 이 스위치 문의 경우입니다.이는 매우 독특한 상황이었습니다(왜 소수의 제품에만 영향을 미쳤는지를 설명합니다).

그것은 것;

  • URL의 끝(예:제품 urlKey) 다시 작성했고 그렇지 않다면;
  • 해당 제품의 최하위 카테고리에 재작성이 있는지 확인하고 그렇지 않다면;
  • ID별로 제품을 로드하고 다음에서 표준 URL을 가져옵니다. MageWorx_SeoSuite 도우미 클래스;
  • 표준 URL로 리디렉션을 보내고 구성 설정에 따라 이전에 정의된 HTTP 응답 코드를 사용하여 응답을 업데이트합니다.
  • exit();

처음 두 조건문 중 하나라도 다음과 같은 경우 거짓;그 방법은 return false; (즉:라우터가 일치하지 않습니다).그러나 처음 두 조건문이 모두 다음과 같이 평가된 경우 true 일부 다른 검사가 통과되었습니다(표준 URL이 비어 있지 않은 등).명령문은 리디렉션을 보낸 다음 간단히 exit();.

나는 전체 라우팅 방법을 처음 접했지만 여기에는 몇 가지 문제가 있다고 믿습니다.

  1. 이 메서드는 조건문의 모든 경로에 대해 부울을 반환하지 않았습니다(예: 제품 및 해당 제품의 중간 카테고리에 재작성이 없는 경우).
  2. 메소드는 "일치"하지만 결코 일치하지 않습니다. dispatch'디.
  3. 이것은 나의 제한된 (학부) 지식을 기반으로 하지만:이건 정말 나쁜 소프트웨어 디자인처럼 보입니다.

나는 사실 없이 MageWorx를 결정하고 싶지 않기 때문에 지금 이 점을 지적할 가치가 있습니다.나는 이 코드가 지난 5년 동안 변경되었다고 확신합니다(여러 제3자 회사가 책임을 졌을 수 있음).

요약하자면:나는 주석을 달았다. default: Magento 코어가 책임을 지도록 스위치의 Case 문을 작성하세요.범인 URL은 이제 404, no-route 페이지는 모두 오래되고 존재하지 않는 경로이므로 이상적입니다.나는 일반적으로 이런 우연한 방식으로 모듈 코드를 변경하지 않지만 이를 잘 문서화했으며 다행스럽게도 웹 사이트의 새 버전이 개발 중이므로 "수정"은 일시적입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 magento.stackexchange
scroll top