gnustep / gnustep.github.io Goto Github PK

Since gnustep.github.io is currently being indexed by search engines, I will keep my changes out of this repo until we have something to publish. I will update this issue with a link to where we can view a staging site to monitor progress when it is ready

Apply header updates in 45bebac to the other pages.

Plan out the page layouts without getting bogged down with cosmetic choices.
This should be done once the site map is completed

I'll post a lot of other projects' websites and talk about their structures.

Proposed tasks:

0. rework anything in the current repo (gnustep.github.io repo) that uses PHP to stop doing so

   • this includes downloads and RSS feeds
   • for RSS, we should explore the jekyll-feed plugin (https://dev.to/dzhavat/adding-an-rss-feed-to-github-pages-2col)

1. create file CNAME in gnustep.github.io with contents www.gnustep.org

2. in hosting control panel, change www.gnustep.org to be old.gnustep.org (to signal that this is a site that is not -- or is rarely -- updated)

   • for example, if there's a record www, change it to old
   • this may require teaching the web server to handle the new hostname ("if you see old.gnustep.org in the Host: header, treat it as if it said www by sending it to the same PHP plugin/PHP fastcgi daemon/PHP cgi daemon")

3. in hosting panel, create new CNAME record www

   • have it point to gnustep.github.io. (including trailing dot)

4. note that wiki has a CNAME to wwwmain already

   • wwwmain, just like www, is an A record pointing at 81.201.190.216
   • wiki is a mediawiki site, so it likely requires PHP
   • proposed: change wiki from CNAME to an A record pointing at 81.201.190.216 to allow for future deprecation of wwwmain

5. handle wwwmain

   • proposed: leave wwwmain as is for now, and track fixing it in another bug
     • we need to update gnustep.github.io not to use PHP URLs from www or wwwmain anyway
     • once that's done, wwwmain should be replaced with 301/302 redirects to www
     • ideally 301/302 redirects can be done by the web server (presumably exposed by the hosting provider, as the bare domain gnustep.org already redirects to www.gnustep.org automatically)
   • fixing this should not be postponed too long, as it will -- like old -- drift away from gnustep.github.io without active maintenance

6. update reverse lookup for 81.201.190.216 to old.gnustep.org. or to wwwmain.gnustep.org.

As per Fred: “JS libraries we are using are really dated. We need to update Bootstrap and jQuery.”

http://wiki.gnustep.org/index.php/ times out.

Report Bugs on the mainpage, times out.

ftp.gnustep.org is down and has been for some time.

Figure out the general architecture of the site. What areas should exist and decide on pages that live in them. After that is decided, the front page content will be easier to plan.

Pages

• Front Page (The main pitch to get devs interested plus latest news)
• Documentation (Contains all relevant "getting started" tutorials, articles and api documentation)
• Tools (Page dedicated to Project Center/Gorm that links to an online user guide )
• Platforms (Page that advertises GNUstep's supported target platforms eg. Mac/Windows/Linux/Android/Custom etc)
• Case Studies (If there are any notable 3rd party apps that have been developed, we should interview the devs and showcase the app)
• News ** (blog with any relevant news. Should launch this after the YouTube channel has some content)
• Contribute (Page describing how developers can contribute code, documentation, issue tracking etc)

Social Media

• Github
• Facebook
• Instagram
• X (aka Twitter)
• YouTube
• LinkedIn

EDIT: Tweaked area names and descriptions

We need to decide on a technology stack. IMO some sort of static site generator would be ideal. I am inclined to use jekyll since that would make it trivial to run it right here on github. Every merge can regenerate the site automatically. It will also make contributing content to the site easy as all anybody will need to know is some markdown. If we later decide to move to another static site generator for whatever reason, they pretty much all take markdown as source files.

For hosting, I understand there is a community member that is already generously providing hosting. Deploying the generated HTML and other assets will be a simple rsync away. If that hosting option ever goes away, deploying to github pages is also an available option. The trick will be to figure out how to pull in the API pages.

TLDR;

We use Jekyll and figure out how to automate pulling in the API docs.

Per our discussion in November, @hmelder came up with the idea of creating a webpage to track this information. Per that conversation it would:

1. Track existing headers
2. Track Cocoa headers
3. Compare the two to determine how compliant we are with the current API

I am adding this here so that we have a place to track it. Please feel free to add a new repo to do this.

I'll post a lot of other API docs and talk about them here.