Currently, we don't allow users to remove the `main_image` of an article once it has been set. It can be changed, but never removed.
This change allows the `main_image` to be removed by checking for the `cover_image` key in the frontmatter that is sent along in the article's markdown. This means that a user should be able to remove the image associated with an article by removing the value of `cover_image:` from their frontmatter.
* Create podcast as a user [WIP]
* Sample css for podcast form
* Nicer podcasts suggesting form
* Validate podcast feed_url
* Validate podcast main_color_hex
* Fix podcasts specs
* Fix form appearance
* Placeholder for podcast main_color_hex
* Provide a link to suggest a podcast
* Add a checkbox and a role for when a podcast is added by an owner
* Prettier checkbox in the podcasts form
* Added creator to podcasts
* Set the podcast creator
* Fix the /pod spec
* Added creator information to the internal podcast page
* Added cta class to the podcasts submit button
* Global notice when a podcast was suggested
Co-authored-by: Ben Halpern <bendhalpern@gmail.com>
* Add specs for ArticleImageUploader
* Add specs for BadgeUploader
* Add specs for CoverImageUploader
* Add specs for ProfileImageUploader
* Refactor uploaders to inherit from BaseUploader
* Strip EXIF and GPS data from uploaded images
* Add ImageMagick to the docs
* Protect strip_exif
* Add system test to create article from the editor
* Move article creation from API to app controller
* Fix system test to edit posts
* Move article update from API to app controller
* Rewrite create article API using API key
* Add main_image and canonical_url to allowed creation params
* Rewrite update article API using API key
* Fix tests and have Comments API inherit from API
* Switch from deprecated honeycomb-rails to honeycomb-beeline
* Improve error handling, tests and add refactoring
* Fix multiple fetching test and add one more
The test wasn't actually testing the correct behavior, because the class
by default force fetches. It worked because it wasn't reloading the user
from the database.
* Test that Honeycomb's client is doing its thing
* Use some defensive programming to avoid any possible problem during shutdown
* Fix typo
* Use the new API to add fields to the current measured event
* Use default instrumentation and add user info to event
* Replace user.email with user.username, less personal data around
* Use mocking instead of calling Honeycomb.init
* Freeze time before traveling
* Remove a flaky test dependent on rand
