뭐, 아는 사람은 알겠고,
짐작하고 있는 사람은 짐작하고 있었겠지만,
그동안 Precious Phraſe는 베타 버전으로 제공되고 있었습니다.
페이지에 장식 요소가 하나도 없었던 것은
내가 워드프레스와 이 테마의 구조에 완전히 익숙해지고,
6천줄에 달하는 css를 완전히 제대로 제어할 수 있다는 확신이 들 때까지
그냥 흰 페이지로 내버려두는 게 낫겠다는 생각에서였어요.

그리고 웹폰트를 적용하느라 css를 만지면서,
이제는 베타 딱지를 떼어도 되겠다는 확신이 들었어요.
그래서 지금 이 시점부터 Precious Phraſe 워드프레스판은
정식버전입니다.

뭐… 달라지는 건 딱히 없겠지만요.

+ 아, 달라지는 게 있긴 있네요. 이게 마지막 개발노트입니다.
앞으로는 수정이 표면적인 영역 보다는 기술적인 영역 위주로 될 것이기 때문에
더 이상 수정 사항이 있어도 패치노트를 써서 알리지 않을 거예요.

이글루스판 Precious Phraſe는 연노랑색(#f7f7f1) 바탕색을 썼고,
사실 링크색인 #06a도 그 바탕색의 보색으로 조정된 색이었죠.
워드프레스판의 바탕색은 좀 더 #06a의 보색에 가까운
연주황색(#f8f4ec)으로 결정했어요.
(+ #fffcf4로 조정했습니다.)
조금 붉어졌고, 조금 어두워졌지만,
어쩄거나 Precious Phraſe의 근본인 난색 바탕색으로 돌아오니
이제 정말로 내 블로그 같네요.

1. 그동안 쌓여 있던 자잘한 수정 요망 사항들이 수정 되었습니다.

1-1. 포스틀리스트와 스크롤 버튼이 모바일에 대응하도록 약간의 마진을 뒀습니다.
기본적으로 모바일에서의 사용은 신경 쓰지 않는다는 게 방침이지만,
굳이, 약간의 마진 수정 정도를 하지 않을 이유도 없어서 했어요.
하지만 버튼 반투명화나 버튼 크기를 반응형으로 조정하는 등의
적극적인 모바일 대응은 하지 않을 겁니다.
불편해요? 모바일에서 보지 마세요.
이 블로그는 결코 모바일에서 보는 것을 추천하지 않습니다.
모바일 활용의 모든 요소가 이 블로그의 운영 방침과 대치 돼요.
내가 모바일 접속 관리 경찰봉을 들고 모바일 접속자 뚝배기를 깨고 다니는 거야 불가능하고,
특정 접속을 차단하는 방식 역시 내 운영 방침, 혹은 http에 대한 신앙과 대치 되니
(우회하는 것도 일도 아니니-_-)
‘모바일 접속을 금지’하는 것 따위는 하지 않지만,
할 수 있다면, 했을 겁니다.
+
모바일에서 포스틀리스트와 스크롤 버튼이 표시되지 않도록 수정했습니다.
만약 기존의 포스틀리스트를 켜놔서 포스틀리스트가 계속 나타나는 경우,
기존의 포스틀리스트 토글 버튼 자리에 놓인 퍼지 버튼을 누르면
정상적으로 포스틀리스트가 삭제됩니다.
기능이 정상 작동하지 않는 경우 쿠키를 삭제하거나
와이드뷰 데스크탑 모드로 전환 후 포스틀리스트 토글 버튼을 눌러 포스틀리스트를 꺼주세요.
다시 말하지만 난 모바일 사용을 신경 쓰지 않으며,
이러한 기능의 추가나 삭제로 인해 모바일 사용 환경이 꼬이는 것에
매번 대응을 하지는 않을 겁니다.

1-2. 카테고리와 작성일을 제목 아래로 끌어올렸습니다.
아직 css 스타일은 고민 중이라서 제대로 정비 안 했지만,
어쩄거나 스크립트는 손 봐 놨어요.

1-3. 포스틀리스트 버튼과 포스틀리스트 메뉴를 살짝 정비했습니다.
나열하기 민망할 정도로 자잘한 오류들이 여럿 수정 되었습니다.
아직 정비되지 않은 알려진 오류: 현재 포스틀리스트 링크를 새로고침하면
페이지 내부 오브젝트의 로드 순서가 어긋나는 경우
지정하지 않은 다른 포스트 위치로 이동 되는 문제가 있습니다.
꼼꼼하게 스크립트를 손 봐서 먼저 로드해야하는 파트를
앞으로 옮겨 정렬하면 해결할 수 있는 문제이지만,
굳이 이 정도 소소한 오류를 손 보기 위해
스크립트 순서를 갈아 엎는 미친 짓은 하지 않을 겁니다.

1-4. 폰트가 정비 됐습니다.
원래대로 팔라티노 리노타입과 세고UI, 맑은 고딕을 우선 사용하도록 바꿨고,
해당 폰트가 없는 경우 노토로 지정했습니다.
다만, 한글 세리프는 이롭게 바탕체가 설치되어 있는 경우
해당 폰트를 사용합니다만….
어떤 시스템에서도 기본 폰트가 아니니 웬만해선 신경 안 써도 됩니다.
한글 세리프로도 맑은 고딕을 쓰게 하면서
한글 세리프 폰트를 아예 없애는 것을 고민했는데,
언어별로 폰트 영역을 지정하는 것보다는
그냥 한글 세리프 폰트는 자기 좋을 대로 쓰는 게 낫겠다 싶어서
그냥 serif로 내버려뒀어요.
시스템에 맑은 고딕이 없다면 시스템에 지정된 한글 세리프 폰트로 출력 될 겁니다.
제발 “본문 가시성이 너무 떨어져요. 폰트 좀 바꿔 주세요” 따위의 말 좀 하지마세요.
네가(혹은 웹브라우저 기본 설정이) 지정한 네 기본 세리프 폰트라고요.
세리프 폰트는 원래 본문을 읽기 쉽게 하기 위해 개발 된 폰트예요.
네가 그 가독성이 높아야만 하는
한글 기본 세리프 폰트를 ㅈ같이 가시성이 떨어지는 걸 쓰고 자빠진 게 문제니까,
제발 기본 세리프 폰트를 바꾸라고요.

+
한글 기본 세리프 폰트 엉터리로 지정해놓고 나한테 ㅈㄹ하는 거
아무래도 개같아서 이롭게 바탕체를 웹 폰트로 적용했습니다.
웹 폰트는 내 개발 철학에 정면으로 반하는 거긴 하지만…
뭐 내 리소스 먹는 것도 아니니까.

2. 댐드 시네이터와 project.lejuel이 완전 독립 페이지로 나갑니다.

블로그 페이지 어딘가에 흔적이 남아 있을지도 모르지만
이미 다 비워서 내보냈어요.
관련 권한 플러그인 몇 개도 같이 삭제했기 때문에
서버 속도에 미세한 향상이 있습니다.
(10-15% 정도 나오니 미세하진 않네요.)
하지만 내가 자원이 남는데 엉뚱한데 낭비하지 않을 리가 없으니
곧 다시 미세하게 느려져서 원상 복구 될 겁니다.

3. 메인 페이지 커멘트 로딩에 대해서는 고민 중입니다.

스크립트는 준비가 됐는데,
현재처럼 커멘트를 보고 하려면 싱글 페이지로 들어가야 하는 시스템이
좀 더 장점이 있는 것 같아서 고민 중이에요.
뭐 페이지 로딩에서 자원을 적게 먹는다도 장점이긴 한데,
이 규모의 블로그에서는 사실 신경 안 써도 되는 수준이긴 하죠.
내가 주목하는 장점은 지나가다 뻘 커멘트 하는 비중이 확실히 줄었다는 거예요.

1. 메뉴 스크롤을 최소화 하기 위해 메뉴 목록 구성과 사이트 아이덴티티 요소에 자잘한 수정이 있었습니다. 메뉴가 다 접혀 있는 상태에서 스크롤이 필요 없는 높이의 창으로 사용할 것을 추천하지만 굳이 그렇게 하지 않아도 딱히 별 차이는 없습니다.

2. 우측 하단에 페이지 맨 위로 스크롤, 맨 아래로 스크롤, 좌우 중하단에 이전 페이지 다음 페이지 플로팅 버튼을 추가했습니다. 네, 알았어요. 가벼운 플로팅 메뉴 플러그인 그만 추천해도 돼요.
2-1. 이전 페이지 다음 페이지 플로팅 버튼이 있으니 맨 아래로가 생각보다 필요 없는 느낌이라서 맨 위로 / 현재 문서 길이의 25% 위로 스크롤 / 현재 문서 길이의 25% 아래로 스크롤로 우하단 플로팅 메뉴를 변경했습니다.

+
2-x. 저 스크롤 메뉴가 가볍긴 한데 진짜 주먹구구로 만들어져 있어서 자바스크립트를 미친듯이 손 봤다. 어…. 이럴거면 그냥 내가 만들 걸 그랬나? 사실 제일 만들고 싶은 건 페이지에서 포스트 엔트리를 받아서 다음 포스트까지 스크롤 하는 기능인데, 이걸 하려면 리스트업 된 포스트에 순서에 맞춰 임시 개별 클래스를 지정하는 플러그인을 깔아야 한다. 당연히 저것만으로도 자원 낭비인데, 저런 플러그인들이 이것저것 엮인게 많아서 너무 무겁다. 아니면 포스트 리스트업하듯이 메뉴도 리스트업 해서 각 포스트 바로가기 버튼을 만드는 방법도 있는데…. 그럼 개 난잡하잖아.
++
임시 개별 클래스를 지정하는 게 아니라, 그냥 퍼머링크를 id로 받아 쓰도록 만들어봤더니 개 깔끔하게 잘 돌아가긴 한다. 문제는 이제 저 리스트를 어디다 배치하냐는 거다. 깔끔한 위치 잡기는 불가능해 보인다.
+++
일단 우상단에 앵커 토글로 붙여놓긴 했는데,
개 난잡하다. 일단 이전페이지 다음페이지 플로팅은 치워놓고 더 테스트해봐야겠다.
++++
뭔가 직관적인 기능 설명이 있어야 할텐데
쉽지 않다.

1. 검색 엔진 수집 정책이 모두 거부에서 모두 허용으로 바뀝니다.
네, 원래 이 서버가 정상 궤도에 오르는 것을 기다리면서 기존 사이트 정보 찌꺼기들이 삭제되도록 막아둔 거라서, 이제는 풀어놓습니다. 원래대로 다음 검색은 막으려고 했는데, 다음 검색 봇 인식명이 기억 안 나는데 찾아보기 귀찮아서 안 막을게요. 물론 또 ‘ㅅㅂ 이런 검색어로 여기 들어오는 게 맞나?’ 싶은 병신같은 레퍼 잡히면 막을 겁니다. 다음의 전례를 볼 때 그 수준 떨어지는 검색엔진이 얼마 안 가 사고를 칠만한데, 자주 문제를 일으키던 앨범 정리를 더 이상 올리지 않기 때문에 문제가 안 생길 것 같기도 하네요.

2. 일단 PLN 서버는 분리합니다. MLN과 VLN은 일시 중지됩니다.
DLN 원드라이브 루트에 관련 공지가 따로 있습니다. 가서 처 읽으라고 이 강아지들아, 서버 자원만 파 먹지 말고 공지가 있으면 읽으라고! 응?

3. 영향이 댐시에서 프레이즈로 다시 옮겨집니다.
공개 일기장은 결국 완전 공개 되어 있어야 제 기능을 하죠. 요즘 남이 보는 게 두려운 글을 잘 안 쓰다보니 글을 너무 못 쓰는 게 자꾸 밟혀서 이걸 해야겠어요. 다만 검열을 좀 빡쎄게 하고, 기존의 비공개로 작성된 영역이 공개되지는 않을 겁니다.

1. 캐시 설정을 완료했습니다.
이제 제대로 돌아가는 것 같아요.
(사실 설정을 완료했다기보다는 캐시를 없애 버렸다에 가까워서
이래도 제대로 안 돌아가면 말이 안 돼요.)

2. fake request에 대한 우회 대응을 완료했습니다.
이걸 전부 대응할 수 있게 하려고 했는데,
이게 나한테는 완전히 새로운 분야라 아는 것도 없고,
관련 아티클을 찾아봐도 뭔 소린지 알기 싫고-_-
개발하는 내내 저 캐시가 제대로 작동하지 않는 문제와 맞물려서
제대로 된 테스트가 이루어지지 못했고,
그나마도 내가 이해한 대로 작동하지 않아서 전부 대응은 불가능했습니다.
(ㅈ같아서 캐시 다 날려 버리고
우회로 하나만 뚫어서 정상 작동 되는 걸 확인하고 대응 했음. 한다는 겁니다.)
따라서 dpi 우회를 위한 fake request을 할 때는,
sequence, ack number을 fake request 하는 것을 추천합니다.
다른 설정은 페이지를 제대로 로딩하지 못할 가능성이 있습니다.

3. 라잇박스 플러그인을 적용했습니다.
이제는 이미지를 클릭하면 해당 원본 이미지 파일을 표시하는 대신,
확대 된 이미지가 라잇박스로 표시됩니다.
다만 포스트가 아닌 페이지의 경우는
태그 목록등에서는 라잇박스가 정상적으로 출력되지만,
페이지 내에서는 라잇박스를 열지 못하고 원본 이미지 파일을 여는 문제가 있습니다.
고칠 수 있을 것 같은데, 귀찮아요.
어차피 이미지를 클릭해 볼 필요가 있는 페이지는 WfGA 밖에 없으니
그냥 안 고칠래요.
+
생각해보니, 현재 과거 WfGA등을 포스트가 아닌 페이지로 올린 이유는,
퍼머링크 url을 wfga-2022 같은 식으로 의미 있게 유지하기 위해서인데,
앞으로는 포스트로 올려야 할텐데 그럼 퍼머링크가 문제가 돼요.
그래서, 포스트에 커스텀 퍼머링크를 달아줄 수 있도록 조정한 후,
현재 페이지로 되어 있는 프로젝트 페이지들을 포스트로 바꿔줘야 할 것 같네요.
++
커스텀 퍼머링크가 구조가 간단할 줄 알았는데,
플러그인들을 둘러보니 생각보다 구현이 어려운 모양이네요.
플러그인이 지정한 슈도 퍼머링크 주소들을 저장하고 있다
포스트로 연결해주는 방식을 취하는데, 이게 퍼머링크가 달린 포스트 수가 늘어나면
자원 잡아 먹는 게 기하 급수적으로 늘어날 게 뻔하니 좀 마땅치 않았어요.
그래서 대충 억지로 DB구조를 고쳐서
포스트에 슈도 퍼머링크를 달아줄 수 있는 기능을 추가했습니다.
어찌됐든, 필요한 기능은 구현했어요.