Starting this thread to discuss the different solutions, what they offer and how many people have used them before. I know Drupal better than other CMSs and it fits the requirements although static generation is not out of the box but supported by a module(like most things in Drupal). Content is usually created and modified through a web interface that offers either source code view or a WYSIWYG GUI but can be template based using text files on disk. Can anyone explain a bit how Jekyll would work in the context of the Tor website? Do users need to create the content on disk or through a web interface?
Jekyll is basically a set of markdown files you edit in a text editor and then they're rendered in the browser as valid HTML by the generator (liquid, I think). It's pretty simple to set up and use, but you have to be comfortable with typing away in the markdown syntax. From the previous thread, seems like Middleman is a similar concept except perhaps with more internationalization options out of the box. A ______________________Label: Superstar DestroyerWeb: http://www.hipstersunite.netI write for Prog Magazine, The Fly, This is Fake DIY and build websites. Twitter: @hipsters_unite | LinkedIn Date: Thu, 9 Jan 2014 17:08:43 -0500 From: olssy1@gmail.com To: www-team@lists.torproject.org Subject: [Tor www-team] [Back-end][CMS] Starting this thread to discuss the different solutions, what they offer and how many people have used them before. I know Drupal better than other CMSs and it fits the requirements although static generation is not out of the box but supported by a module(like most things in Drupal). Content is usually created and modified through a web interface that offers either source code view or a WYSIWYG GUI but can be template based using text files on disk. Can anyone explain a bit how Jekyll would work in the context of the Tor website? Do users need to create the content on disk or through a web interface? ________________________________________________________________________ Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
drupal is way to bloated wordpress way too insecure. and neither of them are downloadable as they are db based. i am assuming that anyone who is going to edit the blog will have a basic understanding of html As the site needs to be portable as in downloadable, pdfable and made to run offline. Is there any reason it cant be built in html? a webmaster can update it and push out new pages. i know this goes against scaling and there will be argument that it should be ruby or jekyll or octopus or whatever garbage is in fashion at the moment. "Jekyll is basically a set of markdown files you edit in a text editor and then they're rendered in the browser as valid HTML by the generator (liquid, I thin" seems to be it solves a problem that dosent exist. but html has been around for decades and is not just downloadable to read offline but bundalable in software. someone can whipup some code to allow it to publish as pdfs as soon as a page is updated. i just want to throw that out there even if it gets dismissed immediately which i will understand. On 10 January 2014 10:02, Alex Lynham <acelynham@hotmail.com> wrote:
On 10.01.2014 11:57, Earl G wrote:
Jekyll generates HTML that can be put on any server that serves static files. The advantage of Jekyll is that you can define templates and includes that simplify your development work and reduce repetition in your code. Using markdown, textile or another text to html generators, helps content creators to write their texts without having to worry about html. It's rendered into your jekyll template and stored as a simple html file. In the end you have to distribute the generated html, images and css files and nothing more. Cheers
yeah i just wanted to get my point across that sometimes simple is best and don't forget the lost art of coding in notepad
I very much like Jekyll because writing content is simply a case of creating a markdown file in the relevant directory and writing it in Vim. It's super simple, as it should be :) Here is an example of a blog post I wrote for my Jekyll-powerd blog: https://raw2.github.com/rey/reyhan.org/gh-pages/_posts/2013-03-12-jekyll-arc... Rey On Friday, 10 January 2014 at 11:53, Earl G wrote:
+ 1, use it for my blog as well and it's really simple. A ______________________Label: Superstar DestroyerWeb: http://www.hipstersunite.netI write for Prog Magazine, The Fly, This is Fake DIY and build websites. Twitter: @hipsters_unite | LinkedIn Date: Fri, 10 Jan 2014 11:58:02 +0000 From: rey@spcshp.com To: www-team@lists.torproject.org Subject: Re: [Tor www-team] [Back-end][CMS] > yeah i just wanted to get my point across that sometimes simple is best and don't forget the lost art of coding in notepad I very much like Jekyll because writing content is simply a case of creating a markdown file in the relevant directory and writing it in Vim. It's super simple, as it should be :) Here is an example of a blog post I wrote for my Jekyll-powerd blog: https://raw2.github.com/rey/reyhan.org/gh-pages/_posts/2013-03-12-jekyll-arc... Rey On Friday, 10 January 2014 at 11:53, Earl G wrote: yeah i just wanted to get my point across that sometimes simple is best and don't forget the lost art of coding in notepadif jekyll fits the need then this is perfect On 10 January 2014 12:37, Christian <me@rndm.de> wrote: On 10.01.2014 11:57, Earl G wrote:
drupal is way to bloated wordpress way too insecure. and neither of
them are downloadable as they are db based.
i am assuming that anyone who is going to edit the blog will have a
basic understanding of html
As the site needs to be portable as in downloadable, pdfable and
made to run offline.
Is there any reason it cant be built in html?
a webmaster can update it and push out new pages.
i know this goes against scaling and there will be argument that it
should be ruby or jekyll or octopus or whatever garbage is in
fashion at the moment.
"Jekyll is basically a set of markdown files you edit in a text
editor and then they're rendered in the browser as valid HTML by
the generator (liquid, I thin" seems to be it solves a problem that
dosent exist.
Jekyll generates HTML that can be put on any server that serves static files. The advantage of Jekyll is that you can define templates and includes that simplify your development work and reduce repetition in your code. Using markdown, textile or another text to html generators, helps content creators to write their texts without having to worry about html. It's rendered into your jekyll template and stored as a simple html file. In the end you have to distribute the generated html, images and css files and nothing more. Cheers ________________________________________________________________________ Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team ________________________________________________________________________Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit:https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team ________________________________________________________________________ Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Can anyone explain a bit how Jekyll would work in the context of the Tor website?
In terms of the Tor website it would be a case of completely replacing the current Drupal implementation with a website built on Jekyll. In practice this would require moving all the content current found on torproject.org into markdown files. Each markdown file would have a `layout`[1] defined in the YAML frontmatter[2] which exists on the top of the markdown file. As a simplified example, a blog post's frontmatter may look like: ``` --- layout: post title: "Tor Weekly News" tags: - weeklynews - browserbundle --- ``` And a page's frontmatter may look like: ``` --- layout: page title: "Documentation" --- ``` The documentation has an example of a basic directory structure: http://jekyllrb.com/docs/structure/
On Thursday, 9 January 2014 at 22:08, Olssy wrote:
I like the idea if Jekyll, though I've never used it myself. Running a git repo and gerrit will make our use of Jekyll easier. We'd use git to manage the markdown files that generate the website and gerrit to approve changes. Gerrit is in use by some Android projects. Check it out http://review.cyanogenmod.org and https://gerrit.omnirom.org Silviu. On Jan 10, 2014 5:59 AM, "Rey Dhuny" <rey@spcshp.com> wrote:
I am currently working on a drupal project and agree that drupal is far too big and complex for the requirements laid out for tor. Something like jekyll seems much leaner and simpler. As a developer, I agree that writing straight html would be nice. But there are a lot of content writers in the world that just don’t know it well enough. On Jan 10, 2014, at 7:27 AM, Silviu Riley <silviu.riley@gmail.com> wrote:
Why not just write a really simple PHP back-end with TinyMCE that produces plain HTML pages? Should be quite simple to implement, and with TinyMCE pretty much every moron can work with the back-end. Jekyll seems okay too, but still, markup language still is a kind of programming, and lots of content writers are allergic for programming. 2014/1/10 Sean Rafferty <seanmrafferty@me.com>
Rick Lubbers:
Why not just write a really simple PHP back-end with TinyMCE that produces plain HTML pages?
Jekyll (or Pelican, Middleman or $static-site-generator) are tools that do one thing and one thing well: they take markdown (or $text files) + templates and spit out a fully static website. It's important to consider that it's not simply a case of spitting out plain HTML pages as thought has to be given to managing torproject.org's content structure both for launch and as the website's content grows it has to scale.
Should be quite simple to implement, and with TinyMCE pretty much every moron can work with the back-end.
I believe writing a bespoke solution for torproject.org 3.0 introduces further complexity as opposed to using one of the proposed static site generators[1]. The proposed have mature codebases, active communities and fulfil the current technical requirements[2].
Jekyll seems okay too, but still, markup language still is a kind of programming, and lots of content writers are allergic for programming.
Markdown is a) very easy to read and b) very easy to write[3]. I must respectfully disagree that "markup language is still a kind of programming" as in my opinion it's simply a way to structure a text document and nothing more. It's not a skip and a jump away from how one may write an email, for example. Rey [1] https://trac.torproject.org/projects/tor/wiki/Website#Candidates [2] https://trac.torproject.org/projects/tor/wiki/Website#Technicalrequirements [3] http://daringfireball.net/projects/markdown/basics On Friday, 10 January 2014 at 15:18, Rick Lubbers wrote:
On Fri, Jan 10, 2014 at 10:10 AM, Sean Rafferty <seanmrafferty@me.com>wrote:
But there are a lot of content writers in the world that just don’t know it well enough.
Then they can learn. If someone wants to contribute to a solution to a problem as complex as privacy and security, then learning markdown / HTML should be a minor investment of their time. Basic HTML takes little time to learn, and will instantly boost the self-respect of anyone who wants to help Tor and other software projects. Setting a bar is worth it, IMO.
Ok So Jeklly a user guide for people that need to learn markdown to be able to contribute to the blog. and the front of the site user friendly for anybody that wants to get started. back of the site and deeper for the linux nerds and specialists that want to dig deeper. job done On 10 January 2014 17:32, Sam E. Lawrence <selbrit@gmail.com> wrote:
Markdown is _very_ simple. Please check out http://daringfireball.net/projects/markdown/basics and try out markdown at http://www.markdownviewer.com/. Let’s try to use these as long as possible for getting people familiarized with Markdown. We do not want to duplicate existing documentation efforts, and keep up-front investment for tools as low as possible in this project. I hope I am correct in my understanding that we agree on a static website generator now, and kind-off agree on Jekyll. Best Moritz Am 10.01.2014 um 17:35 schrieb Earl G <globallogins@gmail.com>:
I hope I am correct in my understanding that we agree on a static website generator now, and kind-off agree on Jekyll.
+1 for Jekyll from me. ______________________Label: Superstar DestroyerWeb: http://www.hipstersunite.netI write for Prog Magazine, The Fly, This is Fake DIY and build websites. Twitter: @hipsters_unite | LinkedIn Date: Fri, 10 Jan 2014 17:00:58 +0000 From: rey@spcshp.com To: www-team@lists.torproject.org Subject: Re: [Tor www-team] [Back-end][CMS] > I hope I am correct in my understanding that we agree on a static website generator now, and kind-off agree on Jekyll. +1 for Jekyll here. On Friday, 10 January 2014 at 16:57, Moritz Süß wrote: Markdown is _very_ simple.Please check out http://daringfireball.net/projects/markdown/basics and try out markdown at http://www.markdownviewer.com/. Let’s try to use these as long as possible for getting people familiarized with Markdown. We do not want to duplicate existing documentation efforts, and keep up-front investment for tools as low as possible in this project. I hope I am correct in my understanding that we agree on a static website generator now, and kind-off agree on Jekyll. BestMoritz Am 10.01.2014 um 17:35 schrieb Earl G <globallogins@gmail.com>: Ok So Jekllya user guide for people that need to learn markdown to be able to contribute to the blog. and the front of the site user friendly for anybody that wants to get started. back of the site and deeper for the linux nerds and specialists that want to dig deeper. job done On 10 January 2014 17:32, Sam E. Lawrence <selbrit@gmail.com> wrote: On Fri, Jan 10, 2014 at 10:10 AM, Sean Rafferty <seanmrafferty@me.com> wrote: But there are a lot of content writers in the world that just don’t know it well enough. Then they can learn. If someone wants to contribute to a solution to a problem as complex as privacy and security, then learning markdown / HTML should be a minor investment of their time. Basic HTML takes little time to learn, and will instantly boost the self-respect of anyone who wants to help Tor and other software projects. Setting a bar is worth it, IMO. ________________________________________________________________________ Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team ________________________________________________________________________ Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team ________________________________________________________________________Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit:https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team ________________________________________________________________________ Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Definitely a +1 for Jekyll. There's no need to reinvent the wheel. While a custom solution or plain HTML may seem appealing at first (and would be great for a personal project), Jekyll lets us move much quicker and keeps everything relatively standardized. It also makes it easier for people to collaborate, since Jekyll is widely used. On Fri, Jan 10, 2014 at 11:57 AM, Moritz Süß <moritz@moritzsuess.de> wrote:
Hello, Everyone! Missed the introduction thread, so I'll just start with that: I'm Gvido, and I'm currently based in Amsterdam. My official job title is front-end developer, but in reality I do full-stack development with ruby or python. Now, back on topic. I'm also going to agree with the general sentiment that Jekyll is the way to go. It's stable, simple, widely used, easy to extend, and powerful. Markdown is really easy to learn, I don't think content creators writing about Tor would have a problem grasping it. On Fri, Jan 10, 2014 at 6:52 PM, William Papper <william@papper.me> wrote:
While Jekyll is indeed a choice, for larger sites, it's generation time is simply too long. Development takes time on Jekyll, simply because of it's generation time. If we can offset that problem in some way, that would be great, otherwise I feel we should be looking at some other static site generator (Someone suggested Middleman? It also has internationalization!) As for the debate about author's writing 'code', Markdown is easy to learn and use, and outputs semantic data. We really don't need a rich text editor of some sort, Markdown (Or similar languages) are good enough. On Fri, Jan 10, 2014 at 11:45 PM, Gvido Glazers <gvido.glazers@gmail.com>wrote:
-- Namanyay Goel <http://namanyayg.com/> :: Freelance Web Designer and Developer. :: UI Designer at MakeUseOf <http://makeuseof.com/>. :: Author at Symmetrycode <http://symmetrycode.com/>. :: @namanyayg <http://twitter.com/namanyayg>
While Jekyll is indeed a choice, for larger sites, it's generation time is simply too long.
Are there any benchmarks or examples to validate this statement? I would be very interested to see generation times comparing the proposed static site generators, especially for larger sites. I personally have never encountered such problems in my usage of Jekyll though they haven't been large, content heavy applications like will be the case for torproject.org.
(Someone suggested Middleman? It also has internationalization!)
I was somebody who suggested Middleman and indeed, it does have internationalisation baked in, though a concern I personally have is that it could potentially be _overkill_ for the application in this case. Thoughts? Rey
I couldn't find much - Except the multiple StackOverflow questions you find when searching 'Jekyll generation slow', and this Github issue: https://github.com/jekyll/jekyll/issues/1140, and my personal experience with using it (Use it on a blog with ~40 posts, generation time is from 8-12 seconds). Hmm, Middleman might be overkill, but still I suggest we look into other static site generators, especially that can handle larger sites. (Points of interest in the Github issue: * Testing with jekyll build: 150 files - 20sec 300 files - 40sec 600 files - 130sec * Testing jekyll build, 100 files, and using Jekyll-Bootstrap: #1 real 0m18.725s user 0m18.256s sys 0m0.407s #2 real 0m18.578s user 0m18.124s sys 0m0.423s #3 real 0m18.467s user 0m17.986s sys 0m0.434s * jekyll new performance: posts 1 0.824s 100 2.644s 1000 25.071s 5000 186.715s 10000 536.904s) On Sat, Jan 11, 2014 at 12:07 AM, Rey Dhuny <rey@spcshp.com> wrote:
-- Namanyay Goel <http://namanyayg.com/> :: Freelance Web Designer and Developer. :: UI Designer at MakeUseOf <http://makeuseof.com/>. :: Author at Symmetrycode <http://symmetrycode.com/>. :: @namanyayg <http://twitter.com/namanyayg>
Namanyay Goel: Thank you for those stats! Maybe they should be put on the wiki where we can compare performance under the proposed generators section?
Hmm, Middleman might be overkill, but still I suggest we look into other static site generators, especially that can handle larger sites.
I very much agree, much more so since seeing looking at those stats. Rey
A 'smart' rendering engine would only render the pages that need to be changed. Right? -- Clark On Fri, Jan 10, 2014 at 14:02, Rey Dhuny <rey@spcshp.com="mailto:rey@spcshp.com">> wrote:
How often will the static files need to be rendered?
Off the top of my head (not in front of a computer), When a page is changed or added, the entire site is regenerated. I could be mistaken.
Static site generators that can handle large sites easily: * Gostatic: https://github.com/piranha/gostatic (0.3s for 250 pages) * Pacbot: https://github.com/olav/pacbot (Has two modes, dev and build, dev is faster and on-the-fly, while build processes everything and neatly packages files) However, I have experience with neither. On Sat, Jan 11, 2014 at 12:41 AM, Clark Venable <jclarkv@gmail.com> wrote:
-- Namanyay Goel <http://namanyayg.com/> :: Freelance Web Designer and Developer. :: UI Designer at MakeUseOf <http://makeuseof.com/>. :: Author at Symmetrycode <http://symmetrycode.com/>. :: @namanyayg <http://twitter.com/namanyayg>
Static files rendering: If you change a single page, it will render that, and will render any related pages, such as home, tags, etc. Changes to the stylesheet make each page render again, which tremendously slows down development. Using Drupal @Olssy: It's already been established that we *need* something that doesn't need a database so it can be easily mirrored (on over 70 mirrors) and can be downloaded and stored by our users (in a pen drive, CD, etc). Also, I don't believe we need user roles? On Sat, Jan 11, 2014 at 12:31 AM, Rey Dhuny <rey@spcshp.com> wrote:
-- Namanyay Goel <http://namanyayg.com/> :: Freelance Web Designer and Developer. :: UI Designer at MakeUseOf <http://makeuseof.com/>. :: Author at Symmetrycode <http://symmetrycode.com/>. :: @namanyayg <http://twitter.com/namanyayg>
Sorry to be such a pain about Drupal but I just want it to make sure it is being ruled out for the right reasons, the database it uses does not prevent it from generating static pages. Just like the Jekyll markdown files don't need to be mirrored neither does Drupal or its database, just the generated html files. I do like the Jekyll solution though just worried that it's a bit limited for the project. Back to your question: Do we need User roles? If the site will ever be supporting user generated content through then I think this is a requirement but if UGC is to be offloaded elsewhere else and it's really just the static pages then I think the file system permissions should suffice. On Fri, Jan 10, 2014 at 2:12 PM, Namanyay Goel <mail@namanyayg.com> wrote:
Olssy, thanks for addressing my concerns here. I wasn't aware that we could mirror the files and make them available for download, however, I do think it would come with it's own share of problems. Another thing to see here is speed and the easiness of backing up data. With a static site generator, there are only a few folders that you need to save for backups, while Drupal needs a backup of database and plugin data, among other things. Static site generators are also fast, really fast, and even the simplest of servers which have caching set up well can handle large traffic to a static site. I advocate for a static-site generator, though not Jekyll (Since it's painfully slow). On Sat, Jan 11, 2014 at 1:54 AM, Olssy <olssy1@gmail.com> wrote:
-- Namanyay Goel <http://namanyayg.com/> :: Freelance Web Designer and Developer. :: UI Designer at MakeUseOf <http://makeuseof.com/>. :: Author at Symmetrycode <http://symmetrycode.com/>. :: @namanyayg <http://twitter.com/namanyayg>
I'll drop talking about Drupal, you two have convinced me. I still wonder if the project should support user generated content and I'm still a bit foggy as to what the back end roles will be for maintaining the site. On Fri, Jan 10, 2014 at 3:28 PM, Namanyay Goel <mail@namanyayg.com> wrote:
On 01/10/2014 02:24 PM, Olssy wrote:
I'm a little confused by the definition of "user generated content". Are we referring to things like blog posts and tutorials? If so, then I think a static site generator + git still works. The author would just need to create a patch (using git format-patch) and then email it to this list. Someone with commit access to the www repo could then apply the patch and then a post-commit hook could regenerate the web site. Granted, you would need some degree of technical savvy to do that, but not much more than it would take to clone the repo in the first place. Tom Purl
I agree - worst case scenario, there can be a tech team that take the new .md document (or edited doc) and merge it into the git repo/branch ready for deploy. A ______________________Label: Superstar DestroyerWeb: http://www.hipstersunite.netI write for Prog Magazine, The Fly, This is Fake DIY and build websites. Twitter: @hipsters_unite | LinkedIn
I was thinking more along the lines of blog comments or forum posts, I think currently the blog allows anonymous posting which shouldn't be a problem but if ever any part of the site requires creating an account for end-users then we should give it a thought before choosing a solution. On Fri, Jan 10, 2014 at 4:05 PM, Tom Purl <tom@tompurl.com> wrote:
Olssy:
We want to replace the current blog (with comments) by a solution where content and comments are separated. See: <https://trac.torproject.org/projects/tor/milestone/2014%20Tor%20Blog%20Replacement> If anyone else would like to help with contributing to the website content with documentation, language improvements or anything else, we will find ways to make it happen. I believe we can find people to do some “marking up” on submission that are not directly in the right format. -- Lunar <lunar@torproject.org>
Sam E. Lawrence:
See <https://trac.torproject.org/projects/tor/ticket/10022>. We can't trust data retention policies of 3rd party services. So we would need something we can host ourselves. Andrew suggested Discourse <http://www.discourse.org/> as it is something the Tor Project could run on its own systems. It is not clear yet how complicated this would be. After some quick searches, I've also found: * Juvia <https://github.com/phusion/juvia> * comment-it <https://code.google.com/p/comment-it/> Those three should probably be compared more thoroughly. -- Lunar <lunar@torproject.org>
Discourse seems very nice and can be used with blogs as this site has implemented: http://eviltrout.com I find this entry in the FAQ a bit disconcerting: Should I switch to Discourse right now? Probably not. Discourse is brand new. Discourse is early beta software, and likely to remain so for many months. Please experiment with it, play with it, give us feedback, submit pull requests – but any consideration of fully adopting Discourse is for people and organizations who are eager to live on the bleeding and broken edge. There is tremendous technical and sociological friction to change in any established community. Consider carefully whether your community is willing to adopt such a big change. Perhaps start a discussion about even the possibility of such a change well in advance. We believe Discourse currently makes the most sense for new discussion communities. In some rare cases communities may have a discussion platform that they intensely and actively dislike, to the point that they are willing to throw the whole thing away and start over. Also, pretty much any blogging solution is going to be using a database in the back end so a strategy for the mirrors will be needed before long. On Mon, Jan 13, 2014 at 10:59 AM, Lunar <lunar@torproject.org> wrote:
Olssy:
Also, pretty much any blogging solution is going to be using a database in the back end so a strategy for the mirrors will be needed before long.
The mirrors would not host the comments. The comments would be hosted on Tor Project infrastructure only. This is not a problem: comments are not what censored users need to access the most. -- Lunar <lunar@torproject.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The two beta partners they have now are How-to Geek and Boing Boing and I know the guys at Discourse are looking for a third beta partner before working on a hosted version for the masses. Maybe the Tor Project is a good match? - From the "Buy It" link: We are currently evaluating our options for third partner – who we hope will be equally amazing and definitely our largest yet, by volume. If you feel your organization is a good match, mail us, explain why you're a good match, and let's try to make a love connection. Seems like Tor and Discourse have several common goals and you could benefit each other. with kind regards, Nancy On 01/13/2014 05:46 PM, Olssy wrote:
Tor Website Team coordination mailing-list
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1CrsAAoJEIK75clYS/g4imsH/0PKVrUPLfIhgn0R1JEo+1+0 GyipcvHjkdGKbn1eOF/Jlk3seWksMSUgnOMfu7PxjvmcyTtZB9M+hjGWrrmaqzHL 34unORh9yPRzgUFCy/5KpgUDXPP6zjSZzWauuRSwDb/FqB6Loicx+POSFVtyH5yW dSbndHQspkvKg2oQXjF5u6zWmC9PKM4yNFRYedWoDupJOT2FZQAWZLc+8FKmkqJ4 koMUsmDVgAgJ+m2X1iJPhzE4volXxtAxr2NEavKHhmah8IYO8yzf2ttvPCjSo8zm pc7Pwu1b1lx4g8+K4Birz4IGAY7O2q8ftQqqal4YxRVwd+c8DXIYAYWNqJQzZhk= =0vbB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Luna, Looks like a little misunderstanding. I was referring to Discourse and since the developers envision their software as running in either hosted or "own server" environments, I bet they would work together with the Tor Project to implement Discourse in the way that was most suitable for your needs. Sorry if I was unclear - my native tongue has become my second language. :-) with kind regards, Nancy On 01/13/2014 07:30 PM, Lunar wrote:
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1QujAAoJEIK75clYS/g4vLAIAJ3p1E7U24LCZarn2OoPtHwF pI/vmlZ8sJW58/QaJrDBzDYiJwcPtDj/8Ga+gs7zKW7WXVCiIvDncnw9aE3jaYAq 9Owq0526/nS7MyQ2t6OPulV0XFm221fseM+GUTyfCs1U7UJ8quUcwrVf16QH1Z+9 tspvcnba+9h/uNIIYxv6pD88ksf3pO/7ZvuZesTP4DZAQDm53u5qEmiW2SxurH/B eH4K2yfOJzApV6/JMNScOcwNXSIrHji/YOPgpFqgfNnSK8rf54KHuDNphz+eM+zW QEBKeEiEzralb3aWgmsvWdlZfeB7q8sleP2tvf8rWGbCwrmsx/wl+2Wv4mUQV9k= =DO8a -----END PGP SIGNATURE-----
On 13.01.2014 17:46, Olssy wrote:
Just a small update: the now officially enabled discourse support in static sites: http://eviltrout.com/2014/01/22/embedding-discourse.html cheers Christian
On 01/22/2014 04:57 PM, Christian wrote:
I agree that Discourse seems to be very nice. I've been following the "comment subsystem" emails quite a bit, and I was hoping to help out. I thought it would be nice to try a POC with each of the comment subsystems that are being evaluated so we could see if they are viable. I therefore installed Juvia (https://github.com/phusion/juvia) on a VPS at the following URL: * http://juviatest.dyndns.org There's also a "test" instance of the Juvia server that is provided by Phusion (see the Github page for more details), but that sever is rebuilt daily. This Juvia instance will give us the ability to try a lot more things. If anyone is interested in trying it out, then please send me an email message and I will be happy to set up an account for you in that Juvia instance. I plan on running this VPS for at least a couple of months if anyone is interested. Tom Purl
For experimenting with the Middleman static site generator, I’ve set up a gitorious repo: https://gitorious.org/tor-middleman It’s minimally configured right now, totally bare bones. Anyone interested in this, feel free to clone it and start exploring how localization works (I’m looking at this as well). My primary focus on this right now is just getting a functional blog + event calendar going, since I’ve scraped this content from blog.torproject.org Have at it. Push updates. Restructure things that I did stupidly. Best, ultrasandwich
Tom Purl:
Thanks a lot for doing this! Have you kept notes of the installation procedure? Could you scribble something about that on ticket #10022? https://trac.torproject.org/projects/tor/ticket/10022 Details I can think of that matters: dependencies (and their availability on Debian), resource consumption, stability, updatability… It would be sad to loose your experience! :) -- Lunar <lunar@torproject.org>
On 01/23/2014 08:10 AM, Lunar wrote:
Yes I have. As a matter of fact, 99% of the server setup is done by Puppet modules, so everything is self-documented.
Could you scribble something about that on ticket #10022? https://trac.torproject.org/projects/tor/ticket/10022
I added sub-ticket 10713. I hope that's ok. I just felt that I needed a little more space to flesh out what I did.
Details I can think of that matters: dependencies (and their availability on Debian), resource consumption, stability, updatability…
I'll be sure to publish my build notes and custom Puppet modules soon. The good news is that my server is also running on Debian and I HATE installing software that's not in the official repo's. Thanks, Tom Purl
Tom Purl:
I don't know how much Puppet is already used on Tor Project's infrastructure. It might not be directly usable but it sure will help!
Smart move! :) I guess you can even assign the ticket to yourself.
That's how it's done on Tor Project's servers, so that fits perfectly. -- Lunar <lunar@torproject.org>
On Fri, Jan 24, 2014 at 10:00:42AM +0100, lunar@torproject.org wrote 3.0K bytes in 0 lines about: : I don't know how much Puppet is already used on Tor Project's : infrastructure. It might not be directly usable but it sure will help! We use it heavily to manage everything. -- Andrew http://tpo.is/contact pgp 0x6B4D6475
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, Clark, I was wondering that too. Maybe there is something I'm missing about this but my personal site uses Octopress, and at the moment it takes a few seconds to generate. This is really only painful when working with the design where I want to see my changes quickly, but for my normal day-to-day use it doesn't bother me at all. I believe there is also a command for stashing most of my posts until deploy, to improve the speed of the generate command. I haven't needed that yet. And finally, when the day comes that it takes "too long", I'll probably use the time to get a cup of coffee and check my email. with kind regards, N. On 01/10/2014 07:58 PM, Clark Venable wrote:
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0QMKAAoJEIK75clYS/g4weAH/1Yk4whxAkd7K8sWxFCqbBSo TlYyLDT/w3NJ/0zdbUGq8W5Pk9Zyb9TvvTqw3GE/28iKXU9HbPNiHc1PXd32rRHE kOThn8yj6+rv7J2NQIX29EnnbsEfJRPq7rwoTwAe+XTnqMbN6hzkahuM8/+iXGmD c2yQDbGuVokQ71M8tOhJJg01Wlj0zYy8q3GumvFFxardwOysAZDownZa7KHceBfn ANqohsb3zXKd9xnTfxL17gEx7xnqrT4pA8TXC9zzekTgZoPLDyopcN5duP2T5H/2 bmaTBY7C7315rEhVLOVa1iGN7xopYyOPu7hlCjFtYUEoUN14i0mcNHvmQu1tu4k= =cMMx -----END PGP SIGNATURE-----
On Fri, Jan 10, 2014 at 10:58:23AM -0800, jclarkv@gmail.com wrote 28K bytes in 0 lines about: : How often will the static files need to be rendered? The greater the time interval between static file generation the less speed of engine matters. Or an I thinking about this wrong? Generally, every two days or so. See https://svn.torproject.org/cgi-bin/viewvc.cgi/Tor/website/trunk/ for the current history. The current website in WML takes around 30 seconds to build a modern freebsd running on an intel i7-3667U. -- Andrew http://tpo.is/contact pgp 0x6B4D6475
@Andrew won't generation time be more frequent in the development stages, example, when designing the theme? -- Namanyay Goel Freelance designer/developer. UI Designer at MakeUseOf http://namanyayg.com/ On 12 Jan 2014 07:24, <andrew@torproject.is> wrote:
On 12 Jan 2014, at 12:46, Namanyay Goel <mail@namanyayg.com> wrote:
@Andrew won't generation time be more frequent in the development stages, example, when designing the theme?
of course it will but it shouldn’t be too hard to setup a smaller testing site with e.g. one page per content type. in one blog post I read about an option in jekyll that allows to exclude some content types from generation - if that’s indeed teh case than it should do the trick too.
thms/ao thomas lörtsch tl@rat.io hospitalstr. 95 tomlurge@someOtherServices °|´ d 22767 hamburg +49 173 202 71 99 ^^^ 30c3: To Protect And Infect, Part 2 http://www.youtube.com/watch?v=b0w36GAyZIA
If that could be managed well and everyone is comfortable with Jekyll then I think that will work out well. I am just concerned about generation speeds. -- Namanyay Goel Freelance designer/developer. UI Designer at MakeUseOf http://namanyayg.com/ On 12 Jan 2014 17:59, "thomas lörtsch" <tl@rat.io> wrote:
On Sun, Jan 12, 2014 at 05:16:29PM +0530, mail@namanyayg.com wrote 3.5K bytes in 0 lines about: : @Andrew won't generation time be more frequent in the development stages, : example, when designing the theme? We can live with 30 seconds to generate a static site. -- Andrew http://tpo.is/contact pgp 0x6B4D6475
Genuine question, how do you regen css on the fly with Jekyll? -- Namanyay Goel Freelance designer/developer. UI Designer at MakeUseOf http://namanyayg.com/ On 12 Jan 2014 23:08, "Moritz Süß" <moritz@moritzsuess.de> wrote:
Sorry, my reply was not clear enough. What I wanted to say was that you can do most of the theming without generating a Jekill-site. Therefore the build-time is not as important, since initially developing a theme can happen without even involving Jekill. Hope that was clear :) Am 12.01.2014 um 18:40 schrieb Namanyay Goel <mail@namanyayg.com>:
-----BEGIN PGP MESSAGE----- Charset: ISO-8859-1 Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ hQEMA71R6cQeOgKoAQf/fm689pwu8GGCGB8BEynsVmCPr6CvLdJhb6a8cxRLD37e LzRzPF+lQAwfSNN6Cu5CWXD6Vx58G9HtjcGI88hzCa59CoBBl5+PwC7/D4lNBw6/ GJBid3NmNJ81X42ax0MU08VcqFrmpxbye8TIl4dgVrmKBNDtS0HzNyI1UkdlgwUx VK4GQ8DhUXGY1hXOdj5fHaXo08tJ8AmJEGtTA3Ht4YATKujeIg2mruEHfzKYlJiz sZKqiGYLcGp7yI7r4dYLvib1W0KsW0YZIrb3vvjBTC1z8HlYnmlm2vS8uOHf4irM ow/xBfFNSjleIIW+0AnWnSe0bHzW1MtFmFJnmecTMdLpAdESS0X70oTU0BkRLkOf EgGjAc0IatDL3pn67O47k9KmufNpTKxeSKptjGLLVNRfw32o5p8QvoxmMHV22HCl v+g1JWWqEkKjs3XPHNTyZKbR+R27FFDqGruT9uVCx7jg9oS9TgZLjt1SnPR6W0/n PtmQT8+7SSiRzwQrJFA+RJOmnk0Vb5Ey0m8Qqtbo+i2lk3nxpGXJkuDgUcrcXBjY tn4RdmF3hGErkfBNADRdCHF1et6JwvPUcsGH4NOks1tBLA8Ao+naLrV3PmhZv24g NMFh8wYTZiFGUFANWeIewPf/UeRa7Y+AYJ5pQShT589rJHVBtIDWsOTD7H90XONH xWiBUNJEOUrwyqnaFJfYVAdHc4gvNMj8UzDcLIl8J2iUyDR+JQ/r9dXtYXJdb+zL ln6BogsXwj4MFSdUm/RmqReOXUTIy9f4wBC/F+gytd6m5QZEaw+xaU1cbywmGRiO rzYn5ASw3JjlmAvd1n/trNXu8jWXiUptI5HyqQesJCX6x/L3Qc0KyrNVp46P+gOu OcLHPEEjQM3A/OGNsEteHV9Kar9l+sg5mTKWoOoAnk3Fx6AZaFdmF0U/YzILN76M JKjzinA/eHAyJK3+SOXGnAtIbJFPC9nicrDgH5qUwX0Aq5P8SuJF6zd2i8xK4b/W r5VrElmeRzzwn31twf8Uc6RG1fBzDZ3Xh1sh+l/+D/zlv1HaXIeO+tcR144Z8JG7 Be0KTHr3pUMIvY8WfrqW7JicQyfcTpcuFB4Q8mqQT6V6u4Nvsb4fgA== =lLOz -----END PGP MESSAGE-----
Hi there, I too think we should probably go for something like Jekyll but alternatives like Middleman should be investigated more thoroughly. After all this is a decision with some consequences. Possible criterias: * support for mulitlinguality * support for large sites / complex navigation * performance * usability sugar like graphical admin frontend, wysiwyg markdown editor wouldn’t hurt * integration with Git (not sure if there are differences in this respect) Oh, and, btw: I’m Thomas, currently working on another Tor project and therefor more lurking in this one then actually being able to contribute much right now, but definitely interested. My expertise is more with HTML, CSS, Javascript, interface design, “information architecture”. I did a CSS based redesign of de.indymedia.org 10 years ago of which I’m still proud but got a little rusty with my web skills lately while I concentrated on trying to become a real computer scientist (by studying it at university, uh oh). Cheers Thomas On 10 Jan 2014, at 19:21, Namanyay Goel <mail@namanyayg.com> wrote:
thms/ao thomas lörtsch tl@rat.io hospitalstr. 95 tomlurge@someOtherServices °|´ d 22767 hamburg +49 173 202 71 99 ^^^ 30c3: To Protect And Infect, Part 2 http://www.youtube.com/watch?v=b0w36GAyZIA
On 10.01.2014 19:49, thomas lörtsch wrote:
We should definitely check if Jekyll has an easy way to support localization. There are plugins available that require the user/developer to install an additional gem ( https://github.com/liamzebedee/jekyll-i18n ). In my opinion, using something that supports i18n out of the box, without having to install other applications/gems, would be the better approach. cheers Christian
Jekyll seems very cool but are we sure editors and content creators prefer learning markdown than having a WYSIWYG editor in a web page? Is anyone who will be modifying the site in the future available to let us know what they prefer? Also, does Jekyll support users, roles and permissions or is this dealt with by file permissions? Will the site need more advanced features in the future that Jekyll doesn't provide such as shopping carts and forums? I have never used Jekyll so I don't know the answers to these questions but I think they need to be asked before a final decision is made. Here are some reasons I thought Drupal would have been a good choice: Static generation is already provided through at least 2 modules and can be implemented very quickly through the hooks that are provided out of the box. Many workflow modules exist to do things like e-mail translators when a certain piece of content is modified and needs updating. Supports users, roles, permissions, blogs, forums, localization, shopping carts, dynamic rss feeds, etc. Huge community of developers. On Fri, Jan 10, 2014 at 1:15 PM, Gvido Glazers <gvido.glazers@gmail.com>wrote:
I know Drupal well. It is very well suited to traditional CMS web projects, especially if there are a number of different parties supplying content in different areas of a website with workflows and approvals etc. In this case though this is not the way to go. Way too complex, not as easily scalable as static content delivery, considerable amounts of setup and design time needed to make it work for this organization. Crucial here is that it is not easily possible to integrate all the features of a good revision control system, such as revision history, easy roll-back, transparency and reproducibility. With static content served by one of the long-time trusted webservers, Jekyll and a revision control system such as git there will be a very simple, stable, transparent and portable environment which will stand a good chance of being easy to support even if in two or three years time a whole new team will be tasked with supporting it. +1 for static content provided by Jekyll or similar Am 10.01.2014 um 20:01 schrieb Olssy <olssy1@gmail.com>:
Then that bar should be markdown (IMHO). We're dealing with a great deal of text content here, the html generated (so long as it's semantic) is not really the issue. Markdown will be friendlier to the content creator or editor; case in point, I'm happy to write my static blog using it but I'd never be bothered if I had to do it in neat html. I'm sure that I can't be the only developer that feels the same way. A ______________________Label: Superstar DestroyerWeb: http://www.hipstersunite.netI write for Prog Magazine, The Fly, This is Fake DIY and build websites. Twitter: @hipsters_unite | LinkedIn From: selbrit@gmail.com Date: Fri, 10 Jan 2014 11:32:38 -0500 To: www-team@lists.torproject.org Subject: Re: [Tor www-team] [Back-end][CMS] On Fri, Jan 10, 2014 at 10:10 AM, Sean Rafferty <seanmrafferty@me.com> wrote: But there are a lot of content writers in the world that just don’t know it well enough. Then they can learn. If someone wants to contribute to a solution to a problem as complex as privacy and security, then learning markdown / HTML should be a minor investment of their time. Basic HTML takes little time to learn, and will instantly boost the self-respect of anyone who wants to help Tor and other software projects. Setting a bar is worth it, IMO. ________________________________________________________________________ Tor Website Team coordination mailing-list To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sean, I think you have made a good point, and one that really underscores the beauty of Jekyll. Content creators don't have to know any html, they write markdown in a text file with a bit of frontmatter at the top of the page to set-up tags / categories and the like. And, I'm guessing that people who are interested in becoming content creators for a technical project like Tor are pretty likely to be good with frontmatter and be happy to work in a text editor. I know I would be. +1 for Jekyll with kind regards, Nancy On 01/10/2014 04:10 PM, Sean Rafferty wrote:
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0QBaAAoJEIK75clYS/g4dXwH+wcqm/Eg8uBY43WlIVw2OSGO xkhUaNv9fyTU8Jnt+ZELjfwT13uFHb13mJHhDz71rXovsD5GV9Sk7IZlbILALToA 0SyMcz6dOqRIipsHayE765Gp/s6k5YtTG9WkIBBr53W/sXdCxAWSAvZemHHUwadm Z2PabrTWOexW1SKTeAQPm+eoU2ydxTs7jOA0N+k6ybZWku+dNCGpj+dqcbu1CWsC 0rtpywVztcl0Ov8RuVZSNIIYYB/WYM7xBz1K4UWu0eK/uCp6UEVFE/2MO2jBdnA/ TwIuXJTmZtfpm3/X6qhy3d/Sn0Gccad8SPr6p28q1Nb2uISCRdIA/fSakdYZ5JM= =kort -----END PGP SIGNATURE-----
participants (20)
-
Alex Lynham -
andrew＠torproject.is -
Christian -
Clark Venable -
Earl G -
Eric Schaefer -
Gvido Glazers -
Lunar -
Moritz Süß -
Namanyay Goel -
Nancy Carroll -
Olssy -
Rey Dhuny -
Rick Lubbers -
Sam E. Lawrence -
Sean Rafferty -
Silviu Riley -
thomas lörtsch -
Tom Purl -
William Papper