Wiki as part of the org website

[ff6347]

This could be something to work on. See issue #3 comments from @dominikwilkowski

[dominikwilkowski]

I'll move discussions over here then.

write/test the code
create a new file in the wiki repo for it
commit, push, done
It should stay as simple as that. That's why I never moved to a Jekyll gh page.

I completely agree. Simplicity is important for a healthy FOSS project. How I see the contribution if the wiki was it's own repo in https://github.com/ExtendScript/extendscript.github.io:

• fork
• write/test code
• create a new file in your repo
• commit, push, send PR
• review step to get it into the master repo (something that might proof important as the community grows)

If someone want's to use the website interface they can do so arguably even better with a real repo as it gives you access to each page and the ability to add new pages. With the wiki I am currently unable to add/edit pages as I am not a contributor.

What about discoverability through search engines? It feels like the wiki gets indexed better then a .io site. There is this article about seo for pages. Maybe it already solves this.

SEO is probably a point we need to consider as we would move the wiki to an entirely new URL. On the up-side this gives us a fresh start.

I would add that using gh-pages branches for this might not be the right move. Using the https://github.com/ExtendScript/extendscript.github.io repo seems to be the most appropriate location for the wiki IMO.

[ff6347]

Okay. Sounds all reasonable.

With the wiki I am currently unable to add/edit pages as I am not a contributor.

Sorry for that. I changed it to be editable by everyone. Maybe we should include @wridgers into that discussion. He wanted to work on ExtendScript/extendscript.github.io#1

Would you still use jekyll as generator? I have no experience in making static sites searchable.

[dominikwilkowski]

Would you still use jekyll as generator? I have no experience in making static sites searchable.

There's no urgent need to use jekyll as all static HTML pages will be visible via pages. We, at work, use jekyll frequently but with lots of plugins which makes it impossible to use the built-in GitHub jekyll generator. We just have a build step via gulp or grunt to spit out the pages to be commited. I am happy with any.

Searchable static sites rely on JavaScript so things like:

• lunrjs (That would be my choice)
• tapirgo (just found this)
• Google Custom Search Engine

Lot's of good ways of enabling dynamic searching. I love to have a sitemap I can search with the browser built-in search.

[ff6347]

We can also host the site on my server where the Mailserver is running and the domain is pointing to http://extendscript.org. Then we can use jekyll without any limitations. Could be done with a webhook so every push/commit triggers a pull and build on the server.

[dominikwilkowski]

That's fine too but in the spirit of keeping things simple for now (MVC/MLC and all) I would suggest to get something up on the github repo and point your A record of your domain there. Github supports custom domains easy.

Again GitHub doesn't actually give us any restrictions other than it being a static page. Happy to help any which way.

[ff6347]

Okidoki. CNAME is set up. http://extendscript.org/

[dominikwilkowski]

Another thing I just noticed is the way the wiki handles images. I am unable to upload anything directly to the wiki which means the wiki is full of extra dependencies on other servers or other repos. Having the wiki in a repo means all assets are in one location and won't fail partly.

Anything I can do to help?

[ff6347]

The images are within the repo. There is no upload right. But you can clone the repo, add an image and push it again. There is no dependencies to other servers (currently)