Its all about transitions! Lets talk about Slicer's landing page

Actually, this is going to be tricky, possibly too tricky to have github.io hosting be viable.

slicer.org (which forwards to www.slicer.org as per best practices) is now hosted on Digital Ocean. www.slicer.org/wiki points to the wiki, also hosted on digital ocean. There are a bunch of rules on the slicer.org web server that keep old links working while allowing current, consistent, cleaned up wiki URIs. Backward compatibility was one of our goals in the re-architecture of the wiki.

If we moved slicer.org to github, we don’t have a place to put those Apache configurations, since slicer.org is top-level. Right now I don’t see how it can be done.

An alternative would be to author the site on github, and pull it over to the main site where our existing slicer.org HTTP server would serve it. That would also take care of the SSL configuration, which is working and continuously maintained using letsencrypt.

Let me know your thoughts.
–Mike

Yet another alternative is to declare everything-wiki “legacy”, and move on with hosting documentation using ReadTheDocs or GitBook, as some of the folks discussed earlier.

Do we have any idea of who is using Slicer wiki, how it is used (editors/readers ratio), what pages are being accessed, etc? My guess is that it could be the case that most of the wiki content is not used either because it is obsolete, not searchable, or for various other reasons.

Just wanted to float this idea around.

@fedorov in fact, we do now have some good data on that via google analytics, at least on page views and it’s in the thousands per day (see below). I would not want to move to either gitbooks or readthedocs because either one would be a disruptive change that doesn’t offer enough advantages at the moment.

I like the idea of hosting the repository for slicer.org static pages on github and then using the existing digital ocean infrastructure that already handles the wiki to host that content under https.

@mhalle it sounds like we could set up something like:

github.com/SlicerExample/example.slicer.org => https://example.slicer.org

where “=>” means a githook publishes every commit over to the digital ocean host and “example” can be any community that wants to participate, is that right?

@pieper it is great that we have analytics set up! It should be very helpful to prioritize migration, if there is ever agreement to do it.

I disagree though about “a disruptive change that doesn’t offer enough advantages”. I think it is an opportunity to bring some order to the various resources that piled up over the last decade, and improve the appeal of these resources. By making documentation more accessible for both users and developers, we have a chance to attract more people and grow the community, and there are few things that are more valuable than that. I think there is also relatively low risk if wiki is maintained in read-only legacy mode, as the content is migrated/populated.

But I also think that, as we have experienced already, reaching consensus on what will be the new platform is challenging.

@mhalle Thanks for the investigating. It all makes sense.

Agreed.

Look like this tools should be helpful: GitHub - adnanh/webhook: webhook is a lightweight incoming webhook server to run shell commands

It should allow to easily create endpoint and execute command based on the payload.

For example, here is a hook definition for GitHub payload.

In other word, it is a generalization of the flask app I put together to trigger generation of apidocs.

We should make sure the end points we setup:

  • checks that the payload come from the range of ips matching Github (see Meta - GitHub Docs and ip_check
  • checks a secret agreed one when setting the webhook

During the weekly developer hangout, @bpaniagua and I talk about this, and we suggest to setup a cron job on the server that is currently serving “slicer.org” ?

A cron job like this one (running every minutes) should do the work:

SITE_DIR=/path/to/slicer.org
if [[ ! -d $SITE_DIR ]]; then
  git clone https://github.com/Slicer/slicer.org $SITE_DIR
fi
cd $SITE_DIR
git fetch origin
git reset --hard origin/gh-pages

I just talked with @mhalle about this and it sounds like the digital ocean instance is now set up and would be ready to start autopulling from github.com/Slicer/Slicer.org. As I understand it @freephile has a git repository of what is currently hosted on https://slicer.org which I think is similar (identical?) to what is currently on github.

So I think we are ready for the plan to make the github.com/Slicer/Slicer.org repository become the official one and use github issues and pull requests to maintain it.

2 Likes

I haven’t compared them bit by bit, but the index.html content does look similar between https://slicer.github.io/slicer.org/ and https://slicer.org/index.html

There is a bunch more file content in the live slicer.org site. Some of which just needs to be purged (e.g. DownloadSlicer.php). Some may be desired, but ignored in the repo (e.g. doc), in which case we’ll just use the .gitignore file to avoid collision. And some would be candidates for addition to the repo (e.g. robots.txt).

Also, @mhalle I noticed that https://download.slicer.org/ is different from http://download.slicer.org/

git ls-files|grep -v doc/
.gitignore
DownloadSlicer.php
css/basic.css
css/basic.css~
css/ie.css
css/ie5mac.css
css/styles.css
css/styles.css.bak
css/styles.css~
favicon.ico
img/3DSlicer-DesktopIcon.png
img/3DSlicer4Logo-H-218X144.png
img/3DSlicerLogo-H-Color-218x144.png
img/Logo-Slicer.png
img/Logo-Slicertext.png
img/Search.png
img/Slicer4Announcement-HiRes.png
img/animated_favicon1.gif
img/bullet_more2.gif
img/bullet_style1.gif
img/bullet_style1.png
img/bullet_style4.jpg
img/bullet_style5.jpg
img/bullet_style6.jpg
img/dl-l.png
img/doc-l.png
img/favicon.ico
img/fb-l.png
img/focal/js/config.php
img/focal/js/download.php
img/icons612.png
img/logo2_slicer.png
img/logo_slicer.png
img/misc/Bugtracking-hover-old.png
img/misc/Bugtracking-hover.png
img/misc/Bugtracking-l.png
img/misc/Bugtracking-old.png
img/misc/Bugtracking.png
img/misc/Documentations-hover-old.png
img/misc/Documentations-hover.png
img/misc/Documentations-l.png
img/misc/Documentations-old.png
img/misc/Documentations.png
img/misc/Download-hover-old.png
img/misc/Download-hover.png
img/misc/Download-l.png
img/misc/Download-old.png
img/misc/Download.png
img/misc/DownloadNav-hover.png
img/misc/DownloadNav-hover.png.bak
img/misc/DownloadNav.png
img/misc/DownloadNav.png.bak
img/misc/Slicer3.6Release.png
img/misc/Slicer4Announcement-612x362.jpg
img/misc/SlicerExtensions-612.png
img/misc/Tutorial-hover-old.png
img/misc/Tutorial-hover.png
img/misc/Tutorial-l.png
img/misc/Tutorial-old.png
img/misc/Tutorial.png
img/misc/bugtracker.png
img/misc/bugtracker1.png
img/misc/documentation.png
img/misc/documentation1.png
img/misc/download.png
img/misc/download1.png
img/misc/slicer4Announcement612px-i-mj.png
img/misc/tutorial1.png
img/misc/tutorials.png
img/re/chunk1.png
img/re/chunk10.png
img/re/chunk11.png
img/re/chunk12.png
img/re/chunk2.png
img/re/chunk3-blank.png
img/re/chunk3-orange.png
img/re/chunk3.png
img/re/chunk4-blank.png
img/re/chunk4-orange.png
img/re/chunk4.png
img/re/chunk5-blank.png
img/re/chunk5-orange.png
img/re/chunk5.png
img/re/chunk6-blank.png
img/re/chunk6-orange.png
img/re/chunk6.png
img/re/chunk7.png
img/re/chunk7r.png
img/re/chunk8-blank.png
img/re/chunk8-orange.png
img/re/chunk8.png
img/re/chunk8r-orange.png
img/re/chunk8r.png
img/re/chunk8r2.png
img/re/chunk9.png
img/re4.1/Bugtracking-hover.png
img/re4.1/Bugtracking.png
img/re4.1/Documentations-hover.png
img/re4.1/Documentations.png
img/re4.1/Download-hover.png
img/re4.1/Download.png
img/re4.1/Tutorial-hover.png
img/re4.1/Tutorial.png
index.html
robots.txt

Thanks Greg. I’m not sure what all is in the existing slicer.org folder,
but based on the toplevel page it looks like most links to go the wiki or
to the download site, so perhaps we just start fresh with just index.html
and its assets. On the other hand it doesn’t look huge, so we could commit
it all and then clean up.

Either way I understand that github.com/Slicer/Slicer.org is a placeholder
that can be overwritten by the content of the currently non-public
slicer.org git.

@jcfr I made a pull request to update index.html Do you want to make me an editor on the repo, so I can push, or if you want I can continue to issue pull requests.

With that merged, I can pull the github repo and setup cron on https://slicer.org

I’ll simply archive the existing content listed above (it’s all legacy by the looks of it), and add in the .gitignore, favicon and robots.txt files to the github repo.

Thanks Greg. PR merged :slight_smile:

1 Like

@freephile I also just sent you an invite to join https://github.com/orgs/Slicer/teams/slicer-website-maintainers

@mhalle Similarly you also have a pending invitation …

1 Like

OK, this is done. The website is pulling every 5 minutes from the repo. Any merged changes into the repo will go live automatically.

The repo has been updated with a README etc. And unused content has been moved aside on the server for eventual deletion.

1 Like

Very nice :thumbsup:

Now that we have the sync setup, what do you think of:

  • we rename gh-page branch to slicer-org
  • create a branch preview-slicer-org that would allow to try changes on “preview.slicer.org” (or we could have the preview rendered by Github configured at as github page)

I’d have to change the sync if we change the branch name, so it’s important to coordinate.

Since gh-pages is configured in GitHub to automatically be hosted at slicer.github.io. I’d use that branch name as a ‘preview’, but the caveat is how do we avoid accidental visits that would fake out a user?

For hosting the true site, we don’t really need a new branch. we could just merge the current gh-pages into master and then pull from master.

The branch used for github pages can now be configured

merge the current gh-pages into master and then pull from master

Since I anticipate we will add some scripts and tooling to potentially help build the static content, I still think it makes sense to server the site from a dedicated branch (e.g slicer-org)

In the mean time, I created a new branch named slicer-org based of the existing gh-pages

how do we avoid accidental visits that would fake out a user

We could add some javascript checking the hostname and making a banner visible

Sounds good.

I updated the git version on the host which works better with credential configuration and cron seems happy with git fetch

What is the font that is used in the 3DSlicer logo? Such in this image https://www.slicer.org/img/3DSlicerLogo-H-Color-218x144.png

@bpaniagua I was just wondering the same thing for another logo and found your question :smile: Copy-pasting the text from Mac Preview of a pdf version of the logo into TextEdit, the font appears to be Verdana (changing it back and forth gives the same look so I think that’s correct).

Hi all,

Now that are using the github.com/Slicer/Slicer.org repo as the main Slicer landing page, I wanted to bring back to the conversation the fact we wanted to give some presence to the SlicerDistributions to the landing page.

I did a version of what that would look like here: https://bpaniagua.github.io/slicer.org/

Ideas?

Bea