@kapoorlab The site imagej.net is the old wiki’s static content, which can (if you must) be edited here.
We are in the process (nearly finished!) of migrating all that content to GitHub Pages. Once that migration is complete, the imagej.net domain will be pointed at the imagej.github.io content—but this has not yet happened.
Note that edits made to the old static content will not be rolled forward to the new imagej.github.io site. You would need to add the content yourself to both sites separately. The main reason for editing the old static site would be in case you need imagej.net/<SomePageOfYours>
to reflect changes immediately due to e.g. a publication link. This should hopefully be rare.
Therefore, the commit you made created a page at https://imagej.github.io/User_ClaudiaCarabanaGarcia
. However, I then moved all user pages into /users
, because we are in the process of reorganizing the content. So the content you made is now here:
User ›ClaudiaCarabanaGarcia
This is not the final URL though—site is still in flux. I will announce when the site has stabilized, and when it is “going live” via imagej.net.
As for the BTrack page, the link BTrack(Mate) is active, but it seems that GitHub Pages does something weird with it because there is no content: it gets served as application/octet-stream
. Is BTrack a new plugin from your group? Note that plugin pages will now live under /plugins/
, and all pages will be in small-case-with-dashes, so I’ll be renaming that page to /plugins/btrack
some time soon. But you are welcome to populate it with content about your plugin any time.
Yeah, that’s intentional. It’s a link to a page explaining what a wiki is, for people who don’t know. The entire imagej.net is (was! and will be again!) a wiki; there is no need to have a link “take you to the wiki” from the front page.
I’m currently developing the include template for that. Stay tuned. It will be easiest for you if you extend pom-scijava, and put that information in the developers
section of your POM, and publish your releases to a remote Maven repository. Then you’ll be able to simply reference your groupId:artifactId
and javascript will auto-populate it for you. But if you don’t want to do that, it will be possible to maintain this information manually on the wiki as well.