Fix Brighter Tomorrow Map compiling errors

This task is null if this one is completed first.

Without DCS branch is loading fine. The issue is the auto compile set up with Travis. is running perfectly. is doing something weird.

If I make changes to the withoutdcs branch they change the live site, so it is loading that branch. There are a whole load of random differences between the two though, for example the shape of some buttons. I think it is also loading the old master branch and then smushing them together.

Docus isn’t working on it either so the forum wont load, but that’s a different issue (probably).

@syl the brighter tomorrow map could be a huge help to the many people who are homeless and struggling as all their safety net is shut down (shelters, food give aways, etc). Can you see why Docus stopped working on it? Its been down for so long i can’t remember what the issue was.

As far as I can tell, still uses the old system where the Discourse forum was loaded in an iframe. Also, the app tries to load a forum from address, but this address doesn’t exist anymore.

With the new system, should point directly to a Discourse instance. Then the app would be automatically loaded in an iframe within Discourse.

Ah, ok. So we need to basically redeploy a new discourse instance with the Docus plugin pointing at our GitHub branch?

Yes, you need to mirror Publichappinessmovement deployment.

1 Like

Ok, so the plan of action looks to be:

  1. Create a new Discourse instance.

  2. Set the Brighter Tomorrow map branch live at …or @tmcnulty where is the current app deployed on phm, we should mirror that system? i dont see it at - auto deploying from Travis

  3. I’ll edit the Docuss plugin settings and we should have Brighter Tomorrow Map up and running again.

The even better version of this fix (linked at the top) would be to use this opportunity to create a third instance as a development server and ask all other instances to watch it for approved changes (new version updates), which would greatly increase the speed we are developing at.

@system @ReactMeteor @RubyonRails

It would be very useful for all the people who are homeless around the world if we could get the Brighter Tomorrow Map running smoothly. Once its up again we can also tell the world they can use the platform so elderly people nearby, or people in quarantine, can post their shopping lists and young healthy people can pick items up for them when they go shopping and leave it at their doors. I think it’ll help a lot of people who need support very quickly.

I’ve got a video meeting with a new dev who’s offered to help set it up again in around 20mins to discuss it. I know its short notice but you would be welcome to join us. Can also hold another one tomorrow… or anytime for anyone who wants to contribute.

@syl i remember you got ‘auto following’ in Docuss of threads working for people who post themselves onto the map but we didnt have anyone around at the time to install it. Could you outline whats needed to get that running, or would you mind setting it up for us.

With a push we can get this out in a day or two and begin helping support society dealing with the horrible virus :sunglasses:

@UI-Design @UXers this should be our main focus for the next month or two. Using our work to help society. If you’d like to join in improving the maps, user flow, and that homepage please join in. Also invite any friends of yours who suddenly have an abundance of free time and want to do something to help this global crisis.

@SysAdmin the current branches on Github are master_withoutDCS and fl-sleeper. ‘Master’ is not active and shouldn’t be linked to anything (we probably should use this opportunity to delete/rename it and rename master_withoutDCS to Master. Its not live, and we’d just need to change Travis settings to point to the changed branch name).

@tmcnulty and @ArtyS It would be great if you could share what you know about the databases. Specifically from the view of if we reinstall the brightertomorrowmap app, how would we hoook it to the existing database. Also Tom, you’ve launched a new Discourse instance before. Is that something you could do again without too much effort? If so it would save someone new learning how to do that.

Finally we need to decide if we are launching one new instance, or mirroring everything we do here to launch a third development site that devs can test new code on live.

I’m not available to do the implementation work, but you can hook me up with the dev and I will help him. The feature is documented here:

1 Like

@zofrex just tagging you so others can join your rebuilding today if they come online

Unfortunately I didn’t end up having a lot of time to spend on this today, but I’ve come up with an outline plan of things to do and how to do them:

  • New Discourse instance - I’m planning to set the server up with Ansible, unless anyone has strong opinions to the contrary. This should make it a lot easier to set up an additional one later for dev. I don’t particularly endorse Ansible as the best tool for the job, but it’s one of the easiest to get up and running with. If you have strong opinions that we should use e.g. Puppet instead or something, let me know.
  • Deployments - I’m not familiar with mup so I’m still getting my head around that stuff but I think it would be nice to move away from having encrypted tarballs, and have the non-sensitive parts of the deployment files visible. There are some tools that can then plonk in encryption keys and passwords and so on into the files as part of the build process.
  • Deploying the two sites - I think it would make sense to have two branches still, one for each site - otherwise you won’t be able to deploy one without deploying the other? These could be the same 99% of the time, but having that flexibility would probably be useful. We could make the travis build script key off the current branch to decide which site to deploy, perhaps. If you’re certain you will always want the same code on both sites, we can fix it up so Travis always deploys both.

I’m sure there’s more to do that I haven’t got my head around yet, but let me know if you are or aren’t happy with the above and I can make some movement on them.


thanks for laying this all out.

Everything sounds great to me, except for the branches as the other devs discussed it fairly recently and came to the conclusion it was best to strip things down to one branch, as the other kept falling behind and we had constant issues with an ever fluctuating team of devs. The lack of consistency inherent in our operations made the two branches a bit of a nightmare to maintain. The system we’re moving towards is a development branch with the others all running the same code and defining their differences via i18n called in based on the url.

That was then planned to transition to a core codebase all projects running our code can contribute to, and a plugins library for anyone who wants to build specific customisation. That will likely be around 6 months away, but will also allow many more people to make use of and contribute to advancing our codebase.

After this before its functional we also need to install the code that @syl linked above.

1 Like

I agree it’s a good idea to have the same code for all sites, and effectively “one branch” in that sense - copying code or cherry-picking commits to keep sites up to date is a lot of work.

I still think it’s worth considering using branches to control deployment, even then. In my experience it’s likely you’ll want the ability to deploy to just one site or the other sometimes. Here’s how that might look:

All the code for both (or all, in the future) websites lives on the “master” branch. All PRs are made to master, all new code is sent to master when it’s ready.

You also have branches to track deployment. For example those might be named “release-phm” and “release-btm”.

When you want to deploy the changes you have on master to phm, you would do:

git branch -f release-phm master
git push

to point the release-phm branch at the latest master, and thus indicate to Travis that you want to deploy it. This is a lot less work than cherry picking, but you still retain control over which sites to deploy at which time.

Of course this is just my two cents, if you want just the one branch to deploy both (all) sites that’s do-able :slight_smile:


Yes, that does sound more sensible although not my area of expertise. We can then built that into a notification and upgrade button in the admin section in the future, so it would be a step further towards that. I love the idea of reducing the amount of sensitive areas and key holders necessary. the more we have in the open for everyone to see and use the better as long, as it doesn’t compromise security @SysAdmin @RubyonRails and @ReactMeteor what do you think?

1 Like

I collected ideas on Reddit a while back which are worth reading to guide that 1st step:

@bob do you think it’s possible to get the apps ready for brighter tomorrow map this week so we can push those out with the relaunch?

We have the graphic ready to go for that one

I think theres a few things that need to be fixed in BTM before it can be used on mobile. When you open the map using Chrome on Android, the UI doesn’t fit the screen properly so the map is a bit small and part of the location list becomes unusable. I can’t recall if it was like that before, I’m sure I would’ve spotted it before. Can you check if its like that for you?

Also the forum on the side panel doesn’t load at all and it’s been like that for a while now.

I could probably get an Android app out if the map issue is fixed. The app would only be like opening the website in a browser though.

1 Like

in a few days it will be the exact same code as :slight_smile: just running from a different url

Hey, any front end stuff I am willing to help. I think Andy said there maybe something to do with notifications, and your using react?