akngs / ecogwiki

Wiki engine for Google App Engine written in Python

Hi there 👋

ecogwiki's Issues

Add enumeration type

Sidebar

Allow users to specify per-page CCL

권한이 없을 때 .read .write 페이지 작성시

로컬에서 로그인 안하고 .read .write 넣은 페이지 만들고 다시 가면 읽어지지를 않음

wiki-like image embed syntax

구글 드라이브나 드랍박스에서 지정한 폴더에 대해 이미지를 embed하기 쉬웠으면 좋겠습니다. 예를 들어

![image](db:image.jpg) //Dropbox
![image](gd:image.jpg) //Google drive

혹은 둘 중에 하나만 지정한 후

![image](file:image.jpg) //Mediawiki-like

Try stricter types first when converting schema properties

For example, the range of http://schema.org/featureList property are Text and URL. Since URL is stricter than Text in terms of formality, the system should try to convert it to URL first and then to Text.

user who has write access cannot read page

A non-admin user who has write access to a page could not read the page unless he is declared in read acl.

Consider the following acl configuration:

.write [email protected]
.read [email protected]

some content here

and user [email protected] reaches the page. He can read the page, so it's meaningless to be declared as a writer!

Of course, generally a user might write the name in both .write and .read, but even if he doesn't, the system should understand that he who has write access could also read the content.

It seems like the current models.py calls can_read inside can_write for short-circuit logic, meaning,

"he who cannot read are not able to write"

but I think it should be the other way around:

"he who can write can read"

Is there some specific policy on this?

Don't render [[1979]] to "1979-??-??"

Plain editor is too slow in Safari

The plain editor is not responsive enough and difficult to use in Safari. The Typed characters appear after some delay.

Do not parse texts in code block as a structured data

Embed prezi

- [ ] 체크박스 클릭스 .read .write 날라감

1. 페이지 생성
2. .read .write 넣음
3. 넣음
4. 읽기모드에서 체크 클릭
5. Edit로 들어가보면 .read .write 날라가 있음

Flush cache after deployment

h2부터 사용할 시 오류가 발생하는 문제

본문에 heading을 줄 때 h1를 사용하지 않고 h2부터 사용하였을 경우에 Duplicate paths not allowed 에러가 발생합니다.

_가 들어간 URL을 파싱하지 못하는 문제가 있는것으로 보입니다.

에디터에서 http://blogs.msdn.com/b/david_gristwood/archive/2004/06/24/164849.aspx 링크를 추가하려고 했는데 _이후의 텍스트가 italic으로 표시되고 이 텍스트가 있는 페이지를 Save하려고 하면

Cannot accept the data for following reasons:
Duplicate paths not allowed

라는 메시지가 나오면서 save가 되지 않습니다.

Delete page with hierarchical path

Deleting page with hierarchical path doesn't work well.

1. Create a page something like "A/B"
2. Delete "A/B"
3. Goto "A"
4. The page says there's incoming link from "A/B".

ted 동영상 넣기

Page alias / redirect support

대부분의 위키엔진은 redirection을 통해 한 페이지를 여러 이름으로 접근할 수 있도록 하는데, 개인적으로는 모니위키의 방식이 더 좋아 보입니다.

Show preview side-by-side

Pagination

Following pages/features need pagination or something similar:

• sp.changes
• sp.posts
• sp.search
• sp.index?
• Wikiquery results

Data backup or export

@가 들어간 링크의 변환

현재는 URL 주소에 @가 들어가면 링크가 아니라 email로 변환합니다.

@가 URL에 들어가는 것이 적합하냐는 논의가 있기는 한거 같긴 합니다만..
혹시 이를 지원할 생각이 있으신가요?

이유는 간단합니다. 구글맵이 이렇게 쓰고 있어요:

[구글맵](https://www.google.com/maps/dir/%EC%97%90%EC%BD%B0%EB%8F%84%EB%A5%B4+%EA%B0%88%EB%9D%BC%ED%8C%8C%EA%B3%A0%EC%8A%A4/%EC%B9%B4%EB%B3%B4%EB%B2%A0%EB%A5%B4%EB%8D%B0/@18.8144822,-53.4862847,4z/data=!4m13!4m12!1m5!1m1!1s0x9aaa92ee319f2cbf:0x95bebc63839846f2!2m2!1d-90.9820668!2d-0.8292784!1m5!1m1!1s0x9358f2159115131:0x6b1af236f918ea1f!2m2!1d-23.6050817!2d15.1217288)

github은 제대로 나오는걸 보니, 지원해주는 것이 좋다고 생각합니다 :)

(협박: 안된다고 하면, "구글맵 지원" 이슈를 따로 넣을 생각)

Maybe it's more natural to have 'cancel' button in the edit view?

If you want to cancel your edit and go back to the page, the only way is browser back button, which you need to use several times if you clicked the editor taps. (view=edit#plain -> view=edit#struct -> view=edit => original page)

I think it may be better to have a cancel button that brings you back to the page.

Make page list to show additional information something like thumbnail.

Make page list to show additional information something like thumbnail:

• sp.changes
• sp.posts
• wikiquery result
• ...

Structured editor

< > 를 편집기가 변환해버립니다.

클라이언트에서 사용자가 입력한 HTML 엔티티를 자동으로 변환해서 보여주고, 저장할 때 변환된 채로 저장하는 문제가 있습니다.

---

재현 시나리오

페이지에 <refspec> 이라고 적고 저장을 하면, 편집 시 <refspec> 으로 나옵니다.
(이 때까지는 _type=txt를 보면 여전히 <refspec>로 나타납니다)

여기에서 바로 저장을 누르면 변환되어서 저장이 됩니다. 이제는 txt 형식으로 봐도 <refspec>으로 나옵니다. 화면에 렌더링될 때는 태그로 인식하기 때문에 나타나지 않습니다.

페이지 내용을 바꾸었으나 읽기 모드에선 수정전 내용이 보임

/sp.flush_cache 하면 괜찮음

Embed videos using normal <iframe> tag

Embed Google Calendar

새 페이지를 만들때 바로 .read / .write ACL을 걸면 페이지 내용이 보이지 않음.

일단 ACL없이 페이지를 만들고 ACL을 추가하면 괜찮음

Treat value of TextProperty as a markdown

Allow customization of the schema properties' cardinality

Allow customization of the schema properties' cardinality.

• Default cardinality should be 0..0.
• 1..n means required property
• If the number of props is larger than the specified cardinality, take heads and drop the rest.

Read http://microformats.org/wiki/cardinality to understand design decisions.

Add automated unit tests for JS codes

Show diff between two revisions

자기한테 리다이렉트하는 페이지의 수정 불가 문제

실수로 어느 페이지에 redirect를 자기 자신으로 하는 경우에, 이를 수정할 수 없는 경우가 발생합니다.

가령, self-redirect 폭탄이라는 페이지에

.redirect self-redirect 폭탄

이라고 적었다면, 이 페이지를 방문하면 무한 자기 순환에 빠지게 되겠죠. 크롬의 경우 이를 발견하고 알려줍니다:

이는 예상된 행동입니다. (물론 페이지에서 미리 알려주면 좋겠죠)

그런데 문제는, 이를 고치기 위해서 수동으로 self-redirect 폭탄?view=edit 으로 접속해도 편집 화면이 나타나지 않고 계속해서 순환 오류 페이지가 나타난다는 겁니다. 이는 잘못된 오류입니다

self-redirect 폭탄?_type=txt로 접근하면 제대로 화면에 rawbody를 나타내줍니다. 이를 이용해 self-redirect 폭탄?_type=txt&view=edit 식으로 접근하면 편집화면이 나타나긴 합니다만.. 해결되었으면 합니다.

---

다음은 예제 페이지입니다. (언제 수정되거나 없어질지는 모르겠습니다. 고치는 당시에만 참고해주세요)

• 에러 페이지: http://www.ecogwiki.com/self-redirect_폭탄
• raw body: http://www.ecogwiki.com/self-redirect_폭탄?_type=txt
• 잘못된 응답: http://www.ecogwiki.com/self-redirect_폭탄?view=edit
• 편법적 접근: http://www.ecogwiki.com/self-redirect_폭탄?_type=txt&view=edit

Add support for footnote

Embed slideshare

Site name and logo image to top-bar

There are many ecogwikis, these have same look and feel. It would be better it display site name and logo image at top-bar. If user did not have logo image, default image (ecogwiki logo) can be displayed.

I suggest {{ logo_image }} {{ site_name }} --------- {{ preferences }} {{ logout }} {{ search }}

page rename 제안

사용자는 위키 페이지의 제목을 바꾸고 싶어서 rename을 하고 싶어합니다.
그런데 위키에서 페이지 제목이 곧 id이라 간단하지 않은데,
그래서 사용편의성을 위해 다음과 같은 제목변경 기능은 어떨까, 제안해봅니다.

이름이 변경된 페이지로 가기

1. 사용자는 <이전 페이지>의 편집 화면에서 [이름 변경] 링크를 이용해 제목을 변경할 수 있다.
2. 제목을 <새 페이지>로 변경하고 나면, <새 페이지>에서 내용을 그대로 볼 수 있다.
3. <새 페이지>의 리비전을 보면, 첫 리비전 comment에는 "<이전 페이지?rev=5>에서 이름이 변경되었습니다"라고 나온다.
4. <이전 페이지?rev=5>로 가는 링크가 함께 있어서, 클릭하면 이전 페이지의 해당 리비전까지만 나오는 페이지로 갈 수 있다.

헌 페이지는 리비전만

1. 한편, <이전 페이지>에는 내용이 지워져 있고, 리비전에만 남아 있다.
2. 그 뒤에 작성되는 내용은 다음 리비전부터 계속 쌓이게 된다.

이름 변경이 안 되는 경우

• <새 페이지>에 이미 내용이 있으면, 제목을 변경할 수 없다.

---

리비전 댓글에 '이전 페이지의 해당 리비전까지' 보러 가는 링크를 다는 것이 현재로선 간단하지가 않네요.

어떨까요?

Image upload

Embed Google Earth

다중속성을 가진 schema property의 json 인코딩 문제

여러개의 값을 가지는 schema property를 배열 형태로 선언할 수 있는데, 이것이 json 인코딩 시 문제를 일으킵니다.

예:

author: ["강규영", "김장환"]

로그를 보면 schema.ThingProperty을 JSON이 serialize 시키려다 실패한다고 나옵니다.

ERROR    2014-02-08 07:45:49,961 webapp2.py:1528] <schema.ThingProperty object at 0x10709c750> is not JSON serializable

예시 페이지에서 에러를 확인해볼 수 있습니다.

[제안] 영어 페이지 제목 대소문자 정책

대소문자나 띄어쓰기는 위키 운영자마다 물론 다른 정책을 갖는 것이 좋지만,
이미 띄어쓰기에 대해서 "서버가 알아서 언더스페이스(_)로 변경해주는 것"과 같이
사용자 편의를 위해 대소문자도 그러한 기본 정책을 제안해 봅니다.

주된 이유는, "사용자로서 영어로된 페이지를 작성할 때 매번 고려하기 번거로워서" 입니다.

다른 위키는 모르겠고, Wikipedia는 현재 다음과 같은 방식으로 해주는 것 같습니다:

• 첫글자는 서버에서 자동으로 대문자로 변경한다. (예: continental drift)

• 두번째 단어부터는 바꾸지 않는다. (예: Continental Drift)

  사용자는 필요하면 redirect 등을 추가할 수 있다.

혹시 이런 식의 방안에 대해 생각하고 있는게 있는지, 알고 싶습니다.

.config 페이지 수정 잘 못 했을 때, 시스템이 뻗는 문제.

{{url::http://ecogwiki.com/}} 파싱 에러

다음과 같은 문자열을 제대로 파싱해 내지 못하고 있습니다. 뒤에 }}가 붙네요:

{{url::http://ecogwiki.com/}}

결과:

<a href="...">http://ecogwiki.com}}</a>

코드를 보니 md_url.py의 url_re 가 내부에 http:// 류가 들어가는 모든 링크를 먼저 파싱하기 때문에 나는 에러인 것으로 보입니다. 여기서 먼저 {{url과 http://ecogwiki.com/}} 으로 끊어져서, 이후의 md_itemprop.py에서 처리되지 않고 있네요.

schema.org에 따르면 기본 Article만 해도 URL이 들어가는 itemprop이 7가지나 되는데, 고쳐야겠죠.

---

markdown.inlinepatterns.Patterns를 이용하는 re pattern이 읽기 힘든데, 혹시 re.VERBOSE 플래그를 사용하실 생각은 없나요?

Embed maps

Google, Daum, Naver

Support for Disqus in addition to Facebook comment

Markdown extension for a long text schema property

Markdown extension for a long text schema property. The notation should allow users to specify multi-paragraph text block as an itemprop.

Don't treat underlines in URLs as emphasis

중첩 li 띄어쓰기

리스트아이템(li) 안에 또 리스트아이템(li)이 중첩될 때, multiparagraph로 표현하는 경우에 CSS가 틀어지는 경우가 있습니다.

예:

* 첫번째 아이템

    1. 중첩 아이템1
    2. 중첩 아이템2

* 두번째 아이템

다음의 두 그림을 비교해주세요 (왼쪽이 현재, 오른쪽이 수정안):

이는 margin-top, margin-bottom이 li > p 에만 적용이 되어 있고, li > ol, li > ul에는 적용이 안되어 있기 때문입니다.

따라서 이에 대한 해결책으로 article .body li 아래에 있는 p, ul, ol 모두에게 margin을 적용해주는 것이 맞다고 봅니당.

14px은 어디서 정의된건지 모르겠네요. 어쩌면 1em일지도 모르겠습니ㅏ.