Custom Fields on Pages - Backlog?

I’m wondering how many partners would find useful the ability to add custom fields on pages in the Treepl admin. For example (and against my every recommendation) I have a client that wants to use images for page titles instead of dynamically populating the title via Liquid in the page template. They want to use a font for the page title that isn’t a web font and they can’t find anything close. Again, I know why this is wrong for so many reasons, but it brings up a common issue that I think could be circumvented by adding custom fields on the pages - just like Custom Modules. I think this was a big missing feature with Adobe BC as well. While this is a bad example of how it could/should be used, does anyone agree that the ability to add custom fields to the pages would be very useful? It would be great, in this instance, to just have an image field that the client could use to select the image for each page rather than having to hard code it in the Content Template or WYSIWYG editor at the page level. Just thought I’d check here to see if this should/could be added to the backlog? I’m open to any suggestions if there is a good workaround. I know we could create all of the pages as Custom Modules, but I’d like to be able to just have regular pages on the site and not have everything set as a Custom Module, but maybe that’s the only way.

Thank you,

  • Ryan
1 Like

Custom fields for pages would be very useful indeed. That would give them the same power as custom modules. Use cases e.g. are sites which have different banner pictures and individuel collections of content in the sidebar of pages (e.g. this site:
We solved that by setting up a custom module. Each item holds additional content for the connected page. This would be obsolete if we could set up custom proberties for pages.

1 Like

Totally makes sense to open this up for Pages just like all other modules.
Hopefully there’s no technical reason why this can’t be done.

1 Like

@StudioRTP - I think it is a great idea, I can see several cases where it would be very useful :slight_smile:

@vlad.z @Eugene - Do you want this in the public backlog or is this “easy”, so it would be easy to include in one of the upcoming sprints?

Ryan: I know that you are not looking for a solution to your clients font/image problem, but just wanted to mention that you can make a webfont of any font. You would need to check the license etc. for the specific font, but it can be done :slight_smile:

More info:

@Peter-Schmidt - Thank you for the information here! I meant to add to this post that I found a way to convert the font to a webfont. I’m afraid to ask how long that has been ‘a thing’? Lol! I had no idea, but was doing some Googling and came across a converter. It seems to get the job done (here’s an example page: you can see the script font used for the page title). There is an unfortunate delay when the page loads to load up the font as you’ll see the ‘default’ font pop up and then it quickly converts to the font that is set. I tried a few different ways of moving the font style around in the stylesheet to see if it would help, but I’m not having any luck. The good news is that the client is happy, so I’ll take it as a win. I’ll take any victory in 2020 as a win! Lol

Thank you all for contributing here - I think this would be a really nice feature at the page level if it’s not a huge change to the platform. I know @vlad.z and @Eugene (and all of the others at Treepl) have their hands full right now!

Thank you again,

  • Ryan
1 Like

It would be better if this request will be converted to a public backlog request so we could prioritize it among all requested features and improvements.

Great - Added here:

@StudioRTP, @TimL , @Adam.Wilson - Please let me know if you have anything you want to add :slight_smile:

1 Like

Thank you @Peter-Schmidt! Looks great, I appreciate the add!

1 Like

This would be a great feature. My only concern is that we need to have the option of being able to include or exclude these fields in the indexed content for site search.

@hopestew - Can you clarify that a bit?
I see them work just as fields in custom modules and we can work with that just like any other info from fields in custom modules?

Just not entirely sure what you mean, maybe you can give a couple of example on which fields you would like to index or exclude? :slight_smile:

Site Search indexes content in the Name, Description, and Search Keywords field in Pages and Custom Modules but not any custom fields. You may not want some custom fields to be indexed, eg the field may be used to create a css class. Other custom fields you do want indexed so that its content can be found when a visitor to the website uses the Site Search function.

Saw this come up in another post. Here is a thought.
Use “Site Information” As the Data Modules for Content Templates/Pages.

Here’s how it would work.
Site Information Module

  • Use Site information as it is today however instead of adding a value you leave it blank. Or maybe adding a value a default value. (Some Data Types need to be added like List, dropdown, etc.)

  • In the Site Information Group settings there would be an option to assign the group to a Content Template.

  • At the item Property level you could also deselect the Content Template that is displays on. This way if you have multiple Content Templates but maybe you don’t want a property on one you can deselect it so it doesn’t display on that template.

Content Template

  • While we don’t need the data fields to display on the template. We could have them display to set any default values for that template and to show the Liquid output code of the Site Information property to add to our template by simply copy/paste.


  • The magic happens when you assign the template to the page. Once assigned the Site Information properties assigned to that template will populate the custom data fields on the page editor just like in a Custom Module.

  • It could even populate when entering Custom Module items and any other system module that the template is assigned to.

That’s the Idea.

Now that the Site information module has turned into a data setup module. I would reliable it as Site Data. I know the output code is “si” for site information and changing to Site Data would not make that work but I think we will be okay.

The reason for the change is we then create a new Site Information section and assign the basic site questions created in the Site Data Module like “Name”, “Address”, etc.
The New site module would be simple for our clients to use. They just fill in the blanks like any other form.

1 Like

@StudioRTP This is a great idea. I would find this useful. One very common example would be for hero images on pages. This ends up being a thing on most of my sites, for which I create a module. It’s just a bit convoluted to have a module for this. It would be much easier if it could just be a custom field.

1 Like