Opened 9 years ago

Closed 8 years ago

#807 closed enhancement (fixed)

Revamp of website

Reported by: str4d Owned by: str4d
Priority: minor Milestone: 0.9.9
Component: www/i2p Version:
Keywords: Cc: Zlatin Balevsky
Parent Tickets: Sensitive: no


This ticket tracks progress on the revamp of the I2P website. The revamp is located in the changeset:h:i2p.www.revamp branch on Montone.


Change History (32)

comment:1 Changed 9 years ago by str4d

Related tickets:


comment:2 Changed 9 years ago by str4d

Status: newaccepted

comment:3 Changed 9 years ago by str4d

http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ hosts an instance of the revamp site, and will be kept reasonably up-to-date with the branch.

comment:4 Changed 9 years ago by str4d

As of changeset:c7f4a832ebcfec93b826459c8074a6fe78b7315a the reorganization of the original site is basically done (ignoring some old pages and a few that I am uncertain of how/where they should fit in).

Once we are all happy with the url and navigation layout, the next task is to go through every single link on every single page of the site and ensure the link is correct. Internal links need to be in the form {{ site_url('url/of/page') }} (or the full url_for form for meetings/downloads/blog), and external I2P links need to be in the form http://{{ i2pconv('foobar.i2p') }}/baz (so that on the clearnet they are still accessible). After that, the last big task is to go through every page and set up translation tags per paragraph so that the site can be translated on Transifex (docs/how/intro is already done as an example). The two tasks can be done at the same time for each page.

comment:5 Changed 9 years ago by str4d

Other tasks that also need doing:

  • The theme needs either further work (e.g. SOME designing of the non-front pages), adaption or replacement. I plan to put out requests for designs within I2P (zzz.i2p, forums, IRC, id3nt etc.) as well as maybe the clearnet.
  • The blog and meetings indexes need pagination.
  • The blog index needs real text at the top.
  • The support/performance page needs content (given that I have shifted the more technical future improvements list into a separate page). I'm wondering if eche|on's I2P speed blurb http://echelon.i2p/i2p/i2pspeed.txt could be adapted for this page?
  • Do the blog and meetings Atom feeds need adjusting so they don't show the entire blog entry or meeting summary, or is that okay? Given that the HTML would need to be intelligently shortened, it could be tricky…
  • There was a stub method added by welterde to the backend for a blog RSS feed. Is RSS needed as well as Atom? If so, it can be implemented using the same helper methods that the Atom feed methods use.

Any tasks relating to general page content should be done in upstream changeset:h:i2p.www and propagated across, BEFORE working on the links and translation tags (once they are done, propagating text changes will be a nightmare).

comment:6 Changed 9 years ago by str4d

As of changeset:a8c78a784781bf969e37aa42b3c1c05949b6b04a the index pages of the blog and meetings list have pagination.

comment:7 Changed 9 years ago by Zlatin Balevsky

Cc: Zlatin Balevsky added

Comments as of the time of writing this ticket:

  • #792 can wait until later.
  • on /$LANG/site/support/htproxyports I would move IE8 to the top (sad but true) and add a Chrome section. Chrome iirc uses the OS proxy settings so maybe just rename the section to "Internet Explorer 8 or Chrome"
  • On the drop-down menu leading to the above: I would rename "Web browser configuration" → "How to browse I2P" ( ←- minor nitpick, it's good enough as is)
  • maybe even "Support" → "Help" on the tab name
  • $LANG/site/support/performance ←- not found, but it doesn't have to be there immediately
  • Support → Forums : since forum.i2p is no longer accessible from clearnet, it should either not be there on the clearnet site or it should be marked somehow
  • "Support → Bug Tracker" : I'd move that over to the "Volunteer" menu, probably inside "Volunteer → Develop"
  • The entire "Docs" top-level menu can go either inside the "About" or the "Volunteer" menus as a sub-menu

comment:8 in reply to:  7 Changed 9 years ago by str4d

Replying to zab:

  • Alright.
  • Done in i2p.www; will be in i2p.www.revamp on next propagation (after the 0.9.4 release).
  • Done.
  • Also done (makes sense, and it's shorter).
  • I had the file sitting here locally but hadn't checked it in >_<
  • I've commented out the line that defines its clearnet url, so the i2pconv() function now converts the I2P url to an inproxy url for clearnet viewers.
  • Done, though I do wonder whether having some bug-related link in Help might be useful.
  • I'd spent a lot of time not having an About menu, but now that it's there, putting Docs as a sub-menu makes sense. Done.

comment:9 Changed 9 years ago by str4d

There was a lot of good discussion about the revamp in meeting 213. Some of the points that were raised (I'm probably missing a few):

  • The SEO of the current site needs to be leveraged in the revamp.
    • The URLs of all old pages need to redirect to their new locations - using a permanent redirect should update our URLs in search engines etc.
    • So that mirrors don't suck away reputation:
      • Pages need a <link rel="canonical"> pointing to the main site.
      • All links to mirrors need to be rel="nofollow"
  • It would be good to generate a site map, which can then be uploaded to e.g. Google Webmaster Tools.
    • On that note, it would be good to claim on Google Webmaster Tools.
  • The decision to not have menu-opening items linked as well needs more thought.
    • Link some of them where relevant? (Previous behaviour, was decided against before)
    • Remove the <a> links from the menu-openers? I left them with <a> links because I thought it was necessary for the styling I mashed in to work.
    • Differentiate the menu-openers visually? That would be ideal IMHO.
  • Try integrating duck's original menu color into the mashed-in menubar CSS (to see if the overall look improves).
  • The text on the download page is reasonably important, so having direct links to the download files might not be a good idea. Maybe the "Download" menu could just become a "Download" link? (Though this would then mean that it was the only item on the menubar which is an actual link…)
  • Maybe the drop-down menus could just be buttons to top-level pages which contain the other links?
    • I don't like this idea much; to me the point of having a (good) drop-down menu is to make it much easier for a user to find what they want (in the shortest time possible); having to click through not-necessarily-obvious links on multiple pages to find what they want is not good IMHO.
  • The use of "/en/site" to mark a site page might need re-thinking - it increases the length of the URL.
    • Currently the backend uses the lang code first, and otherwise looks at the accept-languages header parameter.
      • Google recommends not redirecting based on the user's perceived language.
      • The I2P HTTP proxy filters out accept-* so that will not work for I2P viewers.
    • Could we use cookies to store the user's language choice?
      • Google recommends not using cookies for language choice, because then the different translations cannot be indexed.
    • Google recommends having unique URLs for different translations of the same content. It suggests using subdomains or subdirectories to distinguish different languages.
      • Using different subdomains would be easy on the clearnet, but very taxing on I2P.
      • This supports having /en/ in the URL.

comment:10 in reply to:  9 Changed 9 years ago by str4d

  • The site urls no longer contain "site/" - Flask was perfectly happy to distinguish between the "/<lang>/blog" etc. and "/<lang>/<page>" routes.
  • As per the Google recommendations above (as well as other related reading), the urls will still start with "/lang/" in order to ensure distinct pages for translations (which can then be prioritized by search engines in different regions).
  • After removing "site/" from the url above, the legacy pages route "/<page>" would not work ("/<page>.html" "/<page>_<lang>" etc. still did). To keep the urls nice, a custom url converter was added to match the lang part - as a result, the lang part of a url can now be in the form "en" or "en-us" (i.e. regionalization is possible).
  • The above additions were causing the site code to become unwieldy (all in a single .py file). The backend has now been refactored into python modules, additionally using a LazyView class to do lazy loading of the view code - this should speed up the website as only sections of the total codebase will now be loaded on a request.

comment:11 Changed 9 years ago by str4d

Updates related to above comments:

  • The menubar CSS mashed into duck's theme has been tweaked to integrate better (both in usability and color), and I've made various other tweaks to try and improve the non-front-page pages. It's an improvement, but the theme as a whole still needs work.
  • I've removed the <a> links from the menu openers (the CSS is done with <div>s now), so the navbar now only has <a> links where needed for actual links.
    • The menu openers are now differentiated visually, so hopefully that improves usability.
  • The downloads list has been reworked to be clearer for users and easier to style. Some basic styling has been added in duck's and danimoth's themes.
    • Does the clearer downloads page remove the need for specific download links in the navbar?

comment:12 Changed 9 years ago by str4d

Summary of things that need doing (at this stage) before the final link check and adding translation tags:

  • The LEGACY_PAGES_MAP in needs filling out (diff the head to i2p.www to track where the pages went).
  • Sitemap generation - this could partly be done by crawling the pages/site/ dir for *.html, and then filled out with the other pages.
  • The blog index page needs work - text, layout, styling, whatever.
  • Ditto for the meetings index page.
  • /research needs filling out - I envisage this being a central page that we can direct academics to who are interested in studying I2P, which outines relevant information e.g. what the open questions in I2P are, what potential avenues of research could be pursued, what we as I2P developers would like to see studied (namely, everthing =P).
    • /research/papers is a list of academic I2P papers - should this be more in the style of an academic bibliography (since it is aimed at that demographic)?
  • /support/performance needs looking at - does it all make sense for the purpose of this page, or does it need tweaking?
  • I've added a template GNUnet comparison page, which I would like to get filled out (but this is not crucial, and the navbar link can be removed if it doesn't get done).
  • There is existing content that also needs work (this should be done in i2p.www and then propagate into the revamp).
    • /support/glossary needs filling out and checking.
    • /about/contact *really* needs filling out.

Have I missed anything?

comment:13 Changed 9 years ago by hottuna

Re /support/performance:

A long time ago I wrote up some of the advanced options used to manage performance on http://ugha.i2p/AdvancedConfig

Maybe they can be of use?

comment:14 Changed 9 years ago by str4d

As of changeset:42a10e0e62e3a0abd7895773b0fb1da198a68382 the LEGACY_PAGES_MAP has been filled out (so all the old site URLs now permanently redirect to the new ones), and the main site URLs have been standardized to use '-' to separate keywords (e.g. /en/docs/how/garlic-routing ) which should improve SEO as well as readability. The blog paths still use '_' as a spacer in the slugs, but they are converted to spaces when the slug is used as the blog post title, so I'm not sure if using '-'s there is going to work.

comment:15 Changed 9 years ago by str4d

changeset:cd7cdd51b2baf88a89bc4cabc86c0ff607fb27d0 adds sitemap generation - one sitemap.xml per language, and a sitemap_index.xml at the root.

comment:16 Changed 9 years ago by str4d

I'm starting to think that the current implementation of the blog - rendering a RST file that raw-includes a HTML file containing the blog post - is not a great method to use.

I'm guessing that welterde went for the RST file because it enabled some sort of metadata to be retrieved from the posts (which cannot be done with a Jinja2 rendered template AFAIK). But the blog posts should really be a single file - so if RST files are used then the old HTML files should be migrated over to Markdown.

The other problem is URL substitution - docutils does not seem to support any kind of template substitution, so e.g. the download url currently hard-written in each release post would remain so (and would link to the English download page). I wondered if the blog post could be rendered with Jinja2 first to do parameter substitution, and then rendering the resulting Markdown with docutils, but that seems somewhat clunky.

I'm currently looking into alternatives for the blog backend. Ideally a blog post could have metadata at the top which could be parsed easily, or a second file for storing metadata (both of these still require scanning the entire blog post directory to generate the blog index). Or maybe there could be a top-level file for post metadata. Or the post metadata could be cached to reduce regeneration frequency.

Decisions here could also influence the meetings page backend, which currently consists of a RST file with the meeting summary and a .log file with the meeting logs. If a better system is found for blog posts, I don't see why it could not be used for the meeting summaries as well (which would then mean that docutils could be dropped as a dependency).

Suggestions welcome =)

comment:17 Changed 9 years ago by str4d

changeset:74543c1cf04ef2b6f26f78139eca54d47b54baab contains a rework of the blog:

  • Added support for metadata in blog entries - date, author, category and excerpt
  • Modified blog/index.html and blog/entry.html templates to use metadata
  • Migrated the most recent post (0.9.4 Release) over to just a .rst file and added metadata, as a proof-of-concept

Still to resolve:

  • Every request of any page of the blog index, or the feed, results in all blog entries being rendered. Caching needs to be added here, probably with Flask-Cache which will integrate nicely (and can be hooked into memcached or whatever backend the server has).
  • Currently the title used on the blog index pages is the one taken from the slug of the page (its filename). But there is now access to the actual title of the post (due to every entry being rendered) - should this be used?
  • The date on the blog index pages is the one taken from the slug of the page (its directory path). But a date can now be added as metadata, and this is currently displayed on the entry page. Which should be preferred? Is there any point in having date metadata? Might there be use in having metadata for the last time the post was updated, while using the date from the slug as the date of post?
  • Once the above is decided on and finalized, the old blog entries should be migrated over.

An incidental question: would the url /lang/blog/post/XXXX/XX/XX/slug be preferable to the current /lang/blog/entry/XXXX/XX/XX/slug ?

comment:18 Changed 9 years ago by str4d

And on the subject of URL changes (while I still have the option of changing them):

  • /lang/support/* vs /lang/help/* ?
  • /lang/volunteer/* vs /lang/get-involved/* ?
  • Any other suggestions?

comment:19 Changed 9 years ago by str4d

After discussion in meeting 214, /lang/volunteer/* has been changed to /lang/get-involved/* and /lang/blog/entry/* has been changed to /lang/blog/post.

comment:20 Changed 9 years ago by str4d

The date issue above has been "resolved" in that the 'date' metatag is used preferentially, but falls back on the date taken from the slug. Additionally, the blog RST files are now pre-rendered with Jinja2, meaning that normal template tags can be used (e.g. for generation of site URLs). This also means that the blog posts can be tagged for translation like the main site pages.

I have migrated over the 0.9.3 release post to the new format, and added translation tags to it and the 0.9.4 release post; between them, the general layout for blog posts is now well-defined, and future posts will follow this layout. The earlier blog pages still render correctly so I won't be migrating them (as there are other laborious tasks remaining), but anyone is welcome to migrate them across to pick up the extra features.

comment:21 Changed 9 years ago by str4d

As of changeset:cd2b4484fd02a2a1f370dc607bbfc26e2379b6cc the blog and meetings views (index pages, individual entries and feesd) all have ten minute caching, which is enabled when the server operator configures the cache for whatever backend they have.

Additionally, the rendered blog titles are now taken from the blog post RST instead of the slug, so that they can be translated; the slug now only affects the URL.

comment:22 Changed 9 years ago by str4d

Sitemaps are now cached per language, and the blog posts have been renamed to use hyphens instead of underscores.

Additionally, after looking at the stats on Google Webmaster Tools to see which pages are more popular/viewed/clicked/linked/etc, I pushed changeset:0faeddbcbab6b33ebf3295c98b687b390b4dc51b which reorganizes several URLs:

renamed i2p2www/pages/site/about/comparison

to i2p2www/pages/site/comparison

renamed i2p2www/pages/site/about/contact.html

to i2p2www/pages/site/contact.html, /lang/contact

renamed i2p2www/pages/site/support/browser-config.html

to i2p2www/pages/site/about/browser-config.html

renamed i2p2www/pages/site/support/faq.html

to i2p2www/pages/site/faq.html

renamed i2p2www/pages/site/support/glossary.html

to i2p2www/pages/site/about/glossary.html

renamed i2p2www/pages/site/support/performance

to i2p2www/pages/site/about/performance

This reorganization removes the /lang/support/* URL subcategory entirely (nullifying the above question of shifting it to /lang/help/*) and makes the more "visible" URLs shorter (/lang/faq, /lang/comparison/*).

As of this point, I think the revamp is about ready to go. The last blocking tasks are to check every single page of the site for valid URLs and to tag every single site page for translations. I'll start this now.

comment:23 Changed 9 years ago by str4d

The translation tagging is progressing - slowly (it's hell on my hands >_<) but aside from the Documentation, most of the site is done.

On another front, the revamp now supports mobile browsers much better. The required tags have been added to <head> and duck's theme now has a mobile.css (other themes could follow suit). It is displayed on browsers with a width less than 768px, so it can be previewed in desktop browsers.

comment:24 Changed 9 years ago by DISABLED

I just visited the mobile site on a desktop broswer (midori), safari on an ipod touch, and the stock android browser (the latter two via The site works fine from the desktop but on the mobile browsers the navigation bar is unusable. On the ipod none of the links work except the link to the download page, and on the android the titles expand correctly, however the 3rd tier links are unclickable, the broswer just selects the 2nd tier link behind it and expands the appropriate menu. I have only looked at the menu bar so far however i will report back with other bugs on the mobile site as i discover them.

comment:25 in reply to:  24 Changed 9 years ago by str4d

Replying to guest:

I just visited the mobile site on a desktop broswer (midori), safari on an ipod touch, and the stock android browser (the latter two via The site works fine from the desktop but on the mobile browsers the navigation bar is unusable. On the ipod none of the links work except the link to the download page, and on the android the titles expand correctly, however the 3rd tier links are unclickable, the broswer just selects the 2nd tier link behind it and expands the appropriate menu. I have only looked at the menu bar so far however i will report back with other bugs on the mobile site as i discover them.

Thanks for looking at it. I didn't realise it wasn't working that well, but I'd only tested on Opera Mobile for Android. I do recall having the 3rd tier issue, but the CSS I'm using for the menu ( originally only supported up to 2nd tier, so it probably requires some refining. Odd that it doesn't work at all for iOS - the CSS's webpage specifically shows an iPhone _ I probably messed up when migrating the CSS to the revamp though; I'll check.

comment:26 Changed 8 years ago by str4d

Milestone: 0.9.6

The site has been (almost completely) tagged for translations; trolly has translated 26% into Spanish already, and other languages are trickling in. URLs have also been updated and checked (but will be checked again after the site is launched on and before is redirected).

Recent changes include propagating updates from the current website, and changes to the download and mirror selection pages from ticket #463. Mobile CSS has not been further tested other than confirming that it does work on Opera Mobile for Android, mostly… Clicking a 3rd tier item does correctly select it, but opening a 2nd or 3rd tier sub-menu and then clicking on a 1st or 2nd tier item below it selects an incorrect item - the selected item is the one that would have been in the clicked position had the sub-menu not been open. This might be the issue referred to in comment 24.

Other points that still require work: the blog (style and structure), the theme (general styling, desktop tweaks, mobile improvements).

Optimistically adding this to the 0.9.6 milestone (pending welterde having free time).

comment:27 Changed 8 years ago by str4d

Towards improving the general style, I have added Pygments syntax highlighting to the site. To use:

{% highlight lang='shortcode'[, otherparams=foobar, ...] %}
To be highlighted...
{% endhighlight %}

(otherparams are passed through to HtmlFormatter)

See http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/get-involved/develop/applications#start for a live example. The current style is "native" from the built-in Pygments styles, but that can be changed.

comment:28 Changed 8 years ago by str4d

welterde put the revamp up live at a test domain. I have updated the legacy mapping and run checks for broken links. There are many dead links in the old status posts, but I cannot update them because the posts are PGP signed. On the rest of the site there are now only a handful of problematic external links. And AFAICT all site-internal links are valid.

I think that the revamp is now ready to go live at for final testing. If that goes well, then I will propagate i2p.www.revamp to i2p.www and welterde can redirect to

Any final issues?

comment:29 Changed 8 years ago by str4d

Status: acceptedtesting

killyourtv has fixed the site-update bug. Once I test and confirm, the site will be ready for testing live on

comment:30 Changed 8 years ago by str4d


comment:31 Changed 8 years ago by str4d

Almost done - the old urls all redirect to the new ones. There are a few trivial steps remaining:

  • eche|on updates his site to use branch i2p.www
  • eche|on updates his server config to use 301 for redirects from [www.] to
  • I inform Google etc. of the domain change to start the migration of linkage

comment:32 Changed 8 years ago by str4d

Resolution: fixed
Status: testingclosed

Done :)

Note: See TracTickets for help on using tickets.