I would love to see image cropping where you set the dimensions and the client can manually adjust the crop location on the image.
Another feature I'd like to see is datachecklist; similar to how dataselect works, but is a list of checkboxes so the client can select multiple options.
Both of those would be incredible. Also, +1 for event app start and stop times, I've needed that on more than one occasion!
Assets is still the place where I have to turn away from Perch on certain projects. I'd like to see ways of using tags to filter and display file assets on the front-end, hierarchies of assets, and the ability to add custom fields to assets. And as mentioned by others, the ability to re-crop images based on new template values without having to re-assign the images one-by-one.
There's something unfortunately clunky about adding a bunch of images to a slideshow region, manually adding a repeater item or multi-item then clicking Select an image… then choosing the image then Use Selected Asset (or whatever) over and over and over. I think I understand why it works that way from a technical standpoint but the user experience is sub-par compared to what the editors may experience with other online applications. Not sure if that can be remedied given how Perch is set up, but I see it being done in other CMSes and it would improve editing flow significantly when groups of images are used.
Top request: multilingual content management in a more straightforward way than having to create a directory for each language (en/fr/de/it/es/ru/...) and duplicating pages within them. Or dealing with very long forms with all the inputs for all languages on top of each other, or some other hacky solution.
Easier deployment as migrating from a local server to a staging/production server (in short moving to another server) is clunky. It would be much easier if the links to content and pages were relative to a root defined as a setting in the CMS. That way moving Perch websites around would be less "fragile".
We absolutely want to do better multi-language support but it is a huge huge job to do really well (and we don't want to do it in a hacky way). It would impact on everything - the complexity of editing, the complexity of future development, the complexity of apps (ours and third parties using the API). It's something we talk about a lot here, and we do think important but don't underestimate how complex a job it is - and the fact it would essentially stop everything else while we did it!
I'm not sure what is fragile about moving a Perch site around unless you do something suboptimal like develop in a sub folder. We wouldn't recommend that and so it isn't likely to be something we put development time into solving.
I work in VMs and am constantly moving Perch sites and data around, with no problem at all. The new stuff in Perch Runway is brilliant as well as you can pop your database into Dropbox and keep assets in a Cloud bucket which makes life easier when moving between environments.
We've got lots of notes on multi-language - it's just a huge development effort, more information doesn't help with that, it just gives us something else to do.
To be perfectly honest it's probably not something we will tackle until we are at a point where we have another developer here. So that completely depends on whether we can grow Runway in particular to the point where we could afford to do that.
Another thing that would be great is the ability to clone or copy a page with the content and assets. I am making landing pages all with the same content and a few little tweaks here and there and a copy page feature would be perfect in this situation.
That won't happen, the minute we even hint that something might be in development we have people relying on it for their projects. We don't want people relying on something that we might have to push back due to another thing becoming more important.
We don't want to put people in a position where they are let down by us. So you should buy the software if it meets your needs now. If it doesn't and you have to use something else that's a risk we have to take. We think that is better and fairer than having people holding out for something we then find ourselves unable to deliver.
Being swiss, this has been a showstopper in various cases and I'd like to work around that - if it's more an issue of complex templates / some additional php (e.g. with perch_pages_navigation, forms...) than of the ease of use in the backend, I can live with that. Should be smooth in the backend for the client though.
@Rachel I understand your concerns and hope it goes that way with big success and additional "man"power
Stripe addon - anything that gives me more options for using Perch with an ecommerce project would be a huge plus. Currently I have to look at other CMS solutions when it's ecommerce.
2 - Duplicating an existing page - useful for creating landing pages where everything is very similar
Some eCommerce cart functionality would be big feature for me. Or like a whole eCommerce add-on (perhaps chargeable).
Ability to regenerate all image sizes without having to re-save each page etc. I have a few sites that have Perch that are now undergoing a redesign and as a result some of them (blogs particularly) would require new image dimensions for in list pages etc.
A single concept of an author or user of Perch. At the minute there are users, blog authors and an example by Drew for related content used collections of authors. You can even use categories for authors. It would be great to have a <perch:authors> tag, much like collections, that allowed you to select one or many authors. In the template, having content within this block would work like categories. I should then be able to filter by this author.
Related content. There is some functionality for this at the minute but it would be good if this could be expanded further. For example, a 'related-to' keyword for perch collections or blog posts that could take a slug such as 'collections/mycollection/slug'. This would then gab tags, keywords etc from the collection or blog post, find related content (with weighting) and return it or dump out the html.
A 'vars' keyword that sets and unsets any layout variables for collections etc. Seems like a quick win.
Both of those would be incredible. Also, +1 for event app start and stop times, I've needed that on more than one occasion!
Categories support for Apps such as the gallery
Runway: Multilanguage Support!
Assets is still the place where I have to turn away from Perch on certain projects. I'd like to see ways of using tags to filter and display file assets on the front-end, hierarchies of assets, and the ability to add custom fields to assets. And as mentioned by others, the ability to re-crop images based on new template values without having to re-assign the images one-by-one.
There's something unfortunately clunky about adding a bunch of images to a slideshow region, manually adding a repeater item or multi-item then clicking Select an image… then choosing the image then Use Selected Asset (or whatever) over and over and over. I think I understand why it works that way from a technical standpoint but the user experience is sub-par compared to what the editors may experience with other online applications. Not sure if that can be remedied given how Perch is set up, but I see it being done in other CMSes and it would improve editing flow significantly when groups of images are used.
Top request: multilingual content management in a more straightforward way than having to create a directory for each language (en/fr/de/it/es/ru/...) and duplicating pages within them. Or dealing with very long forms with all the inputs for all languages on top of each other, or some other hacky solution.
Easier deployment as migrating from a local server to a staging/production server (in short moving to another server) is clunky. It would be much easier if the links to content and pages were relative to a root defined as a setting in the CMS. That way moving Perch websites around would be less "fragile".
We absolutely want to do better multi-language support but it is a huge huge job to do really well (and we don't want to do it in a hacky way). It would impact on everything - the complexity of editing, the complexity of future development, the complexity of apps (ours and third parties using the API). It's something we talk about a lot here, and we do think important but don't underestimate how complex a job it is - and the fact it would essentially stop everything else while we did it!
I'm not sure what is fragile about moving a Perch site around unless you do something suboptimal like develop in a sub folder. We wouldn't recommend that and so it isn't likely to be something we put development time into solving.
I work in VMs and am constantly moving Perch sites and data around, with no problem at all. The new stuff in Perch Runway is brilliant as well as you can pop your database into Dropbox and keep assets in a Cloud bucket which makes life easier when moving between environments.
Thanks for sorting out the backgrounds on transparent images.
What I’d really like to see is end times for events (including over multiple days) and recurring events.
Meta feature: a feature roadmap
Thanks for adding draft icons to items in a collection - nice.
It'd be great if it was possible to 'like' or 'thumbs up' some of these suggestions in the forum.
@ Rachel, Stéphane about Multilanguage: would it help if we as users would join the effort? I once did a few wild notes for Drew, maybe Stéphane and other multi language experienced users could review them from their perspective? Only if it makes sense to you
@ Urs, Rachel: would be happy to chime in on notes if it helps.
We've got lots of notes on multi-language - it's just a huge development effort, more information doesn't help with that, it just gives us something else to do.
To be perfectly honest it's probably not something we will tackle until we are at a point where we have another developer here. So that completely depends on whether we can grow Runway in particular to the point where we could afford to do that.
Another thing that would be great is the ability to clone or copy a page with the content and assets. I am making landing pages all with the same content and a few little tweaks here and there and a copy page feature would be perfect in this situation.
That won't happen, the minute we even hint that something might be in development we have people relying on it for their projects. We don't want people relying on something that we might have to push back due to another thing becoming more important.
We don't want to put people in a position where they are let down by us. So you should buy the software if it meets your needs now. If it doesn't and you have to use something else that's a risk we have to take. We think that is better and fairer than having people holding out for something we then find ourselves unable to deliver.
@Stéphane do you have some examples on how you have coped with synchronous multilanguage sites? You can find my contact on www.sturmundbraem.ch if you do and would like to share.
Being swiss, this has been a showstopper in various cases and I'd like to work around that - if it's more an issue of complex templates / some additional php (e.g. with perch_pages_navigation, forms...) than of the ease of use in the backend, I can live with that. Should be smooth in the backend for the client though.
@Rachel I understand your concerns and hope it goes that way with big success and additional "man"power
2 - Duplicating an existing page - useful for creating landing pages where everything is very similar
Some eCommerce cart functionality would be big feature for me. Or like a whole eCommerce add-on (perhaps chargeable).
Ability to regenerate all image sizes without having to re-save each page etc. I have a few sites that have Perch that are now undergoing a redesign and as a result some of them (blogs particularly) would require new image dimensions for in list pages etc.
A single concept of an author or user of Perch. At the minute there are users, blog authors and an example by Drew for related content used collections of authors. You can even use categories for authors. It would be great to have a <perch:authors> tag, much like collections, that allowed you to select one or many authors. In the template, having content within this block would work like categories. I should then be able to filter by this author.
Related content. There is some functionality for this at the minute but it would be good if this could be expanded further. For example, a 'related-to' keyword for perch collections or blog posts that could take a slug such as 'collections/mycollection/slug'. This would then gab tags, keywords etc from the collection or blog post, find related content (with weighting) and return it or dump out the html.
A 'vars' keyword that sets and unsets any layout variables for collections etc. Seems like a quick win.