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.
* Modernize index test
* Hide comments body_html and user info if the comment is either deleted or hidden
* Shorten lines a bit
* Freeze repeated strings
* Document all /comments
* Document /comments/{id}
* Access only unpublished listings if they belong to the user when authenticated
* Make sure we never send unpublished listings in the index
* Update API docs
* oops
* Remove unused preloading as this loads a single item
* Fix articles index state param values
* Update Articles API docs
* Fix ClassifiedListing.cost_by_category with invalid category
* Add docs for GET|POST /listings and fix bugs
* Document PUT /api/listings/:id
* Add docs for /listings/category/{category}
* One variable down
* Improve listings update error handling
* Add check for article param being a Hash & spec
* Remove unnecessary blank line
* Move logic to private method and before_action call
* Change check_if to validate
* Use is_a? to type check
* Fix type check for specs
* Add specs
* Check the object, not the ID
* Use permitted params and delete cache only after create
* Inherit from ApiController, bail if the reaction user does not exist, fix naming
* Remove superflous test
* Add tests and improve pagination and caching
* Add two more specs
* Add .with_video scope
* Get rid of N+1
* Only select needed columns
* Improve efficiency of the video page as well
* Add missing set_cache_control_headers to API videos#index
* Fix article description issues
* Move tag info to decorator
* Fix description edge cases
* Fix description creation logic
* Fix test and adjust naming
* Modify line in processed_description
Surrogate keys are about setting expectations on cache purging.
Presently we use a combination of all parameters to set changing surrogate keys depending on the result of the `ArticleApiIndexService`. This approach has two limitations:
- if two set of params lead to the same exact set of articles, we still create two different caches
- deleted articles will remain for 24 hours in the cache because the cache key doesn't take the record keys into account
By simply using record keys we make sure that different params leading to the same result set will share the same cache and that deleted keys won't appear anymore in the cache.
* Add article's record key to Fastly Surrogate-Key to separate caches
After #4744 we successfully setup an auto purging system based on Fastly's surrogate key based cache and purging API.
Unfortunately this worked only in the `:show` action as comments are their own tree-based resource.
The `:index` though, is related to a single article, so without the article's record key in the `Surrogate-Key` header the first time we hit the API the result would become the value stored in Fastly's API, for all articles.
* Fix commentable mock for job spec
* Add comment.commentable.purge to the worker as well
* Add more thorough tests for commentable
* Use ancestry in the index and add test
* Add tests for show action
* Return complete comments trees for index, kill n+1 and use correct edge cache key
* Return complete comments tree for show, kill n+1 and use correct edge cache key
* Refactor tests and add surrogate keys tests
* Preload users for the whole subtree
* Clarify explanation of the edge cache keys construction
* Refactor partials
* Remove action caching
* Replace .map.flatten with .flat_map
* Fix surrogate key prefix according to Fastly docs
* Add comment.purge to Comments::BustCacheJob to use Fastly-Rails
* Fix surrogate key spec
* Remove mock from specs to test the actual Suggester
* Fix articles API top articles n+1
* Fix n+1 in articles API with state parameter
* Remove eager loading for organization dashboard
* Eager load notifiables in notifications only when needed
* Algolia does not like this
A common response in collection endpoint with REST APIs is to return an empty result set when the requested params end up in an empty result. The reason for this is that the resource itself exists (the collection always exists), it just is empty.
See https://github.com/thepracticaldev/dev.to/pull/5192
* Add infinite scroll to followers list (#258)
* Refactor fetchNext function for clarity (#258)
* Sepparate following tab into multiple tabs to support infinite scroll (#258)
* Add infinite scroll to following pages (#258)
* Add tests to infinite scroll api
* Refactor dashboard loading text
* Refactor infine scroll function
* Fix duplicated entries problem in infinite scrolling
* Switch randomized attributes to sequential to avoid InvalidRecord error
* Add acceptance tests for infinite scroll
* Remove unused following method
* parameterize limit per page for followers and followings
* Split follows endpoint into followers and followings
* Authenticate user with api key in followers and followings
* Split followers endpoint into users and organizations
* Add redundant html to sublist partial
* Speed up infinite scroll tests
* Refactor api json responses to use partials
* Authenticate api user before follows create
* Resolve conflicts on scrolling js
* Improve partials organization and fix organization username bug
* Improve readability of unauthorized test
* Use let! to create scrolling test data
* Fix not working podcasts link
* Refactor initScrolling to remove linting errors
* Fix codeclimate coding style issue
* Test tags forms and podcasts hyperlinks
* Fix eslint issue with double equals
* Improve before_action usage and readability
