정식으로 올리긴 했지만,
아직 리비전 검토 기능을 제대로 갖추기 전이었는데,
아침부터 워드프레스가 테마 업데이트를 하는 바람에
리비전부터 뚝딱 뚝딱 올리기 시작해서
이제야 완성하고 테스트 끝냈다.
그리고는 이 새끈하게 잘 뽑은 리비전 검토 기능으로
업데이트된 테마 파일을 비교해서
대체 테마 업데이트가 뭐가 됐는지 보니…
테마 펑션에서 font_url을 불러 오는 항목 변수 종류가 지정 안 되어 있었는데
스트링으로 지정.
뭐, 저기에 숫자 값이 들어가서 오류를 일으킬…. 리가 없는데?
소스를 아무리 뜯어봐도 저기에 스트링 말고는 들어갈 여지가 없는데?
폰트 url이 전부 숫자라면 몰라도, url이 전부 숫자일 수는 없잖아?
아, 동일한 폴더 안에 있거나, 이름이 숫자로만 이루어진 하위 폴더 내의,
파일명이 숫자로만 이루어진 폰트 파일을 상대주소로 호출한다면 가능하겠네.
폰트 폴더 이름이 2424254598 따위고 폰트 파일 이름이 383896282.243 따위라서,
상대주소로 2424254598/383896282.243로 호출하면 개판 나겠네.
근데 폰트파일 확장자 안 맞춰줘도 인식하나?
하겠….지? 할 것 같긴 해.
그런 병신짓을 해본 적 없어서,
상상도 안 해봐서 모르긴 하지만…
………………..
css 업데이트 관련 된 날짜 어레이 처리.
이건 어차피 css 파일들이 안 바뀌었으면 안 바뀌는 거고.
readme 파일 정보 수정.
이것도 어차피 바꾼 거 없으면 안 바꾸는 거고.
메인 css 파일 버전 수정.
이것도 바꾼 거 없으면 안 바꾸는 거고.
에딧블록 css 파일 separator 섹션 구분 주석에 seperator로 오타 난 것을 수정.
…… 어. 고치는 김에 오타는 고쳐줘야지.
블록파일에 탑마진 2em 추가.
….. 음? 뭔가 출력 되는 게 줄이 틀어져서 살짝 마음에 안 드셨나봄?
블록 css 파일 separator 섹션 구분 주석에 seperator로 오타 난 것을 수정.
뭐. 그렇지. 하는 김에….
끝.
?????????????????????????
뭐?
….
그러니까,
저거 하나란 거지?
‘동일한 폴더 안에 있거나, 숫자로만 이루어진 하위 폴더 내의,
파일명이 숫자로만 이루어진 폰트 파일을 상대주소로 호출할 경우,
파일 로딩을 못하고 오류를 일으키기 때문에,
폰트 호출 라인을 텍스트로만 인식하도록 선언’
저거 하나 고쳤다는 거지?
그러니까…. (string) 띄어쓰기까지 9바이트 추가 하자고….
내가…
그러니까….
그러고는 오타나 고치자고.
아침부터.
일 제쳐두고.
리비전 시스템을 완성하느라.
시발.
그러니까.
아니 시발 폰트 파일 파일명을 숫자로만 만들고 쓰는 미친놈이 세상에 어디 있어요!?
폰트 파일을 테마 루트, 혹은 이름이 숫자로 된 하위 폴더에 두는 미친놈이 세상에 어디 있어요?
폰트 파일 따위를 호출하는데 절대 주소를 안 쓰고 상대 주소를 쓰는 미친놈이….
어, 이 정도 미친놈은 많은 거 같긴 하네.
어쨌든, 저 셋을 동시에 하고 자빠진 미친놈은 세상에 어디 있냐고!
+
이거 생각해보니까, 회원별로 폰트를 따로 쓰게,
직접 업로드 하게 하면 숫자로만 이루어진 하위폴더와 파일명은 이상하지는 않은 것 같긴 하다.
폴더명, 파일명 전부 회원 번호가 되게 된다면 말이지.
근데 그러면 대체 왜 상대주소를 써요?
아니 그러게? 대체 왜 상대주소를 씀?
테마 폴더 자체를 복사해서 다른 위치로 보낼 일이…
아… 저렇게 파일을 테마 폴더 안에 넣은 상태로
테마 버전 관리하려면 상대주소 써야하는 거구나.
난 파일 업다운할 때마다 드는 자원 아까워서
애초에 절대 주소로 파일을 올리고 절대주소로 파일을 호출하겠지만,
‘이 폰트는 이 테마에 쓰이는 거니 이 테마 폴더 아래에 있어야 해요’ 같은 식으로
사고하는 애들, 그리고 테마 버전별로 다른 폰트를 쓸 수 있게 하는 경우에….
음. 결론은 내가 처음 생각한 것에 비해서 상대적으로 덜 미친놈이긴 한데,
미친놈인건 변함 없네.
저런 식으로 사이트 구성을 왜 해-_-