This seems to have been inadvertently broken in this commit [1]. Perhaps
even the GitLab Web IDE was confused by the "duplicate" image files...?
[1]: f0f0c3aea7
Both Blake House and Open Data Services were already using lowercase
version of the Power to Change client markdown and image files, i.e.
`_clients/power-to-change.md` and `images/clients/power-to-change.png`.
So the uppercase versions of the files, i.e.
`_clients/Power-to-Change.md` and `images/clients/Power-to-Change.png`,
were effectively duplicates.
This led to the following warning messages on case-insensitive
filesystems, making it hard to work on the project on such systems:
> warning: the following paths have collided (e.g. case-sensitive paths
> on a case-insensitive filesystem) and only one from the same colliding
> group is in the working tree
In this commit, I've added the website from `Power-to-Change.md` into
`power-to-change.md`, deleted `Power-to-Change.md` &
`Power-to-Change.png`, and changed the reference in `dot-project.md`
from `Power-to-Change` to `power-to-change`. I think this is the right
thing to do, because ideally all the markdown files should be lowercase
in case they are used in URL paths.
Although no coops seem to be referencing this client, there were already
lowercase versions of the relevant files, i.e. `_clients/kaspersky.md`
and `images/clients/kaspersky.svg`. So the uppercase version,
`Kaspersky.md` was effectively a duplicate.
This led to the following warning messages on case-insensitive
filesystems, making it hard to work on the project on such systems:
> warning: the following paths have collided (e.g. case-sensitive paths
> on a case-insensitive filesystem) and only one from the same colliding
> group is in the working tree
In this commit, I've deleted `Kaspersky.md` which didn't contain
anything different to `kaspersky.md`. I think this is the right thing to
do, because ideally all the markdown files should be lowercase in case
they are used in URL paths.
There are other similar issues, but I plan to address them in separate
commits.
Both Blake House and InFact were already using lowercase version of the
CAST client markdown and image files, i.e. `_clients/cast.md` and
`images/clients/cast.png`. So the uppercase versions of the files, i.e.
`_clients/CAST.md` and `images/clients/CAST.png`, were effectively
duplicates.
This led to the following warning messages on case-insensitive
filesystems, making it hard to work on the project on such systems:
> warning: the following paths have collided (e.g. case-sensitive paths
> on a case-insensitive filesystem) and only one from the same colliding
> group is in the working tree
In this commit, I've added the website from `CAST.md` into `cast.md`,
deleted `CAST.md` & `CAST.png`, and changed the reference in
`dot-project.md` from `CAST` to `cast`. I think this is the right thing
to do, because ideally all the markdown files should be lowercase in
case they are used in URL paths.
There are other similar issues, but I plan to address them in separate
commits.
I think having the seperator is not properly supported by the
foundation CSS. I was a bit confused with app.css as some seems to
be vendor CSS and some custom CSS, so I left the original padding
rule, and added an override in what seems more like a "custom CSS"
section...
I don't know why they didn't all just float nicely
together in the first place though :/
As the map tab is created hidden by default, leaflet seems unable
to deal with the sizing properly initially, but we can hook into
the "tab changed" event, and tell leaflet to recalculate the size
after switching tabs
We don't have a process to ensure that emails to our internal list
(contact@coops.tech) are replied to in a timely manner/at all. At the
moment we appear to have 5 legitimate emails from the 13 March that
don't appear to have replies.
I hope that encouraging people to post to the forum will increase the
chance that they receive a reply.
I think there are further improvements we can make, by clarifying the
joining process for example, but this is a good enough start.
I'm not sure the distinction between Python and Python 2 is
particularly helpful, and because they share a logo it means we appear
to have python listed twice under technologies. I've replaced
instances of `python-2` with `python` to fix.
I'm pretty sure this was also a problem on the Wordpress version of the
site, but I think I fixed it by removing the single quote from the very
same address.
Also ensure newline at EOF.
This was achieved by running the new normalize_coop_frontmatter.rb
script which basically reads in the frontmatter, parses it and dumps it
back out.
I had to manually fix some telephone numbers which had been incorrectly
parsed as some kind of number rather than as strings.
I've populated the data, where available, from the field "Number of
current members The number of full members (owners) in the co-op." in
the wordpress admin.
Showing all of the client logos adds a considerable amount to the page
weight of the page. This change shows 6 random clients. It will be
re-generated each time the page is deployed, which might be OK for
now, although we could add timed pipeline to keep this fresh/fair.
This updates the number to be the same as it currently is on
coops.tech. There's a separate
issue (https://git.coop/cotech/website/issues/29) to populate this
from the YAML front matter in each file under `_coops`.
This repo is [hosted at git.coop](https://git.coop/cotech/website) and [push mirrored to GitHub](https://github.com/cotech/jekyll-website).
If you would like to contribute to this repo you have two options:
1. [Join Webarchitects](https://webarch.coop/join) to [create an account at git.coop](https://webarch.coop/git#free) and then request access to the [CoTech group](https://git.coop/cotech) and when that has been granted you can update this repo directly.
2. Use a GitHub account to create a [pull request](https://github.com/cotech/jekyll-website/pulls) at GitHub and then ask someone who is a member of [Webarchitects](https://www.webarchitects.coop/) to [patch the repo for you](https://community.coops.tech/t/cotech-website-repo-mirroring-to-github/2818).
## Introduction
This is a port of the current Wordpress version of the [CoTech Website][] to a statically-generated site using [Jekyll][].
This is a port of the old WordPress version of the CoTech website to a statically-generated site using Jekyll. The site consists of a bunch of markdown files and images stored in git.coop. The Jekyll build process is automated so that there is no need to have Jekyll installed and running to make changes to the site.
* Live site: https://coops.tech/
* Dev site: https://dev.coops.tech/
## Updating the site
It is possible to edit markdown files and upload images through the [GitLab Web IDE](https://docs.gitlab.com/ce/user/project/web_ide/). To use this, got to the [GitLab website page](https://git.coop/cotech/website) and click the Web IDE button to the left below the toolbar.
Each page type lives in it's own folder.
* _clients contains client pages
* _coops contains coop pages
* _services contains service pages
* _technologies contains technology pages
To change a coop page, edit the relevant coop file in the _coops directory. Each file contains a metadata block at the top of the file, followed by the main text describing the coop. The metadata block contains the coop details and lists of clients, services and technologies associated with the coop.
If using GitLab Web IDE, make your changes to the relevant files and then commit your changes by clicking the commit button in the bottom-left corner. Add a brief description of the changes you have made as a the commit message and then click 'Stage & Commit'. It is okay to commit to the master git branch if you are simply updating your coop details, but if you are making extensive changes to many coop pages it is better to create a new branch and merge request and ask someone else to review your changes before they merge your changes in the master branch.
Once your changes have been committed to the master branch an automatic build of the dev site is triggered. This will take a few minutes to run and you can check the status of the build here: https://git.coop/cotech/website/pipelines. Once the build has completed you will be able to see your changes on the dev site: https://dev.coops.tech/.
If you're happy with they changes on the dev site, then you can deploy them to the live site. See the Deployment section below on how to do this.
### Adding new clients, services and technologies
You will need to add a new markdown file in the relevant directory for the new item. The file only needs to contain a metadata block with the details describing the new item, this is typically just a title and name (which are usually the same), but look at other items for examples.
Along with the new file you will also need to upload a logo or image for the new item. Images live in a sub-directory of the images directory and should be named the same as the markdown file, but with a .png extension. Images should be formatted as a PNG and optimized for the web.
Once the new file and image have been created then you can add the new client, service or technology as a list item in the metadata section of the relevant coop file.
## Run the site locally
You can run the site on your computer as if it were live online using Jekyll. You will need `git` and `ruby` installed on your machine to do this. Then clone the repository
### ... using docker
Make sure you have [docker](https://docs.docker.com/install/) (CE is fine) installed and running,
and [docker-compose](https://docs.docker.com/compose/install/) installed,
then:
git clone git@git.coop:cotech/website.git
cd website
docker-compose up -d
And visit [localhost:4000](http://localhost:4000) to view the site.
There are two docker volumes used here:
* `vendor` - caches the ruby gems even if you recreate the containers
* `site` - holds the built site files to share them with httpd (and not clutter your local filesystem)
A few useful things you might want to do:
# check the status of the containers
docker-compose ps
# stop all the containers (but don't remove them)
docker-compose stop
# stop and remove the containers (but leave the volumes)
docker-compose down
# remove everything
docker-compose down -v
# bring it back to life from any state you happen to be in
docker-compose up -d
# run some ruby/bundler commands
docker-compose run jekyll bundle --version
docker-compose run jekyll bundle update
docker-compose run jekyll bundle exec jekyll --help
### ... directly on your machine
Install the dependencies for the project
git clone git@git.coop:cotech/website.git
cd website
gem install bundler
bundle install
@ -22,9 +98,25 @@ Run a local web server so that you can view the site
And visit [localhost:4000](http://localhost:4000) to view the site.
## Deploy CI
**Note: not all the images will load as there is no `.htaccess` support locally**
When changes are committed to the `master` branch the `.gitlab-ci.yml` file triggers the building of the site and then the copying of the results to https://static.coops.tech/ and when changes are committed to the `dev` branch the site at https://dev.static.coops.tech/ is updated.
## Deployment
### Dev/Staging
When changes are committed to the `master` branch the `.gitlab-ci.yml` file triggers the building of the site and then the copying of the results to [dev.coops.tech](https://dev.coops.tech).
### Production
You need to manually deploy the changes from dev to production.
1. View the changes on [dev.coops.tech](https://dev.coops.tech) and ensure you're happy for them to be pushed to production.
2. Visit [GitLab environments](https://git.coop/cotech/website/environments). __NOTE.__ If you don't have access to the environments page then post a message in the [Website category of the CoTech forum](https://community.coops.tech/c/cotech/website) to ask someone to do it for you.
3. Click the "Play" icon on the right of the screen in the row for the "dev" environment and choose "deploy:production".
4. Your changes will be visible in production when the commit listed in the "production" environment row matches the commit listed in the "dev" environment row.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
