Automate listing upcoming events on the index #559

mvz · 2014-10-05T06:08:23Z

Do not merge this yet!

This is a first baby step toward fixing #557. It introduces Jekyll and converts two event pages to being posts. Also, it shows posts that represent upcoming evets on the index page.

To see the result, run jekyll server --watch.

- Move page to posts directory - Add metadata - Autogenerate upcoming event entry on index.html

Unlike for a blog, the 'oldest' upcoming event needs to be shown first.

This is a slightly awkward solution, since the 'current' date has to be set manually in a variable for now.

FloorD · 2014-10-05T09:17:23Z

😍

Lieke22 · 2014-10-05T09:50:18Z

That will make it so much easier 😄

alicetragedy · 2014-10-05T12:09:34Z

awesome!!!!

hsbt · 2014-10-05T12:59:25Z

How to deploy jekyll's sites into railsgirls.com?

Maybe railsgirls.com are using dedicated server. so, It's not only repository issue. I think we need to change server configuration too.

lindaliukas · 2014-10-05T14:41:57Z

Yup - so currently @ksaa knows this system best.

And the other thing is, the documentation and instructions needs to be
super good. This is going to be the first time for a lot of people that
they try out Jekyll or start a server and so on. I'll try to write
something too.

On Sun, Oct 5, 2014 at 2:59 PM, SHIBATA Hiroshi [email protected]
wrote:

How to deploy jekyll's sites into railsgirls.com?

Maybe railsgirls.com are using dedicated server. so, It's not only
repository issue. I think we need to change server configuration too.

—
Reply to this email directly or view it on GitHub
#559 (comment).

mvz · 2014-10-06T04:53:46Z

The general idea is to let jekyll generate the site and then upload the result. So, the server config stays the same, except you upload the contents of _site to it, rather than /.

mvz · 2014-10-06T04:59:30Z

Ok, I just looked at deploy.sh (should've looked at it first), and it looks like there will need to be some changes to the server and the whole deploy process.

Bertg · 2014-10-06T06:58:46Z

@mvz @hsbt actually, if vanilla Jekyll is used the site can be completely hosted in Github, even with the custom domain name. I see the current Railsgirls github page is forwarding to the guides page, so this could be an option.
The cool thing that a real deploy would not be needed. Just merge, and it'll be updated by itself.

lindaliukas · 2014-10-06T08:23:23Z

That would be super good, would save a lot of confusion and possible broken merges.

On Mon, Oct 6, 2014 at 9:58 AM, Bert Goethals [email protected]
wrote:

@mvz @hsbt actually, if vanilla Jekyll is used the site can be completely hosted in Github, even with the custom domain name. I see the current Railsgirls github page is forwarding to the guides page, so this could be an option.

The cool thing that a real deploy would not be needed. Just merge, and it'll be updated by itself.

Reply to this email directly or view it on GitHub:
#559 (comment)

Bertg · 2014-10-06T08:31:14Z

Yeah. However, shuffling the projects around can be a bit of a hassle. The github site MUST be placed in a repo named railsgirls.github.com http://railsgirls.github.com/.
If we want to do this, this should be well coordinated.

On 06 Oct 2014, at 10:23, Linda [email protected] wrote:

That would be super good, would save a lot of confusion and possible broken merges.

On Mon, Oct 6, 2014 at 9:58 AM, Bert Goethals [email protected]
wrote:

@mvz @hsbt actually, if vanilla Jekyll is used the site can be completely hosted in Github, even with the custom domain name. I see the current Railsgirls github page is forwarding to the guides page, so this could be an option.

The cool thing that a real deploy would not be needed. Just merge, and it'll be updated by itself.

Reply to this email directly or view it on GitHub:
#559 (comment)
—
Reply to this email directly or view it on GitHub #559 (comment).

hsbt · 2014-10-06T11:21:03Z

The github site MUST be placed in a repo named railsgirls.github.com

railsgirls.github.com is already used by guides.railsgirls.com. We can not use this domain.

Bertg · 2014-10-06T11:44:30Z

@hsbt Actually, I dove a bit deeper into the pages system and noticed that this IS possible. https://help.github.com/articles/user-organization-and-project-pages/

This would make deploying a bit less easy, unless the gh-pages branch would become the default one.

hsbt · 2014-10-06T12:02:32Z

@Bertg Is your consideration following situation?

railsgirls.github.com repos => guides.railsgirls.com
railsgirls repos => railsgirls.com

Bertg · 2014-10-07T07:26:02Z

@hsbt Yeah, that could work. So we leave the railsgirls.github.com as it is.
We can then serve the Jekyll version of www.railsgirls.com from the gh-pages branch in this repo.

hsbt · 2014-10-07T07:32:09Z

@Bertg www.railsgirls.com? it's chaged from railsgirls.com. I worried it make permelink in railsgirls.com to deadlinks.

PS. I'm not against this PR

mvz · 2014-10-07T14:34:55Z

Anyone picking up the other points from #557, please feel free to add commits to this branch.

Adding 2 types of images: event and index images.

andreionut · 2014-10-07T22:00:41Z

Great find, @mvz .

I am working on a script that migrates the old pages to the new format, so I'll assign that to me.

ksaa · 2014-10-07T22:18:56Z

My comments:

Right now the site is just a collection of html pages and my server which hosts the railsgirls.com domain just pulls in the content.

It's definitely a hacky system and not that great but it has the advantage that it can't really break, and it's very accessible to different skill levels. You can just copy the html file, make changes with notepad and open it with your browser.

I like Jekyll, and jekyll or middleman has been on the table before. I think some of the problems are however:

You need to install bundler or the correct version of the jekyll, and possibly related gems
One mistake in a file can break the site rendering and jekyll error messages are not that clear
Deployment seems always bit hacky – you need to always remember to pull and render the changes when uploading (otherwise you overwrite the site) or use gh-pages (but they also randomly cache the content and you have no control over it)

One option would be a simple app, where you can submit the event details to a form online and the app generates the event and the event index page.

If we end up going Jekyll, it should be as out-of-the-box as possible and like @lindaliukas said, really good documentation how to use it and how to troubleshoot problems.

The events listed in the index and the index page were converted into posts.

andreionut · 2014-10-07T23:41:39Z

I've did the first part of the migration of the events.
The issues that I see now are related to images and how they fit in their place in the events page. I will take a look at generating consistent size images for that page.
Next step should be the unlinked events and generating the feed and api.

We need to look into the issues raised by @ksaa as this automatic index/events page won't really work unless we generate the site at least once a day.

An app for submissions is a good idea as we can check in there for errors and missing details.

csaunders · 2014-10-10T15:23:18Z

Would it be possible to integrate Travis into this to provide some feedback on the mergability of the updates people are making.

A nice thing about using something like regular files / jekyll is they are easy peasy to understand and backups are simple.

I totally get the UX problem though. Would the app be a jekyll wrapper or would it simply be a web app?

csaunders · 2014-10-10T19:43:25Z

@andreionut could just glue into the github webhooks to make the server re-run jekyll whenever something is merged into master.

hsbt · 2016-05-31T02:26:07Z

This pull request is no activity from Oct, 2014. Current master is huge differences from it time.

mvz · 2016-05-31T07:53:23Z

@hsbt Do you still consider #557 something that should be implemented?

hsbt · 2016-05-31T12:03:07Z

No objection. But I oppose to migrate jekyll without providing instruction guide to non-programmers.

mvz added 6 commits October 4, 2014 20:50

Add basic Jekyll setup

84f041d

Make Silesia event page a post

4e2ec07

- Move page to posts directory - Add metadata - Autogenerate upcoming event entry on index.html

Move Penang page to posts

d35d37a

Add a 'none' layout to keep Jekyll happy

0498fb8

Show events in chronological order

af225dc

Unlike for a blog, the 'oldest' upcoming event needs to be shown first.

Only display events in the future

c16638e

This is a slightly awkward solution, since the 'current' date has to be set manually in a variable for now.

andreionut added 2 commits October 7, 2014 21:42

Use site's date to compare the event's date

23a4cc3

Test a future event for the new display logic.

f6982a1

Adding 2 types of images: event and index images.

andreionut added 4 commits October 7, 2014 23:42

rename datedescription into date_description

c35fe4c

Add migration script

f9166aa

Update migration script

361b528

First batch of the migration.

9ff743c

The events listed in the index and the index page were converted into posts.

Bertg mentioned this pull request Oct 10, 2014

Replace static event pages with generated versions #557

Open

6 tasks

hsbt closed this May 31, 2016

hsbt mentioned this pull request May 31, 2016

Updates some templates and corrects docs #562

Closed

hsbt deleted the issue-557-automate-index branch May 31, 2016 02:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Automate listing upcoming events on the index #559

Automate listing upcoming events on the index #559

mvz commented Oct 5, 2014

FloorD commented Oct 5, 2014

Lieke22 commented Oct 5, 2014

alicetragedy commented Oct 5, 2014

hsbt commented Oct 5, 2014

lindaliukas commented Oct 5, 2014

mvz commented Oct 6, 2014

mvz commented Oct 6, 2014

Bertg commented Oct 6, 2014

lindaliukas commented Oct 6, 2014

The cool thing that a real deploy would not be needed. Just merge, and it'll be updated by itself.

Bertg commented Oct 6, 2014

The cool thing that a real deploy would not be needed. Just merge, and it'll be updated by itself.

hsbt commented Oct 6, 2014

Bertg commented Oct 6, 2014

hsbt commented Oct 6, 2014

Bertg commented Oct 7, 2014

hsbt commented Oct 7, 2014

mvz commented Oct 7, 2014

andreionut commented Oct 7, 2014

ksaa commented Oct 7, 2014

andreionut commented Oct 7, 2014

csaunders commented Oct 10, 2014

csaunders commented Oct 10, 2014

hsbt commented May 31, 2016

mvz commented May 31, 2016

hsbt commented May 31, 2016

Automate listing upcoming events on the index #559

Automate listing upcoming events on the index #559

Conversation

mvz commented Oct 5, 2014

FloorD commented Oct 5, 2014

Lieke22 commented Oct 5, 2014

alicetragedy commented Oct 5, 2014

hsbt commented Oct 5, 2014

lindaliukas commented Oct 5, 2014

mvz commented Oct 6, 2014

mvz commented Oct 6, 2014

Bertg commented Oct 6, 2014

lindaliukas commented Oct 6, 2014

The cool thing that a real deploy would not be needed. Just merge, and it'll be updated by itself.

Bertg commented Oct 6, 2014

The cool thing that a real deploy would not be needed. Just merge, and it'll be updated by itself.

hsbt commented Oct 6, 2014

Bertg commented Oct 6, 2014

hsbt commented Oct 6, 2014

Bertg commented Oct 7, 2014

hsbt commented Oct 7, 2014

mvz commented Oct 7, 2014

andreionut commented Oct 7, 2014

ksaa commented Oct 7, 2014

andreionut commented Oct 7, 2014

csaunders commented Oct 10, 2014

csaunders commented Oct 10, 2014

hsbt commented May 31, 2016

mvz commented May 31, 2016

hsbt commented May 31, 2016