# Custom fields for posts **URL:** \ **Category:** Ideas\ **Tags:** šŸ‘šŸ¼-planned\ **Created:** [April 30, 2018, 12:19pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124 "2018-04-30T12:19:33Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Juan](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/juan/32/25_2.png) [@Juan](https://forum.ghost.org/u/Juan)\ **Post date:** [April 30, 2018, 12:19pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/1 "2018-04-30T12:19:33Z")
> > > Within the top 15 requested features on the \[Ghost Feature Wishlist\](http://ideaā€¦s.ghost.org/forums/285309-wishlist/filters/top), this feature has been waiting for some love since 2015. > > I volunteer to help out with this feature's development. > > \# Brief Overview > > Ghost is one of the most customizable publishing platform for the general public out there, and sports most of the major benefits of all its competitors. However, every now and then comes a blogger with a vision for a design, and that vision requires complete customization of the fields on the core model objects. Think, \_featured image subtitle\_, featured link as replacement for image\_ (video content, tweet, facebook embed, soundcloud), and even more. With the advent of apps, this feature will most likely gain further support as the custom fields will be readily accessible just like any other fields on the core model objects. It is most likely that apps will seek to alter the content and/or the structure of the database, and to allow such behaviour will result in a maintenance mess. Hence it is important to allow such customization now with proper separation of concerns so that later features can use its power at the fullest. > > \# Feature Details > > \## Custom Fields Themselves > > \- Custom Fields should be implemented as fields that are available across all objects of a model, with each instance/row having its own value for the said property. > \- Each core model affected should have its own set of custom fields defined by the user, without commonality with each other. > \- Custom Fields should be easily accessible from the block helpers used in the hbs templates > \- Custom Fields should be easily usable by non-technical personnel so that the widest audience possible be able to use them. > > \## Core Models Affected > > \### Iteration 1 > > \- Post > > \### Iteration 2 > > \- User (gender, sexual orientation, age, behance/deviantart/instagram/some social media, etc can be seen as potential use cases) > > \### Other Models > > I do not foresee the need for any extra custom fields on other models at the moment. If anybody has a very good use case, I'll update this section accordingly. > > \## Proposed UI Workflow > > I am no designer, but here is what I came up with. > > 1. Custom Fields are to be accessible from the General Settings (general.hbs) view > > !\[custom fields settings closed\](https://user-images.githubusercontent.com/31741972/30515638-0c74c59a-9afa-11e7-9f8b-6d5f0cc44b56.png) > > 2. Custom Fields are to be added/removed dynamically and easily. Type of the field (Number, Text, Boolean) can be specified for later retrieval and parsing by the model > > !\[custom fields settings expanded\](https://user-images.githubusercontent.com/31741972/30515652-4629ca6a-9afa-11e7-921d-0487110710e1.png) > > 3. Each post has access to the Custom Field menu through its Settings menu > > !\[new story custom fields nav\](https://user-images.githubusercontent.com/31741972/30515666-6a9e2274-9afa-11e7-89e8-03d8686d7f35.png) > > 4. Each post has its own value for the Custom Fields that can be specified in their Custom Field menu > > !\[new story custom fields menu\](https://user-images.githubusercontent.com/31741972/30515673-82f626c8-9afa-11e7-80a4-217b7ac778f7.png) > > \## Scope of the changes > > After my preliminary analysis of the codebase yesterday, here is what I gathered: > > \### Ghost > > \- \`core/server/models/custom-field\` is to be created as a table representing the custom-fields for each other linked table (see below) > \- \`core/server/models/custom-field-value\` is to be created as a table representing the values associated to each core model object which has the said custom fields (see below) > \- \`core/server/models/post\` and \`core/server/models/user\` are to be modified to allow read, mutation, deletion of custom fields. > \- \`core/server/helpers/post\_class\` and \`core/server/helpers/author\` are to be potentially modified to include the custom field helper > \- \`core/server/helpers/custom\` helper has to be created to allow users to template using the \`custom\` block helper and output helper > \- \`core/server/api/\*\` API endpoints have to be modified accordingly to support modification of the custom field and custom field value models. It is undetermined at the moment whether this should be done through the \`posts\` and \`users\` endpoints or through the \`settings\` endpoint. > > \#### Quick DB Class Diagram > > !\[Class Diagram\](https://user-images.githubusercontent.com/31741972/30516085-d499cb76-9b02-11e7-902d-371d85b5f006.png) > > \### Ghost-Admin > > \#### General Settings Page > > \- \`app/controllers/general\` Unclear whether modifications should be done on this file. It does play a significant role however in contacting the server to update the settings under the General page (general.hbs) > \- \`app/templates/settings/general.hbs\` Modify the layout to include the new custom field settings. Will require the creation of a new \`component\` for the layout shown in the second mockup. > \- \`app/models/setting\` Include a new field to validate on the model. Will require the creation of a new \`ember-data Transform\` in order to support and validate the custom field. > > \#### Editor Page > \- \`app/mixins/editor-base-controller\` May need modification to allow mutation and save of the custom fields > \- \`app/components/gh-posts-settings-menu\` Modify to include the design seen in screens 3 and 4. May require the creation of an extra components for dynamically generating the list of custom fields on screen 4. > \- \`app/models/post\` Include a new field to validate on the model. Will require the creation of a new \`ember-data Transform\` in order to support and validate the custom field values. > > \## Expected Time Investment > > | Activity | Estimate | Conservative Estimate | > |---|---|---| > | Supplementary Analysis | 3h | 6h | > | Implementation (Ghost) | 10h | 20h | > | Testing (Ghost) | 10h | 20h | > | Implementation (Ghost Admin) | 10h | 20h | > | Testing (Ghost Admin) | 4h | 8h | > | TOTAL | 37h | 74h | > > This is undoubtedly a large epic, and would benefit from being undertaken by multiple individuals / be broken down in smaller user stories. > > \# Drawbacks > > \- Potential bottleneck on the CustomField / CustomFIeldValue table if accesses are done often. With proper caching practice should not be problematic however. > \- Requires changes to large portion of the Ghost/Ghost-Admin software > \- Increases maintenance debt by increasing the codebase > \- Feature may not be necessary for a large portion of the target market but nevertheless eases a significant portion of the user base and facilitates future symbiosis of apps > > \# Alternatives > > \- Custom install on self-hosted version > \- Front-end with external database > \- Apps with ability to modify existing database structure (and potentially requiring reboot for each new modification) > > It is an understatement to say that this list of alternatives is unsatisfying. Friends, the future without custom fields is dire šŸ˜± > > Let us not allow ourselves to follow such a dark path. For example, to have caption for the featured image (using `
` in the theme with the custom field), and many other possible things. Itā€™s currently a feature tagged _ā€œlaterā€_, with the author of the above issue offering to work on it. ---
**Author:** ![dsecareanu](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/dsecareanu/32/413_2.png) [@dsecareanu](https://forum.ghost.org/u/dsecareanu)\ **Post date:** [April 30, 2018, 12:32pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/2 "2018-04-30T12:32:53Z")
I would go even further than custom fields and say that Ghost could use custom content types (ideally with an admin interface to add them, on a concept similar to [pods.io](http://pods.io) for WP)ā€¦ I think this would be the feature that will allow Ghost to move beyond just a publishing platform for blogs and become truly a platform for journalism as it would allow small and medium sized publishers to build their websites by offering them a flexible content structure. Just my 2 cents šŸ˜‰ ---
**Author:** ![HauntedThemes](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/hauntedthemes/32/15301_2.png) [@HauntedThemes](https://forum.ghost.org/u/HauntedThemes)\ **Post date:** [April 30, 2018, 12:50pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/3 "2018-04-30T12:50:11Z")
The Custom Post Type that is now available on Wordpress is pretty much a work in progress for Ghost too. Check this out: > > > Refs: https://github.com/TryGhost/Ghost/issues/9528 (YAML Settings), https://gitā€¦hub.com/TryGhost/Ghost/issues/9192 (Routing re-write), https://github.com/TryGhost/Ghost/pull/9550 (Url Service). > > \## The what and why of dynamic routing > > Ghost's Routing has always been almost entirely static and hard-coded. The only config we've offered is the option to add dates to permalinks, but that setting is probably my least favourite part of Ghost šŸ˜‚ > > People close to the project will have heard a lot about a mysterious feature called "channels", which was an attempt to expose more configuration around lists of posts. This has been working behind the scenes, but we haven't been clear on how to expose the functionality: Apps? Config? UI? > > Early this year we sat down and rethought routing from the ground up with a view to answering the following questions: How can we make it possible to solve all the common routing use cases? How do we expose functionality to our users? How does this fit in with Apps? And where the fuck do Channels fit into all of this? > > Top 3 common use cases we want to solve: > > 1. custom home pages > 2. rendering a taxonomy at a non-standard URL, e.g. /tag/recipes/ -\> /category/recipes/ > 3. customising post collections e.g. removing posts with a certain tag, or using a different URL > > There are 3 main problems we have with trying to reach these use cases: > > \- How to make routes enumerable and configurable > \- Ability to generate sitemaps and other features that need to know about URLs rather than routes > \- Resource \<-\> URL 2 way binding - get resource from URL, get URL for resource > > We think we have the answers, however the theory is never quite the same as the practice. This issue represents our current thinking at the time of writing and is very subject to change! > > \## What's coming? > > In https://github.com/TryGhost/Ghost/issues/9528 we added the ability to customise Ghost through YAML files that live in \`content/settings\`. The first file that will live here will be \`routes.yaml\`, and this will be the gateway to all things dynamic routing. This solve the configuration problem. > > The solution to everything else is the introduction of a URL service and a huge rewrite of all the code that generates content for Ghost blogs šŸ˜… > > \*\*Beta Goals\*\* > > In the first beta version, by editing \`content/settings/routes.yml\` it will be possible to: > > \- Define a custom route that renders a specific template > \- Define a custom home page > \- Change the location of the standard collection of posts, e.g. so they all live at \`/blog/\*\`. > \- Change the URL for taxonomies e.g \`/tag/:slug/\` -\> \`/category/:slug/\` > \- Customise the main post collection (v1 has severe known limitations) > \- Define new collections (v1 has severe known limitations) > > Once the first beta goes out we will be looking for people to test their routing use-cases. At that point, we'll publish some documentation on how the default routes.yml file is structured and how to define custom routes and collections within the limitations. > > \*\*Tracked tasks\*\* > > \- \[x\] YAML Settings #9528 > \- \[x\] Url Service rewrite #9550 > \- \[x\] Dynamic sitemap 100% working (https://github.com/TryGhost/Ghost/pull/9580) > \- \[x\] Rework url utility https://github.com/TryGhost/Ghost/pull/9593 > \- \[x\] Routing re-write https://github.com/TryGhost/Ghost/pull/9596 > \- \[x\] render 503 if url service is processing (https://github.com/TryGhost/Ghost/pull/9588) > \- \[x\] Resources have full 2-way binding https://github.com/TryGhost/Ghost/pull/9596 > > \*\*Overall Goals\*\* > > This issue will be closed when we achieve the following: > > \- \[x\] Ship first beta version of dynamic routing > \- \[x\] First version of channels (https://github.com/TryGhost/Ghost/pull/9686) > - \[x\] Resource path aliases with automatic redirects (Need a separate issue explaining this feature!) > \- \[x\] Data key, order, limit, redirect > \- \[x\] Disable rss (https://github.com/TryGhost/Ghost/pull/9693) > \- \[x\] \*\*Extracted\*\*: disable sitemaps, disable pagination (https://github.com/TryGhost/Ghost/issues/10313) > \- \[x\] \*\*Extracted\*\*: All hard-coded public routes (e.g. page) are configurable inc homepage (https://github.com/TryGhost/Ghost/issues/10312) > \- \[x\] Add UI to upload+reload routes.yaml file (https://github.com/TryGhost/Ghost/issues/9744) > > \_Note: There are some extensions to the dynamic routing behaviour that are known but not covered by this issue, which include custom controllers and custom taxonomies\_ > > šŸ’” \*\*Please direct all questions & discussion to the \[forum\](https://forum.ghost.org).\*\* This issue will be used for collecting bugs & use cases once the beta goes out. ---
**Author:** ![dsecareanu](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/dsecareanu/32/413_2.png) [@dsecareanu](https://forum.ghost.org/u/dsecareanu)\ **Post date:** [April 30, 2018, 2:51pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/4 "2018-04-30T14:51:17Z")
Iā€™ve seen that, but I guess I only browsed it as I was left with the impression itā€™s only about homepage and categories. ---
**Author:** ![Sarah](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/sarah/32/21755_2.png) [@Sarah](https://forum.ghost.org/u/Sarah)\ **Post date:** [March 29, 2018, 7:44pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/5 "2018-03-29T19:44:40Z")
An input or similar to allow the automatically generated canonical URL to be overridden on a per-post basis. ---
**Author:** ![JoelDeTeves](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/joeldeteves/32/495_2.png) [@JoelDeTeves](https://forum.ghost.org/u/JoelDeTeves)\ **Post date:** [April 15, 2018, 8:39am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/6 "2018-04-15T08:39:15Z")
As far as I know this feature exists. While editing your post click the gear icon in the top right -\> change the text under Post URL ---
**Author:** ![Stromfeldt](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/stromfeldt/32/13572_2.png) [@Stromfeldt](https://forum.ghost.org/u/Stromfeldt)\ **Post date:** [April 15, 2018, 11:36am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/7 "2018-04-15T11:36:50Z")
Correct, but to be more specific the desire is to be able to change the canonical URL independently from the post URL. The posts from my pre-imported-to-Ghost blog were under the slug /blog/year/post-title, but after the import I now have them at /post-title. If I could change the canonical URLs independently then I could recoup the share stats associated with those old URLs. ---
**Author:** ![FoohonPie](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/foohonpie/32/579_2.png) [@FoohonPie](https://forum.ghost.org/u/FoohonPie)\ **Post date:** [May 9, 2018, 1:55pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/8 "2018-05-09T13:55:46Z")
I came looking for exactly this. I run a few different blogs with some slight overlap in content and would like to edit canonical urls for cross posting purposes. It would be great as a built-in input underneath ā€œPost URLā€. ---
**Author:** ![Illya](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/illya/32/1665_2.png) [@Illya](https://forum.ghost.org/u/Illya)\ **Post date:** [September 16, 2018, 9:45pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/9 "2018-09-16T21:45:23Z")
A lot of really good blogs do link posts, a great example being Daring Fireball. Currently, Wordpress has an easy plugin for this, which can be found [here](https://wordpress.org/plugins/add-link-post/). Unfortunately, Ghost has no easy way to do this (without hacking together something in the core services). Even looking online, there seems to be [one blog post talking about how you might achieve this](https://roaringapps.com/blog/link-posts-in-ghost/), but itā€™s from years ago. I was wondering if this was ever going to be a native feature to Ghost? ---
**Author:** ![FoohonPie](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/foohonpie/32/579_2.png) [@FoohonPie](https://forum.ghost.org/u/FoohonPie)\ **Post date:** [January 23, 2019, 12:18pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/11 "2019-01-23T12:18:20Z")
I hope so. Itā€™s a small feature, but definitely not a trivial one if youā€™re involved with more than a single blog. ---
**Author:** ![Kevin](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/kevin/32/32_2.png) [@Kevin](https://forum.ghost.org/u/Kevin)\ **Post date:** [March 12, 2019, 1:35pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/13 "2019-03-12T13:35:23Z")
šŸ’” As of Ghost 2.17.0 itā€™s now possible to override the default generated canonical URL. You can find the setting under the meta data section of the post/page settings menu. ---
**Author:** ![Stromfeldt](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/stromfeldt/32/13572_2.png) [@Stromfeldt](https://forum.ghost.org/u/Stromfeldt)\ **Post date:** [March 13, 2019, 1:49am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/14 "2019-03-13T01:49:44Z")
Awesome, thanks for the canonical feature, been looking forward to it for a while! Unfortunately I seem to have come across two bugs though. **Bug #1, https vs. http:** Prior to using Ghost my old blog didnā€™t have a certificate and used plain old `http`. My current Ghost blog of course uses `https`. When I went to add one of my old post URLs it seemed fine, but as soon as I selected outside of the canonical box the `s` got automatically added in to the end of the `http`, which then became `https`. I nonetheless checked the live post to see if the old canonical stats came through, but they unfortunately didnā€™t. I then checked out and tested [Facebookā€™s debugger page](https://developers.facebook.com/tools/debug/) to see if there was any difference between the `http` and `https` URLs, and there in fact was. Any chance that the automatic `s` addition can be undone? **Bug #2, saving is kinda wonky** : I decided to leave said post by clicking on `< Posts` after those tests, but couldnā€™t do so properly. That is, I got the ā€œAre you sure you want to leave this page?ā€ box. I re-saved, but when trying to exit I still got the box (as you can see at the bottom left of the image below the post is definitely saved, but I canā€™t leave the page without the warning box appearing). ![saved](https://us1.discourse-cdn.com/flex015/uploads/ghost2/original/2X/5/58cd0834ea4b9994ba11f6e1fc48014d5557fc2b.png) I tried opening up a different post, made regular adjustments, saved it, and could exit the post via `< Posts` regularly. However, I then tested the canonical feature again with a different post: I adjusted the canonical URL, saved the post, tried clicking on `< Posts`, but couldnā€™t exit the post without the warning. I donā€™t think itā€™d make a difference, but Iā€™m using Firefox 65.0.2. ---
**Author:** ![naz](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/naz/32/30666_2.png) [@naz](https://forum.ghost.org/u/naz)\ **Post date:** [March 13, 2019, 10:29am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/15 "2019-03-13T10:29:01Z")
> [@Stromfeldt](#): > > Bug #1, https vs. http: Hi @Stromfeldt! Thanks for testing new feature out! These are really awesome findings šŸ™‚ Could you please share more details about where is your old blog hosted (meaning same domain but only different protocol, or is it run on a subdirectory/subdomain)? I suspect the issue with http ā†’ https conversion comes from the fact that your old blog was served under the same domain and now thereā€™s no way to distinguish for new Ghost blog (other than protocol) which makes it harder to distinguish which URLā€™s should be treated as local and which ones are external (like your old blog instance). Just for more context, Ghost transforms all local absolute URLā€™s to relative and stores them in the relative form in the db. The reason for this is when the blog is migrated to a different domain local URLā€™s keep working. ---
**Author:** ![Stromfeldt](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/stromfeldt/32/13572_2.png) [@Stromfeldt](https://forum.ghost.org/u/Stromfeldt)\ **Post date:** [March 13, 2019, 10:44am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/16 "2019-03-13T10:44:46Z")
> [@naz](#): > > Could you please share more details about where is your old blog hosted (meaning same domain but only different protocol, or is it run on a subdirectory/subdomain)? Sure thing! My blog and its posts used to be at [http://domain.com/blog/year/post-title](http://domain.com/blog/year/post-title), and theyā€™re now at [https://domain.com/post-title](https://domain.com/post-title), with the ā€œ[domain.com](http://domain.com)ā€ portion being the exact same. ---
**Author:** ![Kevin](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/kevin/32/32_2.png) [@Kevin](https://forum.ghost.org/u/Kevin)\ **Post date:** [March 13, 2019, 10:53am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/17 "2019-03-13T10:53:57Z")
@Stromfeldt if youā€™ve moved your blog posts and have 301 redirects set up then you should not be trying to set the canonical to point at the ā€œoldā€ URL, thatā€™s a misuse of the canonical tag and will hurt your SEO, the canonical should be left as the default so that your posts are self-referencing. ---
**Author:** ![Stromfeldt](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/stromfeldt/32/13572_2.png) [@Stromfeldt](https://forum.ghost.org/u/Stromfeldt)\ **Post date:** [March 15, 2019, 4:02am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/18 "2019-03-15T04:02:32Z")
Hello @naz, thanks for the explanation! However, I think I may have left out the intention behind my intended usage of the canonical function in that long screed of mine. As I stated in another comment I left in this topic last year, > [@Stromfeldt](#): > > If I could change the canonical URLs independently then I could recoup the share stats associated with those old URLs. [This link](https://cognitiveseo.com/blog/13431/recover-facebook-shares-https/) mentions a bit about transferring oneā€™s old share stats from a `http` URL to a `https` URL, but it requires one to be able to temporarily change the canonical URL to `http` in order to get it to work ā€“ which is exactly what my ā€œBug #1ā€ was stating that I canā€™t currently do. Is there any way that the `http` syntax (rather than just `https`) could be allowed in the canonical input box? p.s. Iā€™ve now updated to version 2.18.1, and for whatever reason the ā€œBug #2ā€ I mentioned is no longer occurring. šŸ˜„ ---
**Author:** ![Kevin](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/kevin/32/32_2.png) [@Kevin](https://forum.ghost.org/u/Kevin)\ **Post date:** [March 15, 2019, 9:32am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/19 "2019-03-15T09:32:42Z")
> [@Stromfeldt](#): > > for whatever reason the ā€œBug #2ā€ I mentioned is no longer occurring. šŸ˜„ Itā€™s not related to canonical tag, Iā€™m still trying to track it down but as youā€™ve experienced itā€™s not consistent _at all_ so itā€™s a difficult one to pin on anything in particular. ---
**Author:** ![chrisarmstrong](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/chrisarmstrong/32/2889_2.png) [@chrisarmstrong](https://forum.ghost.org/u/chrisarmstrong)\ **Post date:** [March 18, 2019, 11:10pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/20 "2019-03-18T23:10:33Z")
Any update on whether you can add custom fields to posts yet, or if this is in development? ---
**Author:** ![naz](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/naz/32/30666_2.png) [@naz](https://forum.ghost.org/u/naz)\ **Post date:** [March 19, 2019, 4:17am UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/21 "2019-03-19T04:17:10Z")
Canonical url is automatically converted into the same protocol your Ghost instance is using if it detects same domain. If your preferred option is `https` why not point from old `http` posts to new `https` ones? If you still really need to point backwards to http, the only way would be modifying `canonical_url` field for those posts on db layer (note saving that post from admin UI will override the protocol back to https) ---
**Author:** ![astericky](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/astericky/32/2178_2.png) [@astericky](https://forum.ghost.org/u/astericky)\ **Post date:** [April 11, 2019, 4:48pm UTC](https://forum.ghost.org/t/custom-fields-for-posts/1124/22 "2019-04-11T16:48:19Z")
I donā€™t understand why this hasnā€™t been added yet. Custom fields is a feature that was added to WP ages ago. [Next page](https://forum.ghost.org/t/custom-fields-for-posts/1124.md?page=2)