Distributor: 승인 실패 // 리퍼러 URL 자르기

@superbuggy 디스트리뷰터에 오신 것을 환영하며 피드백에 감사드립니다! 곧 있을 1.5.0 릴리스에서 검토할 수 있도록 태그를 지정하고 있으므로 업데이트를 계속 지켜봐 주시기 바랍니다.

@dkotter 끌어오기 콘텐츠 페이지에 대한 개선 사항으로 이 문제가 해결될 가능성이 있습니까?

@superbuggy 감사합니다. 지금은 리퍼러/리퍼러 URL을 자르는 것이 확실히 합리적이라고 생각합니다. 사이트 URL로 다시 자르는 것이 더 나은지 아니면 현재 관리 페이지 URL을 사용하는 것이 더 나은지 조사 중입니다. 또한 제외된 게시물을 쿼리 문자열에 밀어 넣는 것을 중단하고(실제 기능은 그대로 유지) 대신 저장된 옵션을 참조하는 것이 장기적으로 더 나은지 여부에 대한 귀하의 의견도 듣고 싶습니다.

@dkotter 의 도움으로 이것을 좀 더 파고 $this->sync_log = range( 0, 400 ) in PullListTable::prepare_items() 를 설정하여 이것을 쉽게 실행할 수 있습니다. 수백 개의 게시물을 끌어오기가 정말 쉽기 때문에 이 문제를 수정해야 합니다. 이 방식으로 계속 진행하면 post max vars로 치명적인 문제를 일으킬 것입니다. 이미 가져온 게시물이 제외되지 않기 때문에 이 변수를 완전히 삭제하고 싶지는 않지만 완벽한 수정은 보이지 않습니다. 여기에서 시도할 수 있는 두 가지 방법이 있습니다.

1. 1.5의 경우 위의 방법에서 $sync_log 를 임의의 숫자(아마도 200?)로 잘라서 최소한 끌어올 콘텐츠의 처음 몇 페이지가 여전히 정확하고 그 다음에는 회색으로 표시되는 과거의 모든 페이지를 가져옵니다. 페이지 매김이 여전히 정확하도록 목록 테이블(로컬 동기화 로그와 비교). 그렇지 않으면 페이지당 게시물보다 눈에 띄게 적은 항목이 있거나 전혀 없는 페이지가 있어 사용자에게 혼란을 줄 위험이 있습니다. 기본 상태에서 페이지 매김에서 꽤 멀리 되돌아가는 것에 대해 이야기하고 있다는 점을 감안할 때 합리적인 UX라고 생각합니다. 검색 결과가 더 일찍 회색으로 표시된 행을 표시하지만 실제로 끌어오기에 사용할 수 있도록 하지 않는 한 제 생각에는 괜찮아.

2. 향후 릴리스(1.6 또는 2.0)의 경우 인증된 연결을 위해 원격 사이트에 동기화 로그를 저장하는 방법(아직 저장하지 않은 경우)과 대신 결과를 반환하는 데 사용하는 방법을 참조하세요. 원격 사이트 URL 또는 기타의 해시를 사용하여 옵션에 저장해야 할 것 같습니다. 인증되지 않은 연결의 경우 여전히 원래 수정 사항으로 대체됩니다.

어떤 생각/이의가 있습니까? 지금 PR을 하고 있습니다.

@superbuggy 이 문제를 해결하기 위해 #431을 열었습니다. 접근 방식 및/또는 UI 결과와 이것이 귀하에게 미치는 영향을 살펴보고 의견을 제시할 수 있다면.

#431을 병합하기 전에 더 많은 실사를 하고 돌아옵니다. @cmmarslender 가 어시스트에 있는 경우 헤더 크기 문제가 아니라 414 Request-URI Too Large 문제인 것 같습니다. 우리 중 누구도 인증 헤더 외에 전송되는 헤더를 재현할 수 없습니다. 귀하가 본 특정 오류에 대해 직접 연결(Slack 또는 귀하가 가지고 있는 것)하려는 경우 리퍼러 문제를 추적하는 데 도움을 드릴 수 있어서 여전히 기쁩니다. 하지만 현재로서는 제 PR이 실제로 올바른 첫 번째 단계 수정이라고 생각합니다.

좋은 소리! 우리의 경우 핫픽스로 메인 테마의 functions.php 에 위의 코드 블록을 추가했습니다. 저는 주로 JS 개발자이고 WP에 새로운 사람이므로 WP가 리퍼러 URL을 사용하는 방법에 대한 세부적이고 낮은 수준의 이해가 아직 없지만 414 문제는 우리가 만난 문제. 추가 조치로 헤더를 최대 32k까지 허용하도록 NGINX 구성을 변경했습니다.

리모컨의 스토리 제외 목록도 이해가 됩니다. 사이트가 이미 가져온 게시물을 추적해야 한다는 것은 직관적으로 느껴집니다. 이것은 옵션 테이블에 저장될 수 있습니까?

응답해주셔서 감사합니다!