Hey team, making a request to add a simple ‘image’ media box on Content / Pages.
More and more clients are wanting some ability to add header images to pages.
It’s not problem for me to create a custom module to achieve this, but this is just one more step. Doesn’t need to be anything more than an image source field in pages.
Thanks in advance for your consideration.
@Peter-Schmidt please take note.
Aaron
This just might be my opinion, so I’m open to counter arguments, but there already is an image field for Pages (and all other items), that being the OG Image field.
The problem as I see it is that this field, and most other “SEO” fields are separated away and potentially miss-labeled in the name of SEO.
A Page/Item should have as its main properties, irrespective of SEO:
which is what we do have, but they are split into different sections and labeled as SEO specific things.
I get that these properties are mostly used for SEO purposes and for marketing of the CMS it’s good to show a high focus on SEO capabilities, but in essence these properties are just good practice meta data needed to best describe a digital item - for whatever purpose - and can be used for whatever purpose. Whether an image for social media sharing or an image for the top banner of a page. If that’s an appropriate image to represent that page then why wouldn’t it be used in all these different places?
If it’s instead, purely a design decision as to why an image is used, then I think that’s a different thing and something to be handled by CSS or other design related process, not the Content Management System.
Adam, my one simple argument on why we shouldn’t use the OG image to support what I am asking is there is usually a base/recommended size for OG images and some page header images are like 2000x400 which wouldn’t look good on Social Media.
Anyways I hold my request for a simple image tag on pages.
Cheers,
Aaron
@A3CS My vote on adding an image field to pages is maayyyyybeee. Thanks for bringing it up though. I think it does need to be addressed.
I would personally like to see the built in banner module become better. Add custom fields, and ability to be easily be attached to a page ( pages/folders as a data source field or media picker field). Currently I never use it because I always need additional fields i.e. an extra byline, an overlay, an animated piece. … something. That would be my vote.
It’s my understanding that this feature is in the roadmap (for eCommerce plans only though). I can already add new properties to system modules like events. But if I read this right it should also be possible for pages:
Fixed, thank you pointing this out.
Ah, okay @alex. Although that would be an awesome feature. E.g. we have two websites where we needed to associate a custom modules with pages so that we can use custom properties to render certain individual content on pages other than the main content like content in the sidebar, banner picture etc. Downside is that this gets confusing for the client as he has to edit stuff for a page at two different places in the admin. Pages with custom properties would have solved that and I was kinda looking forward to that.
That brings me to that question @A3CS: Why not dropping pages and only using custom modules to render URLs on the frontend. I think that came up before in Treehouse or so. Though I’m not quite sure about the implications with overall performance.
Hmm… @TimL I kind of like this idea to be honest… but, pages within Content/ seem a bit more logical. To be honest, all I really need is just one field addition to the Content / Pages module : )
I agree, though my problem is, that some content is kept in modules and other on pages. On some pages (the static ones), clients can edit, from other pages (with module code on it) they should stay away. The admin configurator helps, but I’m not settled in one specific approach yet. I think the way partners use the configurator (or maybe not use it) to improve the experience for their clients could be a topic for a future treehouse btw.
