libs 폴더 내의 오래된 라이브러리들 정리

[kijin]

libs 폴더 내에는 XE 초창기 이후 거의 업데이트되지 않은 라이브러리들이 몇 개 들어 있습니다. composer와 호환되지도 않고, 어떤 보안 취약점이 있는지도 모르고, PHP 버전이 자꾸 올라가면서 언제 작동을 멈춰버릴지 모릅니다.

그래서 libs 폴더 내의 라이브러리들을 싹 정리해 버렸습니다.

• FirePHP : composer로 설치하도록 변경
• HTTP_Request : composer로 설치한 rmccue/Requests로 교체
  • HTTP_Request를 composer로 설치할 수도 있으나, composer로 설치할 경우 오류가 발생하는 것을 확인했습니다.
  • HTTP_Request를 사용하는 FileHandler::getRemoteResource() 메소드를 리팩토링하여, 새 라이브러리를 사용하면서도 동일한 기능을 수행하도록 만들었습니다.
  • 더이상 필요없게 된 requirePear() 함수는 내용을 모두 지우고 껍데기만 남겨두었습니다.
• PHPMailer : composer로 설치한 SwiftMailer로 교체
  • Mail 클래스를 완전히 교체하였습니다. 여기에 필요한 코드는 고급 메일 발송 모듈에서 가져왔으며, 해당 부분의 라이선스를 저작권자 직권으로 GPLv2에서 LGPL로 변경했습니다. (고급 메일 발송 모듈의 나머지 부분에는 여전히 GPLv2 라이선스가 적용됩니다.)
  • 기존의 Mail 클래스가 비공식적으로 지원하던 Gmail과 SMTP도 이제 제대로 지원합니다.
  • 추후 기능 확장 예정 (RhymiX의 라이선스 정책이 변수)
• idna_convert : 최근 PHP에 내장되어 있는 idn_to_utf8() 등의 함수로 대체
  • 함수가 존재하지 않는 경우 true/punycode 라이브러리를 사용합니다.
• ftp, tar : 교체가 쉽지 않을 것 같아 일단 남겨둠
  • common/libraries 폴더로 옮기고 오토로딩을 적용했습니다.
  • 오토로딩을 사용하지 않고 직접 인클루드하는 코드를 모두 삭제했습니다.

자, 이제 코어에서 제공하는 클래스와 메소드를 사용하지 않고 libs 폴더의 라이브러리를 직접 인클루드하여 사용하던 나쁜 어린이 호환성 떨어지는 서드파티 자료들을 찾아봅시다!

(직접 인클루드하여 사용하는 기존 자료가 있더라도 업데이트 과정에서 libs 폴더를 삭제하지 않으면 모두 그대로 남을 테니 상관없을 거라는 생각이 들긴 합니다.)

[conory]

👍
깔끔하게 좋네요..ㅎㅎ 제 모듈에서는 문제가 발생하지않았습니다!

[bjrambo]

출석부는 어쩌면 문제점이 있을지도..?(1.4버전 기반대인 코드가 아직 남아있습니다..)

[conory]

@qw5414 libs 디렉토리에서 라이브러리를 직접적으로 불러오지만 않으면 됩니다. 그런 자료는 보지못했네요..

[bjrambo]

@conory 그렇다면 가능성 희박

[kijin]

@qw5414 직접 불러오는 자료가 있더라도 업데이트 과정에서 libs 폴더를 삭제하지만 않으면 상관없습니다. (zip으로 설치하든 changed로 설치하든 기존에 있던 폴더가 삭제되지는 않거든요.)

파일이 한두 개 남았는데도 완전히 다른 경로로 옮겨버린 이유가 그거예요. 기존에 libs 폴더를 쓰던 사이트에는 아무런 영향을 미치지 않도록... 심지어 zip으로 설치한 사이트가 나중에 git으로 전환하더라도 .gitignore에 libs 폴더를 등록해 놓았기 때문에 완전히 무시됩니다.