I've been keeping https://github.com/cubing/worldcubeassociation.org/blob/master/config/wca_envvars.rb.template up to date by hand, but it's annoying to do and easy to forget. ENVied looks like a good solution to this problem.

Gotta have it =)

Couple small things:

• Make sure the navbar is consistent everywhere
• Orange on blue = bleh (27e4d13)
• Make sure the navbar text is consistent...

@gagou9 suggested this. I've only ever found firewalls annoying, but it's probably a good practice. Here's @gagou9's config: https://paste.debian.net/177161/

I've created this issue to keep track of stuff I've found in various cubing/* repos that are just plain obsolete or are out of date.

• https://github.com/cubing/wca-website-php/wiki/Setup-0.-Overview (DELETED)
• https://github.com/cubing/wca-website/issues/5
• https://github.com/cubing/wca-documents-extra/blob/master/doc/wrc-member-addition.md (https://github.com/cubing/wca-documents-extra/issues/66)
  • The upload part of the regulations make script: https://github.com/cubing/wca-documents-extra/blob/master/make.py#L318
• The state of worldcubeassociation.org

Vestigial repos

• https://github.com/cubing/WCA-Drupal-Theme
• https://github.com/cubing/wca-website-php/tree/api (has been replaced by https://github.com/cubing/worldcubeassociation.org/tree/master/webroot/api)
• The whole cubing/wca-website repo and its issues
• https://github.com/cubing/dresults
• https://github.com/cubing/wca-website-theme

Looks like the live site has a robots.txt. It looks like this is generated by drupal. Do we need anything like that?

As far as I can tell, our HTTPS credentials are currently stored just on our dreamhost panel here: https://panel.dreamhost.com/index.cgi?tree=domain.secure&current_step=Index&next_step=Edit&dsid=24254776.

We'll need to store these somewhere else in order to automate server provisioning.

Currently, we don't include drupal in the repository. Adding it would be nice, but might not be worth the effort. I talked to @jbcm627 about this for a little while, and replacing it might be simpler than trying to add it to revision control in a good way.

Replacing drupal can be split up into two phases:

Read only (can coexist with drupal):

• Pulling all static pages out of drupal (easy to do)
• Pull binary files out of drupal (right now the images on https://dev.worldcubeassociation.org/?page=146 don't work (it tries to link to https://dev.worldcubeassociation.org/images/murciaopen2007.jpg). It looks like there are 1.2MB of images in ~/worldcubeassociation.org/webroot/drupal/images/. We could pull those into git, or wait to put them on S3...
• Link directly to posts? This seems useful. Do we need to preserve the pretty urls? Here's how drupal computes pretty urls: https://www.worldcubeassociation.org/admin/config/search/path/settings
• RSS feed
• Per user pages? NOT NEEDED

Writing to the db (not sure this can coexist with drupal):

• An accounts system (done in 996c019)
  • We need to know who is on the results team (#23) in order to know who is allowed to make posts.
• Form to actually create posts!

But people should only be able to configure applications they control. See 47750ae for where we locked this down to just site admins.

Something unobtrusive like on https://live.cubing.net/ would be nice. Could point people to github. A potential layout:

Powered by [link to github] | Contact

or perhaps

Fork me on github! | Contact

or

© World Cube Association | Contact | ... ?

is copywrite cheesy these days?

We don't want to let users choose any old WCA id. We'll give delegates the power to assign WCA ids, and leave it up to users to contact a delegate to assign them a WCA id.

A separate but related issue is to streamline this process for future first time competitors. See #21.

Right now, things are kept in sync via https://panel.dreamhost.com/index.cgi?tree=mail.addresses, an annoyingly manual process.

I'd like to automate this process based on #23. Until we move away from the dreamhost panel, we can't switch hosts.

This is an umbrella issue to track all ideas relating to the database export

• Permalink (#60)
• Currently, the db export takes quite a while. This post contains some ideas from @larspetrus for improving it.
• We've received reports that the TSV export has grown so large that it no longer fits into MS Excel. We don't necessarily have to do anything about this (there are 3rd party pieces of software to split TSV/CSV files into multiple files), but some people might really appreciate this.
• We currently have no way of knowing who uses the database export, and we have no way of contacting those people. To remedy this in the future, we could require that people use an OAuth application to download the export. (We could even get fancy and let them specify a webhook to be notified when database exports occur). In the mean time, this is Tim's suggestion for contacting software peeps:

Another idea would be to create a wca-software-announce mailing list, which people can subscribe to through google groups. That might have the positive side effect of exposing some of the things that you're working on to people who could theoretically be interested in working on them. Then you can advertise that list by posting on speedsolving/wca site/delegates list "we have this backwards-incompatible change coming up, get ready, oh and by the way we'll announce other stuff to this list". Then ask the delegates to forward to their local software people.

I imagine we'll have a 6 month - 1 year period of time where we continue to support the old database export while telling people to switch to the new one. NOTE: We'll have to update the WCA workbook assistant before we disable the old export.

All the cron jobs on https://panel.dreamhost.com/index.cgi?tree=goodies.cron& must become part of provisioning a (non-dev?) VM.

Something reddit style with threading and voting might be pretty cool, and probably share code with #136.

It also might be desirable to move delegate report discussions off of the delegates mailing list. This could all be started by #222.

I believe we'll need PEAR set up for emailing to work on the new server. @jbcm627, do you know what other things we use from PEAR, or is it just email?

I don't know if we really want mail to work in the dev environment (we don't want test emails to actually send). If we do, then installing PEAR could be useful.

Maybe we should just use Javascript back?

Would be good at some point. I don't think we need an automatic search or anything for 404s, but something cute, at least :)

Right now, the popup you get when authorizing an application includes the navbar, which is a little odd.

These are currently stored in the /home/cubing/worldcubeassociation.org/webroot/results/upload/ directory on james-smith. We'll need to move these elsewhere in order to migrate servers, one possibility is Amazon S3.

Right now it won't run with our production nginx config. We'll have to fix this before we move away from dreamhost.

I see a phpMyAdmin install here on james-smith: /home/cubing/worldcubeassociation.org/results/admin/phpMyAdmin/

but I see no such thing here: https://github.com/cubing/wca-website-php/tree/master/admin.

@jbcm627 do you know how this phpMyAdmin directory came into existence?

I worked pretty hard to make sure that stuff works in both Windows and Linux, but unfortunately, I had to resort to symlinks for the rails public/assets, public/files, and public/images directories.

We may be able to get things working on Windows by falling back to having rails serve up static content: https://github.com/cubing/worldcubeassociation.org/blob/master/WcaOnRails/config/environments/production.rb#L25.

https://github.com/smdahlen/vagrant-digitalocean is quite nice, but vagrant isn't the right tool for spinning up production servers. Instead, I think we should have a single command to run on a fresh Ubuntu 14.04 server. It's important that this command play well with vagrant development mode, though.

This is @gagou9's area of expertise. To have a truly one step deploy, we will need to include phpBB or replace it. I'm not familliar with how phpBB upgrades work.

@lgarron talked about potentially dropping the forum entirely, which would certainly make everyone's jobs easier =)

@gagou9, could you look at https://staging.worldcubeassociation.org/forum/ and investigate if email is working? I didn't see any configuration for email in the config.php for phpBB. See https://github.com/cubing/worldcubeassociation.org/blob/master/chef/site-cookbooks/wca/templates/forum_config.php.erb.

The following folders exist only on the WCA website (and backups):

./history/files/ => Copies of old regs and scramblers
./history/official => Old versions of regs manually placed here and linked from https://www.worldcubeassociation.org/regulations/history/
./scrambles/tnoodle (and ./scrambles/tnoodle/old) => TNoodle binaries

In the interest of one step deploy and development setup, I'd like to think about what our options are for these files. @lgarron says "I don't care what we do with them, as long as we don't lose them. I would prefer not to put them in a general repo, because it adds up to > 60MB." I agree that this is a painful amount of data to add to just any repo. @lgarron, how do you feel about yet another branch on cubing/wca-documents? I'd be willing to drive this and update make.py to automatically check out these files.

We currently automatically generate auxiliary data in setup_db_interactive.sh. @jbcm627 pointed out that we're probably missing a few:

 James:  other pages might need generating too (stats, export, ...)

We currently rely upon Dreamhost to handle email forwarding for our domain: https://panel.dreamhost.com/index.cgi?tree=mail.addresses&. If we want to move away from dreamhost, we'll have to figure out a replacement for this.

Controversial issue from https://github.com/cubing/wca-website/issues/10. Some stuff we should definitely do:

• Remove table-based layouts, and use something like http://plugins.jquery.com/StickyTableHeaders/
• Add alt/title attributes to all images.

As we handle the OS, we have do handle the logs as well or it's all gonna get messy :)

I just recalled that this exists:
https://www.youtube.com/user/worldcubeassociation
There might be more things out there of use too. I vaguely recall a twitter account, but maybe that was just CubingUSA.

Right now, the only place we set the page subtitle:

app/views/layouts/application.html.erb:  <title><%= full_title(yield(:title)) %></title>

On the drupal site, we had subtitles in many places. See https://www.worldcubeassociation.org/posts/us-nationals-2015-july-31-august-2-2015-hilton-head-island-south-carolina-usa, which has <title>US Nationals 2015 on July 31 - August 2, 2015 in Hilton Head Island, South Carolina, USA | World Cube Association</title>

Now that drupal is dead!

One minimally invasive idea would be to have the WCA collect emails (or even better: WCA user ids) as well as birthdays, gender, name, and country. In the future, we could streamline this even more by doing competition registration on the WCA site.

Related: #31.

The useful stuff from this file https://github.com/cubing/worldcubeassociation.org/blob/master/webroot/.htaccess must be ported to our nginx configuration: https://github.com/cubing/worldcubeassociation.org/blob/master/chef/site-cookbooks/wca/templates/default/worldcubeassociation.org.conf.erb

Fail2ban will block IPs trying to do weird stuff on our ports.
It will use iptables to block them, and will unblock after a time. (or not)

Right now if someone wants to organize a competition, they have to go 'find their delegate,' resulting in email chains and random 10 year olds with no clue begging for competitions with no idea how to run one.

Wouldn't it be great if there were a page on wca.org that allowed you to 'request a competition consult'?
Such a page would require you to input:

• dates applicable
• requested events
• competition name
• contact details
• where you've already found a location (less back and forth for delegates)
• etc.

Upon submissions, delegates could choose to respond to the requests through a tiny workflow, depending on their personal schedule.

Thoughts?

There's https://github.com/infinum/cookies_eu which might help us be polite and obey http://www.cookielaw.org/the-cookie-law/.

Right now, I can't find any way to do that with our current ui. If nothing else, this would be useful for testing.

Right now anyone can access /oauth/applications. We should put this behind our devise accounts, and only allow people to edit applications they created.

1. Add the token preload to the Strict-Transport-Security header.
2. Submit worldcubeassociation.org (not www.worldcubeassociation.org) to https://hstspreload.appspot.com/

This is easy to do, but I've put it on hold due to Jeremy's work.

There are board members, website team members, results team members, delegates. I don't know if the WDC or WRC members will have any special powers on the site, but storing who is on the various teams still seems good to me. This data, plus the knowledge of who the leader is, will allow us to autogenerate the /about page, the /delegates page, and the /contact page.

We may also need to know who our delegates are in order to implement #22.

Right now, there are 2 things standing in the way of that:

1. https://github.com/cubing/wca-website-php is a private repo, and we have a submodule pointing to it.
2. Full database exports are only accessible by ssh-ing to the live server.

There are still some regulations files that are not in git. There is PR here https://github.com/cubing/wca-documents-extra/pull/64 to fix that, but it has not been merged up yet.

Dumping discussion with @jbcm627:

i need to squelch the php warnings
James: ah
me: do you know anything about that?
James: you can edit php.ini, or:
run error_reporting(E_NONE); in the code somewhere
me: ahh
James: but that might hide errors from logs too
so there is also
me: ah
James: ini_set('display_errors', 0); or something
I'm not really sure about behavior
but googling those might tell you
me: ok
seems like something we could set iff that admin flag is not passed in
?
James: in the php code? yeah
or maybe debug?
me: yeah
errr
debug, that's what i meant
thanks

Have a script (as decoupled from everything and robust as possible) that monitors the status of things, and alerts someone when things go down.

See https://groups.google.com/d/msg/wca-software/dX1Enl1Iy0U/7ohRaCqCYGUJ and https://github.com/cubing/wca-website/issues/22