- import with CSV file or Zapier
- or create anew
- LinkedIn badges
- Templates: default, custom
- Invite Contributors
- Contributor Questions
- Contributor Answers
- Inserting contributor content
- Customer Story anatomy: highlighted customer quote, customer results, narrative (HTML editor), more info
- publish levels: logo, preview, story, etc
- CTAs
- Sharing
- SEO
- Google Ads
- NOTE that ad blockers may detect Google markup on the ads preview page and block content. The page only mimics Google Ads content and does not load anything from Google. Disable your ad blocker to ensure all content loads
- charts and tables
- multiple types
- fully featured story overlays
- Staging dashboard
- Production dashboard
- Both staging and production use hobby dynos
- Environment variables / API keys: figaro, application.yml, apply to heroku
- common CLI commands
- env variables / api keys
- Heroku doesn't like A-records, may lead to instability in DNS resolution
- Heroku does not support wildcard SSL certificates (needed for subdomains)
- Certificates created with certbot
- assuming a macOS environment
- contact Ryan for DNSimple credentials (
certbot-creds.ini
file)
sudo pip3 install certbot
sudo pip3 install certbot-dns-dnsimple
- For any other DNS registrars, need to install the corresponding DNS plugin. Run
certbot plugins
to check. - Create the wildcard certificate:
sudo certbot certonly --dns-dnsimple --dns-dnsimple-credentials ./certbot-creds.ini -d 'customerstories.org' -d '*.customerstories.org'
- The certificate is placed in
/etc/letsencrypt/live/customerstories.org
. Subsequent renewals will overwrite this directory. - The above folder has super user permissions. You can make a copy (
sudo cp -r /etc/letsencrypt/live/customerstories.org .
) and then change permissions on the directory (sudo chown -R username customerstories.org
). Now you can cd into the directory. - Upload to heroku:
heroku certs:add fullchain.pem privkey.pem -a [csp-staging|floating-spire-2927]
- Check the certificate with
heroku certs -a [csp-staging|floating-spire-2927]
or under Settings in the app dashboard
Copy the production database to staging:
- Assumes
staging
is a remote repo on heroku corresponding to customerstories.org. Also works:-a csp-staging
- Assumes the primary database (as indicated by
DATABASE_URL
in the heroku configuration) on production is being copied to the primary database on staging. If copying to/from another db, make sure to use the correct name instaed ofDATABASE_URL
- To find database names:
heroku pg:info -a [csp-staging|floating-spire-2927]
- Turn off the web dynos on staging:
heroku maintenance:on -r staging
- Turn off worker dynos (if any):
heroku ps:scale worker=0 -r staging
heroku pg:copy floating-spire-2927::DATABASE_URL DATABASE_URL -r staging
heroku maintenance:off -r staging
heroku ps:scale worker=1 -r staging
(or however many workers, if any)
Copy the production database to local:
- First must drop the local db:
bundle exec rails db:drop
heroku pg:pull DATABASE_URL csp_development -r production
RAILS_ENV=development bundle exec rails db:environment:set
There were some issues with caching when upgrading to Rails 6. To minimize complexity caching (mostly in the form of rails low-level caching) has been disabled on staging and production.
- json/ld in
app/views/stories/index/seo_meta_tags.html
andapp/views/stories/show/seo_meta_tags.html
- Google Search Console
- System dependencies: Ruby 3.1.2, PosgresSQL@14, Heroku CLI, AWS CLI
- Clone repo
- Set up DB
- install dependencies
- Add heroku remotes
- Not enough!
- zapier: google sheets
- csv import
- AWS S3: buckets, CORS
- local tunneling with ngrok
- plugin JSONP
- file/image upload: aws s3, CORS
- copying production database
- account customization: stylesheets etc
- for all: username(s), password, account tier, api keys
- models (
VisitorSession
,Visitor
,VisitorAction
,PageView
,StoryShare
) - tasks
- updates presently disabled
- Console
- A separate user
csp-user
is used to generate credentials for interacting with the S3 bucket from the application. See the IAM Management Console. - In the production S3 bucket, note the bucket policy which is necessary for the Cloudfront distribution to read from the bucket, and the CORS list which is necessary for user uploads and font requests.
- Public access to the production S3 bucket (used by both
.org
and.net
) is blocked, however since the development environment does not request assets through Cloudfront, public access to the development S3 bucket must be turned on. The bucket policy ensures only requests from development domains are allowed. - For the Cloudfront distribution, the only additional steps beyond creating the distribution (and accepting default values) were
- Creating the origin access control via these steps
- Editing the default behavior to include Origin headers in the cache key (required for subdomains)
- read receipts
- limits
- Customer Stories app
- test spreadsheets
- models (AdwordsCampaign, AdwordsAdGroup, AdwordsAd, AdwordsImage)
- configuration (search/keywords, topic, retarget)
- send invitation reminders
- download clicky data (disabled)
- clean adwords images (disabled)