가끔 애드온등을 들여다 보면 문서번호를 

$oDocument->variables["document_srl"]

 

이렇게 가져오는 경우가 있는데요. variables 이 특별한 기능을 하는 것 같던데요.

 

글 쓰기시에 작성하고 있는 글의 문서번호를 가져올때 저렇게 하는 것 같더라구요. 

  • profile

    $oDocument->get('document_srl')과 똑같은 기능입니다.

     

    document_srl은 특수한 경우로 $oDocument->document_srl 이렇게 직접 접근할 수도 있지만,

    제목, 내용, 작성일자 등 다른 속성들은 항상 get()을 사용해야 합니다.

     

    variables를 사용하는 것은 get()을 건너뛰고 $oDocument 객체의 내부 구조에 직접 접근하는 셈인데,

    PHP 4.x 시절에는 객체의 내부 구조를 숨길 방법이 없었기 때문에

    아마도 get()의 존재를 모르던 한 개발자가 제목, 날짜 등의 변수에 직접 접근하려다가

    안되니까 variables를 사용해서 대강 땜빵한 것이

    수많은 개발자들의 Ctrl+C, Ctrl+V 신공으로 지금까지 내려오는 것 같네요.
     

    현재 XE 개발 상황으로 보아 내부 구조가 변경될 가능성은 극히 희박합니다만,

    원래 객체라는 것은 이렇게 쓰라고 만들어진 것이 아니기 때문에

    멀쩡한 get()을 두고 variables에 직접 접근하는 것은 권장하지 않습니다.

  • profile profile
    잘못된 사용이었군요. 저는 두가지가 뭔가 다른 특별한 것인줄 알았네요.. 그럼 정석대로 고쳐서 사용해야겠네요. 자세한 설명 감사합니다!
  • profile profile

    매뉴얼화가 안 되어 있기는 합니다만

    document.item.php를 조금만 둘러봐도 제목, 내용, 작성일자, 수정일자, 아이피 주소 등
    다양한 속성들을 다양한 포맷으로 받아올 수 있는 함수들을 제공합니다.

    예)
    내용에서 모든 태그를 제거하고 특수문자를 필터링하여 반환: getContentText()
    마지막으로 수정하거나 댓글을 단 사람의 닉네임을 반환: getLastUpdater()
    작성일자를 유닉스 시간으로 반환: getRegdateTime()
    수정일자를 RSS 등에 사용하는 표준 포맷으로 반환: getUpdateDT()

    이 좋은 것을 안 쓰고 내부적으로만 사용하는 variables라는 원재료를 직접 가져다가
    이리저리 가공해서 쓰는 서드파티 자료들을 보면... 좀 불쌍합니다 ㅠㅠ

  • profile profile

    서드파티라고 보기 어려운 XE팀의 배포 자료도 불쌍한게 많아요 ㅡㅜ
    https://github.com/xpressengine/xe-module-syndication/issues/10

    이것 한번 살펴봐주세요.

    SEO에 지대한 영향을 미치는 것에 오류가 너무 많은데 팀 내부적으로도 개선의지가 없다보니 뭐가 문제인지 문제가 있다고 해도 개선하려는 의지가 없는 상황이 안타깝습니다.

    rss,신디케이션,seo
    이런 자료들은 오류가 곧바로 사이트 노출과 활성화 등에 지대한 영향을 미치는 자료인데 오류가 너무 많아요 ㅡㅜ

    불쌍한 서드파티 자료들이에요. 여기서 말한 서드파티라는건 코어가 아니라는 의미죠.....

  • profile profile
    이건 엉터리 rss 때문에 발생하는 문제에요..

    https://xetown.com/rxe_issue/755983
  • profile profile
    네이버 신디케이션 버전이 바뀌어서 그런지, 어느 항목이 어느 항목인지 전혀 매칭이 안 되네요.
    짧은주소가 적용되지 않을 만한 부분도 딱히 안 보이고요.
  • profile profile
    그렇군요. 그럼 네이버 봇이 신디테이션에서 주소를 받아갈때 뭔가 이상하게 받아간다는건데 너무 정확하게 긴주소형식으로 가지고 가더라구요.

    글 작성 마친 후 나오는 주소 있죠 ? 그것으로 색인이 됩니다.

    제가 정확하게 확인을 한게 신디케이션을 재사용하고 나서 새롭게 추가로 중복 색인되는게 있는데 그 주소가 긴주소로 색인이 되네요.
  • profile profile
    어라....

    여기 XE타운은 제가 글을 써 봤는데 글 작성 직후 주소가 짧은 주소로 나오는데요.

    저희 사이트는 글 작성 직후 긴주소로 표시가 됩니다. 이 차이가 문제를 일으킬 수도 있겠습니다.
  • profile profile
    RSS로 잘 받아간다면 신디케이션은 꺼두어도 되지 않을까요...
  • profile profile

    테스트를 해 볼게 있어서 신디케이션으로 시도해 보고 있습니다.

    보시면 신디케이션으로 색인된 것은 이녀석들이 저장을 따로 하더라구요. 저장된 페이지라고 표시된 게 신디케이션으로 가져간 것들이에요.

     

    XE하고 지금 라이믹스하고 글 작성 직후 완성되는 글 주소가 긴주소 VS 짧은주소 이렇게 차이가 나네요.

  • profile profile

    제가 현재까지 분석한 바로는 rss로 1차적으로 긁어가는 것은 노출반영에 잘 안되는 쪽에 위치시키는 거 같아요.

    저장된 페이지라는 태그가 붙은 색인이 되어야 실제 관련 키워드로 검색시 보여준다고 의심하고 있습니다.

  • profile profile
    제 추측인데 글 작성 직후 긴주소로 보이는 게 아마 최근 1달 사이에 이렇게 코어가 바뀐게 아닌가 의심을 하고 있어요.

    구글단축주소 애드온을 사용해 왔는데 예전 글은 짧은주소로 가져갔는데 최근 글들이 긴주소로 구글에게 전달이 되었더라구요.

    그래서 어제 구글단축주소 애드온은 짧은 주소로 가져가게 고쳐 놓았습니다. 애드온 코드가 현재 머물고 있는 url을 그대로 가져가게 되어있더라구요.
  • profile

    $oDocument = Context::get('oDocument'); 후에 $oDocument를 디버그 프린트 해보시면 variables에 배열값들이 보이실 겁니다.
    variables에 특별한 기능은 없고 그냥 변수 입니다.
    $tmp = 1230;
    echo number_format($tmp);
    위에서 $tmp값을 echo해주는 부분과 비슷하다고 보시면 됩니다.

    뭐 variables을 직접 사용한다고 잘못되었다고는 생각하지 않습니다. 그냥 변수를 가져와서 사용하는 것 이니까요.
    DB에서 가져온 거의 가공되지않은 값, 말 그대로 날것을 가져와서 내가 직접 가공해서 사용하냐 가공 된것중에 맘에드는것을 사용하느냐의 문제 입니다.
    다만 XE메뉴얼이 많이 부족해서 어떤어떤 가공품을 파는지 알수가 없는게 문제점이긴 합니다.

    저 같은 경우도 그냥 php가 더 편하기 때문에 굳이 xe의 함수가 뭐가 있나 찾아보기 보다는 제가 직접 로직을 구성하는 경우가 더 많습니다.

    기진곰님 말씀처럼 XE에서 제공하는 함수를 통해서 원하는 값을 얻어서 사용하는것이 좋기는 합니다. 내부 사정에 의해 변수명은 언제든지 바뀔수가 있으니까요.

  • profile profile
    코알못이 설명을 듣고 나니 조금 이해가 가네요 ㅋㅋ 감사합니다.