closes#7688
- Use `/favicon.ico` and `/favicon.png` in blog app. Depending on type of storage (custom upload = local file storage), serves either from storage adapter with `read()` method or reads the bytes via `fs`.
- Redirects requests for `favicon.ico` to `favicon.png` if custom `png` icon is uploaded and vice versa.
- Redirect requests for `favicon.png` to `favicon.ico` if default icon is used (in `core/shared`).
- Changes the `{{asset}}` helper for favicon to not serve from theme assets anymore. It will either be served the custom blog-icon or the default one.
- The `{{@blog.icon}}` helper renders the url of the **uploaded** blog icon. It won't render the default icon.
refs #7688
Adds logic in theme settings api to either serve an uploaded favicon and give it the type `upload` or use the default settings `default`, which will serve the favicon from our shared directory.
TODOs for #7688:
- [X] Figure out, which favicon should be used (uploaded or default) -> this PR
- [ ] Serve and redirect the favicon for any browser requests, incl. redirects
- [ ] Upload favicon via `general/settings` and implement basic admin validations -> [WIP] TryGhost/Ghost-Admin#397
- [ ] Built server side validations
no issue
- add tests for makePathsAbsolute
- add support for windows paths
When Ghost-CLI inits the database of the current GhostVersion (in /current), then it uses knex-migrator to do that.
Knex migrator is reading the .knex-migrator file of the current Ghost version. This returns a relative path to the database location.
The problem: knex-migrator will init the database in the root folder of Ghost-CLI /content/data instead of /current/content . And when you start Ghost (ghost start), it always complains that
that database is not initialised, because it expects the database in /current/content...
* 🎨 move config_spec to config/index_spec
- add one more test case
